GoogleCodeExporter
commented
9 years ago [deleted comment]Closed GoogleCodeExporter closed 9 years ago
GoogleCodeExporter
commented
9 years ago [deleted comment]Example, how it should work.
A client sends an INVITE to a proxy server which looks like, in part:
INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff
This INVITE is sent with a source port of 4540 and a source IP
address of 10.1.1.1. The proxy is at 192.0.2.2 (proxy.example.com),
listening on both port 5060 and 5070. The client sends the request
to port 5060. The request passes through a NAT on the way to the
proxy, so that the source IP address appears as 192.0.2.1 and the
source port as 9988. The proxy forwards the request, but not before
appending a value to the "rport" parameter in the proxied request:
INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
;branch=z9hG4bKkjshdyff
This request generates a response which arrives at the proxy:
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
;branch=z9hG4bKkjshdyff
The proxy strips its top Via header field value, and then examines
the next one. It contains both a "received" parameter and an "rport"
parameter. The server follows the rules specified in Section 4 and
sends the response to IP address 192.0.2.1, port 9988, and sends it
from port 5060 on 192.0.2.2:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
;branch=z9hG4bKkjshdyff
This packet matches the binding created by the initial request.
Therefore, the NAT rewrites the destination address of this packet
back to 10.1.1.1, and the destination port back to 4540. It forwards
this response to the client, which is listening for the response on
that address and port. The client properly receives the response.Original comment by vale...@gmail.com on 6 May 2011 at 12:42
GoogleCodeExporter
commented
9 years ago Sorry I forgot to reply to this issue.
In fact you are just misconfiguring the application.
CSipSimple (actually pjsip, the sip stack on which csipsimple relies), provides
a cool feature that helps in many many case to workaround NAT issues and to
automatically detect you own public IP.
This method is also used by xlite AFAIK.
The client based on the first registration update its own contact header and
send a second register so that the public IP is the more accurate.
You can disable this feature (usually required when you have an SBC). To do so,
simply switch to expert mode account (see the wiki page about that), and then
disable "Allow contact rewrite" option.
I think that it will solve your problem. Also, search on the issue list (even
on closed issue), this was debated a lot of times and you'll also find other
bugs talking about NAT resolution done by pjsip and how it works with multiple
accounts.
If you think there is a bug in pjsip, you should ask directly pjsip guys (there
is mailing list).
I'm not an expert on what they did, but their stack is known to respect very
well SIP RFC (much more better than other SIP stacks, which sometimes leads to
weird things - for example for TCP transport ).
Original comment by r3gis...@gmail.com on 6 May 2011 at 2:02
GoogleCodeExporter
commented
9 years ago > and then disable "Allow contact rewrite" option.
This not helped me. I think problem with pjsip stack, because 3CXPhone also not
works.
Pjsip sends in "Via" header external IP, but local IP is needed in "Via" for my
SIP provider.Original comment by vale...@gmail.com on 6 May 2011 at 2:27
GoogleCodeExporter
commented
9 years ago Can not found how to register on their tracker.Original comment by vale...@gmail.com on 6 May 2011 at 2:38
GoogleCodeExporter
commented
9 years ago Try the mailing list :
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
As you said, if also appear in 3CX that's something with pjsip since they also
use it (even if they do not opensouce the rest of their code because they have
a pjsip license).
With allow contact rewrite disabled, did you restart the sip stack (go in
csipsimple settings and press back will restart teh stack)?
Cause pjsip cache the public IP once get.Original comment by r3gis...@gmail.com on 6 May 2011 at 2:55
GoogleCodeExporter
commented
9 years ago > With allow contact rewrite disabled, did you restart the sip stack (go in
csipsimple settings and press back will restart teh stack)? Cause pjsip cache
the public IP once get.
Wow! Helps! Last 5 hours I do different test. Thank you!
I did no know that "allow contact rewrite" means this possibility.
How caption "allow contact rewrite" can be connected with IPs?Original comment by vale...@gmail.com on 6 May 2011 at 3:06
GoogleCodeExporter
commented
9 years ago Cool :)
I'll try to explain my understanding of how pjsip (and xlite) do (can do) in
order to resolve public IP.
* First step it registers.
* From the server reply of this register, if "Allow contact rewrite" is enabled, it tries to read the public IP as seen by the registrar. If it finds a different public IP than the one it already knows (the IP of the binded socket), it store this new IP as the "Public IP of the pjsip stack".
* Then it send a new register with updated public IP.
Some registrar does not like to have this double registration, or does not like
the way pjsip cancel the previous registration (reason of the rewrite method
option). The other effect of this option is that it save a "public ip of the
stack". Having a single public IP known by the stack allow to save time in some
situation but has big drawback : for all the rest of time (and also other
accounts :S), it will talk using this new "public IP". This is really annoying
in some case (particularly when you have a private PBX and a public PBX and try
to use STUN).
But pjsip guys are aware about that and will allow a per account public IP
resolution in pjsip-2.0. (there is an open issue of this tracker about that
also so that I will update interested people when it will be done by pjsip guys
and integrated into csipsimple)Original comment by r3gis...@gmail.com on 6 May 2011 at 3:27
GoogleCodeExporter
commented
9 years ago Ok.
But I think "allow contact rewrite" must be disabled when STUN is disabled.
For my SIP provider:
If both disabled - works.
If both enabled - works.
IF "allow contact rewrite" - enabled, STUN is disabled - not works.Original comment by vale...@gmail.com on 7 May 2011 at 10:40
GoogleCodeExporter
commented
9 years ago @vale...
If both enabled -works. How can it be? Use STUN or enable allow contact rewrite
will makes registra thinks of you as NOT behind NAT. Use both STUN and enable
allow contact rewrite does not make senseOriginal comment by onmyway...@gmail.com on 8 Mar 2013 at 7:34
Original issue reported on code.google.com by
vale...@gmail.comon 6 May 2011 at 11:30