[OpenSIPS-Users] nat issue

Mon Nov 21 11:13:34 CET 2016

Hi Miha,

According the SIP grammar, that parameter is perfectly legitimate. The 
client is broken as it is not able to cope with it (in the worst case, 
to simply ignore it).

There is no out of the box way to disable it, but I may provide you a 
patch for that - just to see if that fixes your problem.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 18.11.2016 19:54, Miha wrote:
> Hello bogdan
>
> I guess, but it looks like so. Is it possible to remove it?
>
>
> tnx
> miha
>
> On 18/11/2016 15:39, Bogdan-Andrei Iancu wrote:
>> I guess your UAC freezes when receiving back in the 200 OK REGISTER 
>> the "received" hdr param in Contact ??
>>
>> Regards,
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>> On 18.11.2016 16:33, Bogdan-Andrei Iancu wrote:
>>> HI Miha,
>>>
>>> Sorry, but I'm not able to follow the case you mentioned with 
>>> Innovaphone PBX - maybe you can post (to see the differences) the 
>>> sent and returned contact hdrs in the REGISTER request + reply for 
>>> the 2 cases (OpenSIPS and Innovaphone PBX).
>>>
>>> Regards,
>>> Bogdan-Andrei Iancu
>>> OpenSIPS Founder and Developer
>>> http://www.opensips-solutions.com
>>> On 18.11.2016 11:20, Miha wrote:
>>>> I do not know if this is the case. But from what I can see what I 
>>>> register it on some Innovaphone PBX, innovaphone sends back in 
>>>> contact (200 ok) just ip of IPBX and also when INVITE is send in 
>>>> contact there is URI of PBX and only and it works.
>>>>
>>>> i tried this but did not have any luck.
>>>>
>>>> br
>>>> miha
>>>>
>>>> On 18/11/2016 09:48, Bogdan-Andrei Iancu wrote:
>>>>> Hi Miha,
>>>>>
>>>>> You mean the UAC does not like the multi-URI Contact header in the 
>>>>> 200 OK ???? If so, that UAC is really broken as 1) breaks the SIP 
>>>>> syntax (which allows it) and 2) breaks the the SIP Registration as 
>>>>> per RFC3261.
>>>>>
>>>>> What about the second contact (the one already existing in usrloc 
>>>>> when this registration comes) ? can it be discarded ? If YES, you 
>>>>> can try passing the "c1f" flags to save() :
>>>>> http://www.opensips.org/html/docs/modules/2.2.x/registrar.html#id294033
>>>>>
>>>>> That will make OpenSIPS to accept only 1 contact per AOR/user and 
>>>>> any new contact will override the existing one.
>>>>>
>>>>> Regards,
>>>>> Bogdan-Andrei Iancu
>>>>> OpenSIPS Founder and Developer
>>>>> http://www.opensips-solutions.com
>>>>> On 18.11.2016 10:15, Miha wrote:
>>>>>> Hi Bogdan
>>>>>>
>>>>>> I did few more test. This contact bothers UAC. Is there anything 
>>>>>> i can do in this case in OpenSIPS so that it will only reply with 
>>>>>> one URI in contact?
>>>>>>
>>>>>> Contact:<sip:38618308980 at opsp.kabelnet.net;transport=udp>;expires=1518
>>>>>> ;received="sip:84.41.125.21:5060",<sip:38618308980 at 84.41.125.21:5060>;
>>>>>> expires=180.
>>>>>>
>>>>>>
>>>>>> tnx so much!
>>>>>> MIha
>>>>>>
>>>>>> On 17/11/2016 12:11, Bogdan-Andrei Iancu wrote:
>>>>>>> Hi Miha,
>>>>>>>
>>>>>>> yes, that is parallel forking (you may have more than 2 contacts 
>>>>>>> only).
>>>>>>>
>>>>>>> Are you sure your DB was sync'ed? OpenSIPS is periodically 
>>>>>>> flushing the memory cache into the location table (see the 
>>>>>>> "state" of the contact (as per "ul show") if marked as DIRTY).
>>>>>>>
>>>>>>> In regards to RFC, I think you quote the wrong section (maybe 
>>>>>>> about callings?) - for REGISTERs, any number of URIs are allowed 
>>>>>>> AFAIK.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Bogdan-Andrei Iancu
>>>>>>> OpenSIPS Founder and Developer
>>>>>>> http://www.opensips-solutions.com
>>>>>>> On 17.11.2016 12:35, Miha wrote:
>>>>>>>> Bodan
>>>>>>>>
>>>>>>>> so this is dual forking...?
>>>>>>>> So if you have one account and you have two phones on it and 
>>>>>>>> first will try  to register, 200 ok will will have contact of 
>>>>>>>> both phones?
>>>>>>>> In location table I can see only one registration for this user 
>>>>>>>> but for "opensipsctl ul show" it shows me two contacts, which 
>>>>>>>> is strange? (When i do trace only one invite is send) and UAC 
>>>>>>>> replay with Busy all the time due to two contacts (this what i 
>>>>>>>> have been told).
>>>>>>>>
>>>>>>>> Ok, but if you look at rfc there is only one URI allowed in 
>>>>>>>> contact if I understand this right?
>>>>>>>>
>>>>>>>>
>>>>>>>> The Contact header field MUST be present and contain exactly one SIP
>>>>>>>>     or SIPS URI in any request that can result in the establishment of a
>>>>>>>>     dialog
>>>>>>>>
>>>>>>>> Please correct me if I am wrong.
>>>>>>>>
>>>>>>>>
>>>>>>>> tnx so much!
>>>>>>>> Miha
>>>>>>>>
>>>>>>>> On 17/11/2016 11:22, Bogdan-Andrei Iancu wrote:
>>>>>>>>> Hi Miha,
>>>>>>>>>
>>>>>>>>> OpenSIPS returns in the 200 OK for a REGISTER all the valid 
>>>>>>>>> registrations for that user (for all the devices the user may 
>>>>>>>>> have).
>>>>>>>>>
>>>>>>>>> I guess your user has 2 registrations, so the 200 OK will 
>>>>>>>>> report back both of them. You can check via "opensipsctl ul show"
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Bogdan-Andrei Iancu
>>>>>>>>> OpenSIPS Founder and Developer
>>>>>>>>> http://www.opensips-solutions.com
>>>>>>>>> On 17.11.2016 12:13, Miha wrote:
>>>>>>>>>> Hello Bogdan
>>>>>>>>>>
>>>>>>>>>> i changed this and it works in all cases, only in one I 
>>>>>>>>>> noticed today this (Opensips reply only in this case with two 
>>>>>>>>>> URI on contact):
>>>>>>>>>>
>>>>>>>>>>  UAC:5060 ->OpenSIPS:5060
>>>>>>>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0.
>>>>>>>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKa40225bd7495297c6.
>>>>>>>>>> Max-Forwards: 70.
>>>>>>>>>> From: 042335040 <sip:99942335040 at opsp.test.net>;tag=1f62205074.
>>>>>>>>>> To: 042335040 <sip:99942335040 at opsp.test.net>.
>>>>>>>>>> Call-ID: 61c67f739bef5a2e.
>>>>>>>>>> CSeq: 1804289391 REGISTER.
>>>>>>>>>> Allow:  INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE,
>>>>>>>>>> PRACK, INFO.
>>>>>>>>>> Authorization: Digest
>>>>>>>>>> username="99942335040",realm="opsp.test.net",nonce="582d810c000058b
>>>>>>>>>> d73adccf0d455c2a2159b3a3403c1f7a3",uri="sip:opsp.test.net:5060",res
>>>>>>>>>> ponse="bc0c757c17f9b0976af35ec633dd83ca".
>>>>>>>>>> Contact: 042335040 
>>>>>>>>>> <sip:99942335040 at opsp.test.net;transport=udp>;ex
>>>>>>>>>> pires=3600.
>>>>>>>>>> Privacy: none.
>>>>>>>>>> Supported: path.
>>>>>>>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2.
>>>>>>>>>> Content-Length: 0.
>>>>>>>>>>
>>>>>>>>>> UOpenSIPS:5060 -> UAC:5060
>>>>>>>>>> SIP/2.0 401 Unauthorized.
>>>>>>>>>> Via: SIP/2.0/UDP
>>>>>>>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKa4022
>>>>>>>>>> 5bd7495297c6.
>>>>>>>>>> From: 042335040 <sip:99942335040 at opsp.test.net>;tag=1f62205074.
>>>>>>>>>> To: 042335040 
>>>>>>>>>> <sip:99942335040 at opsp.test.net>;tag=0c7ff67d927afc274
>>>>>>>>>> b272138ce65100a.ac4d.
>>>>>>>>>> Call-ID: 61c67f739bef5a2e.
>>>>>>>>>> CSeq: 1804289391 REGISTER.
>>>>>>>>>> WWW-Authenticate: Digest realm="opsp.test.net",
>>>>>>>>>> nonce="582d811300005a88b92d0287a7460acce0a84e5d2a200b33", 
>>>>>>>>>> stale=true.
>>>>>>>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)).
>>>>>>>>>> Content-Length: 0.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> U UAC:5060 ->OpenSIPS:5060
>>>>>>>>>> REGISTER sip:opsp.test.net:5060 SIP/2.0.
>>>>>>>>>> Via: SIP/2.0/UDP opsp.test.net;branch=z9hG4bKb5f2bbbf80e346f48.
>>>>>>>>>> Max-Forwards: 70.
>>>>>>>>>> From: 042335040 <sip:99942335040 at opsp.test.net>;tag=1f62205074.
>>>>>>>>>> To: 042335040 <sip:99942335040 at opsp.test.net>.
>>>>>>>>>> Call-ID: 61c67f739bef5a2e.
>>>>>>>>>> CSeq: 1804289392 REGISTER.
>>>>>>>>>> Allow:  INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE,
>>>>>>>>>> PRACK, INFO.
>>>>>>>>>> Authorization: Digest
>>>>>>>>>> username="99942335040",realm="opsp.test.net",nonce="582d811300005a8
>>>>>>>>>> 8b92d0287a7460acce0a84e5d2a200b33",uri="sip:opsp.test.net:5060",res
>>>>>>>>>> ponse="9ce3622addeedf74622a23697e6f3728".
>>>>>>>>>> Contact: 042335040 
>>>>>>>>>> <sip:99942335040 at opsp.test.net;transport=udp>;ex
>>>>>>>>>> pires=3600.
>>>>>>>>>> Privacy: none.
>>>>>>>>>> Supported: path.
>>>>>>>>>> User-Agent: Brcm-Callctrl/v1.10.3 M5T SIP Stack/4.1.2.2.
>>>>>>>>>> Content-Length: 0.
>>>>>>>>>> .
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> UOpenSIPS:5060 -> UAC:5060
>>>>>>>>>> SIP/2.0 200 OK.
>>>>>>>>>> Via: SIP/2.0/UDP
>>>>>>>>>> opsp.test.net;received=UAC;rport=5060;branch=z9hG4bKb5f2b
>>>>>>>>>> bbf80e346f48.
>>>>>>>>>> From: 042335040 <sip:99942335040 at opsp.test.net>;tag=1f62205074.
>>>>>>>>>> To: 042335040 
>>>>>>>>>> <sip:99942335040 at opsp.test.net>;tag=766e4f757c55b3450
>>>>>>>>>> c9992a50fb64799-9163.
>>>>>>>>>> Call-ID: 61c67f739bef5a2e.
>>>>>>>>>> CSeq: 1804289392 REGISTER.
>>>>>>>>>> Contact: 
>>>>>>>>>> <sip:99942335040 at opsp.test.net;transport=udp>;expires=3600
>>>>>>>>>> ;received="sip:UAC:5060", <sip:99942335040 at UAC:1024
>>>>>>>>>> > ;expires=119.
>>>>>>>>>> Server: OpenSIPS (1.10.0beta-tls (x86_64/linux)).
>>>>>>>>>> Content-Length: 0.
>>>>>>>>>>
>>>>>>>>>> Do you see where could be an issue?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> tnx
>>>>>>>>>> miha
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 16/11/2016 08:11, Miha wrote:
>>>>>>>>>>> Hello Bogdan
>>>>>>>>>>>
>>>>>>>>>>> yes this was the case...
>>>>>>>>>>>
>>>>>>>>>>> thank you!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> br
>>>>>>>>>>> miha
>>>>>>>>>>>
>>>>>>>>>>> On 15/11/2016 18:35, Bogdan-Andrei Iancu wrote:
>>>>>>>>>>>> Hi Miha,
>>>>>>>>>>>>
>>>>>>>>>>>> When you handle REGISTER requests (from behind NAT) most 
>>>>>>>>>>>> probably you use fix_nated_contact() instead of 
>>>>>>>>>>>> fix_nated_register().
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Bogdan-Andrei Iancu
>>>>>>>>>>>> OpenSIPS Founder and Developer
>>>>>>>>>>>> http://www.opensips-solutions.com
>>>>>>>>>>>> On 15.11.2016 09:11, Miha wrote:
>>>>>>>>>>>>> Hello
>>>>>>>>>>>>>
>>>>>>>>>>>>> i need one info.
>>>>>>>>>>>>> I have one phone behind NAT and it is registered on 
>>>>>>>>>>>>> OpenSIPS. IN register packet, which is send to OpenSIPS I 
>>>>>>>>>>>>> can see contact: 
>>>>>>>>>>>>> "sip:11181600519 at 192.168.0.101:5060;transport=UDP"
>>>>>>>>>>>>>
>>>>>>>>>>>>> and let says that the public ip for this device is 
>>>>>>>>>>>>> xxx.xxx.xxx.xxx.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> When opensips sends INVITE it send to right public ip and 
>>>>>>>>>>>>> right port (source ip and source port generated by 
>>>>>>>>>>>>> router). The issue is this:
>>>>>>>>>>>>> Invite is like:  
>>>>>>>>>>>>> "sip:11181600519 at xxx.xxx.xxx.xxx:5060;transport=UDP" and 
>>>>>>>>>>>>> this request is then fw to this UAC behind router. The UAC 
>>>>>>>>>>>>> replays to this INVITE with 404 Not found as it is waiting 
>>>>>>>>>>>>> to receive the same URI which was written in contact (the 
>>>>>>>>>>>>> userpart is ok, put the ip is public, not private and this 
>>>>>>>>>>>>> is the issue).From what I can see in RFC this is the case.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Till now Idid not have any issues with this, but now I 
>>>>>>>>>>>>> found first phone which replays with 404 and from RFC 
>>>>>>>>>>>>> point of view there should be private ip request :) . So 
>>>>>>>>>>>>> is there anything I can do :)?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> tnx
>>>>>>>>>>>>> miha
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Users mailing list
>>>>>>>>>>>>> Users at lists.opensips.org
>>>>>>>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20161121/3a923bb1/attachment-0001.htm>