[OpenSIPS-Users] nat issue

Fri Nov 18 09:42:04 CET 2016

Hi Miha,

In the "ul show" output, each contact has a "State" field:
     State:: CS_SYNC
It can be CS_SYNC which means the contact from memory was synced to DB 
or CS_DIRTY which means the contact in memory was changed since the last 
sync to DB.

Regards,

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

On 17.11.2016 14:36, Miha wrote:
> Hello Bogdan
>
> how would I know that is marked as DIRTY? how this will look like?
>
>
> tnx
> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20161118/487c20cb/attachment.htm>