Pavel
2019-Apr-22 16:41 UTC
[asterisk-users] Incoming SIP call, outgoing SIP registration. PJSIP.
Hi, Got problems with incoming SIP calls. Scenario: Server1: 3cx or any other server Server2: Asterisk 16.2.1 . PJPROJECT 2.8 Server2 registers on Server1 with SIP ID 1121. Registration is OK. Server2 outgoing calls are OK. INVITE, unauthorized, INVITE with password, OK, RINGING,... Troubles with incoming calls / incoming INVITE's . I can not identify endpoint by IP, I have multiple registrations on the same Server1. As far as I understood, res_pjsip_endpoint_identifier_user match endpoint by "From" header, so it will not match also. match_headers also seems useless (not able to match "INVITE" string, just headers like "TO:"). Is there any way to match incoming INVITE calls ? (also OPTIONS, NOTIFY, ... packets) It should be a typical scenario, but it does not work... Is there any way to make it working ? -------------- next part -------------- [0.0.0.0-udp] type=transport protocol=udp bind=0.0.0.0:5060 [endpoint0](!) type=endpoint transport=0.0.0.0-udp disallow=all allow=alaw allow=ulaw t38_udptl=no t38_udptl_ec=none fax_detect=no t38_udptl_nat=no dtmf_mode=auto direct_media=yes from_domain=172.16.25.23 timers_sess_expires=1800 tone_zone=ru language=ru rewrite_contact=yes rtp_symmetric=yes force_rport=yes [registration0](!) type=registration transport=0.0.0.0-udp retry_interval=60 max_retries=10 expiration=3600 auth_rejection_permanent=yes server_uri=sip:172.16.25.23 [fxs17](endpoint0) context=from-sip-fxs aors=fxs17 outbound_auth=fxs17 from_user=1121 set_var=DAHDICHAN=17 [fxs17] type=aor qualify_frequency=60 contact=sip:1121 at 172.16.25.23 [fxs17] type=auth auth_type=userpass password=111111 username=1121 [fxs17](registration0) outbound_auth=fxs17 client_uri=sip:1121 at 172.16.25.23 contact_user=fxs17
Joshua C. Colp
2019-Apr-22 16:47 UTC
[asterisk-users] Incoming SIP call, outgoing SIP registration. PJSIP.
On Mon, Apr 22, 2019, at 1:43 PM, Pavel wrote:> Hi, > > Got problems with incoming SIP calls. > > Scenario: > > Server1: 3cx or any other server > > Server2: Asterisk 16.2.1 . PJPROJECT 2.8 > > Server2 registers on Server1 with SIP ID 1121. > > Registration is OK. > > Server2 outgoing calls are OK. > > INVITE, unauthorized, INVITE with password, OK, RINGING,... > > Troubles with incoming calls / incoming INVITE's . > > I can not identify endpoint by IP, I have multiple registrations on the > same Server1. > > As far as I understood, res_pjsip_endpoint_identifier_user match > endpoint by "From" header, so it will not match also. > > match_headers also seems useless (not able to match "INVITE" string, > just headers like "TO:"). > > Is there any way to match incoming INVITE calls ? (also OPTIONS, NOTIFY, > ... packets) > > It should be a typical scenario, but it does not work... > > Is there any way to make it working ?Outbound registration provides the line option[1] which can be used to differentiate traffic in regards to different outbound registrations. It requires the remote server to adhere to the SIP RFC and report back some data we give in our Contact, so you have to test it and see if it works. [1] https://blogs.asterisk.org/2016/01/27/the-pjsip-outbound-registration-line-option/ -- Joshua C. Colp Digium - A Sangoma Company | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org
Pavel
2019-Apr-22 17:09 UTC
[asterisk-users] Incoming SIP call, outgoing SIP registration. PJSIP.
Hi, Thank for your answer. 22.04.2019 23:47, Joshua C. Colp пишет:> On Mon, Apr 22, 2019, at 1:43 PM, Pavel wrote: >> Hi, >> >> Got problems with incoming SIP calls. >> >> Scenario: >> >> Server1: 3cx or any other server >> >> Server2: Asterisk 16.2.1 . PJPROJECT 2.8 >> >> Server2 registers on Server1 with SIP ID 1121. >> >> Registration is OK. >> >> Server2 outgoing calls are OK. >> >> INVITE, unauthorized, INVITE with password, OK, RINGING,... >> >> Troubles with incoming calls / incoming INVITE's . >> >> I can not identify endpoint by IP, I have multiple registrations on the >> same Server1. >> >> As far as I understood, res_pjsip_endpoint_identifier_user match >> endpoint by "From" header, so it will not match also. >> >> match_headers also seems useless (not able to match "INVITE" string, >> just headers like "TO:"). >> >> Is there any way to match incoming INVITE calls ? (also OPTIONS, NOTIFY, >> ... packets) >> >> It should be a typical scenario, but it does not work... >> >> Is there any way to make it working ? > Outbound registration provides the line option[1] which can be used to differentiate traffic in regards to different outbound registrations. It requires the remote server to adhere to the SIP RFC and report back some data we give in our Contact, so you have to test it and see if it works. > > [1] https://blogs.asterisk.org/2016/01/27/the-pjsip-outbound-registration-line-option/Tried already. "line" is good, but not perfect. Every time I restart asterisk, it will generate new random string for ";line=". So, every time I restart asterisk, registrar (Server1) will save one more contact in it's database. Some will remove obsolete contacts, but some will not. For example, FreePBX will not remove obsolete contacts, if max_contacts specified (FreePBX will set rewrite_contact=no in this case). So, after a number of Asterisk restarts, FreePBX will reject new registrations, as max_contacts is reached. Unfortunately, "line" does not save random between restarts. It's also unable to specify "random" value in pjsip.conf. I'm thinking to patch res_pjsip_outbound_registration to add this feature. Am I wrong and there is another way ? It's also a security hole, as anybody can generate INVITE with ";line=random" from any IP address ! res_pjsip_outbound_registration will only match "line", but will not take care about source IP, ... Is there any more clear way to identify incoming INVITE/OPTIONS packets ? Not very familliar with SIP, not sure, how should it be done. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20190423/f595b2ad/attachment.html>