Re: [OpenSIPS-Users] nat issue

[Bogdan-Andrei Iancu]

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:38618308...@opsp.kabelnet.net;transport=udp>;expires=1518
;received="sip:84.41.125.21:5060",<sip:38618308980@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:99942335...@opsp.test.net>;tag=1f62205074.
To: 042335040 <sip:99942335...@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:99942335...@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:99942335...@opsp.test.net>;tag=1f62205074.
To: 042335040 <sip:99942335...@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:99942335...@opsp.test.net>;tag=1f62205074.
To: 042335040 <sip:99942335...@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:99942335...@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:99942335...@opsp.test.net>;tag=1f62205074.
To: 042335040 <sip:99942335...@opsp.test.net>;tag=766e4f757c55b3450
c9992a50fb64799-9163.
Call-ID: 61c67f739bef5a2e.
CSeq: 1804289392 REGISTER.
Contact: <sip:99942335...@opsp.test.net;transport=udp>;expires=3600
;received="sip:UAC:5060", <sip:99942335040@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@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:11181600...@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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users










_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users