Hello,
The diagram below shows the SIP message flow in our setup when Softphone A places a call to Softphone B.
----------- ----- ---------- ----- ----------- |Softphone A|-<->-|Proxy|-<->-|Sip Server|-<->-|Proxy|-<->-|Softphone B| ----------- ----- ---------- ----- ----------- IP: a.b.c.d IP: a.b.c.d
Proxies shown in the diagram above are physically the same entity. For convenience of diagrammatic representation the figure above has been unwrapped.
Both Softphone A and Softphone B (hereafter referred to as A,B) are behind a NAT and are registered to the Sip Server through the same proxy (IP: a.b.c.d). Proxy runs Kamailio v3.0.1.
When A places a call to B, an INVITE is proxied to the Sip Server from A. The Sip Server now sends another INVITE to the proxy, however the R-URI of this INVITE does not contain the port number that the INVITE is supposed to be sent to. Hence the proxy sends the INVITE to the default SIP port 5060. This port is not open in the firewall hence Softphone B never receives the INVITE.
My questions are 1) Is it mandatory for R-URI of the INVITE to contain the port number ?
2) If not, is there something that can be added to the config script in Kamailio so that the proxy forwards the INVITE to the appropriate port? (maybe by keeping track of the rcv port of the REGISTER message that Softphone B sends...) ?
Thanks and Regards, Vikram.
PS : The Sip Server in the above discussion is Voipswitch.
Vikram,
1. The port is not mandatory.
2. You can force the port in the RURI explicitly by manipulating the mutable pseudovariable $rp prior to relay, E.g.
$rp = 5067;
-- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Jan 18, 2011, at 1:02 PM, Vikram Ragukumar vragukumar@signalogic.com wrote:
Hello,
The diagram below shows the SIP message flow in our setup when Softphone A places a call to Softphone B.
|Softphone A|-<->-|Proxy|-<->-|Sip Server|-<->-|Proxy|-<->-| Softphone B|
IP: a.b.c.d IP: a.b.c.dProxies shown in the diagram above are physically the same entity. For convenience of diagrammatic representation the figure above has been unwrapped.
Both Softphone A and Softphone B (hereafter referred to as A,B) are behind a NAT and are registered to the Sip Server through the same proxy (IP: a.b.c.d). Proxy runs Kamailio v3.0.1.
When A places a call to B, an INVITE is proxied to the Sip Server from A. The Sip Server now sends another INVITE to the proxy, however the R-URI of this INVITE does not contain the port number that the INVITE is supposed to be sent to. Hence the proxy sends the INVITE to the default SIP port 5060. This port is not open in the firewall hence Softphone B never receives the INVITE.
My questions are
- Is it mandatory for R-URI of the INVITE to contain the port
number ?
- If not, is there something that can be added to the config script
in Kamailio so that the proxy forwards the INVITE to the appropriate port? (maybe by keeping track of the rcv port of the REGISTER message that Softphone B sends...) ?
Thanks and Regards, Vikram.
PS : The Sip Server in the above discussion is Voipswitch.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
When A places a call to B, an INVITE is proxied to the Sip Server from A. The Sip Server now sends another INVITE to the proxy, however the R-URI of this INVITE does not contain the port number that the INVITE is supposed to be sent to. Hence the proxy sends the INVITE to the default SIP port 5060. This port is not open in the firewall hence Softphone B never receives the INVITE.
Usually the softphones register to the proxy or SIP server. Thus, the proxy or SIP server knows under which IP:port (The IP:port from which the REGISTER was received) it can contact the sofpthone.
regards klaus
Hello,
Alex, Klaus thank you for your replies.
Usually the softphones register to the proxy or SIP server. Thus, the proxy or SIP server knows under which IP:port (The IP:port from which the REGISTER was received) it can contact the sofpthone.
Yes, the softphones are registered to the SIP server, and hence the SIP server has the IP:port information required to contact the softphone. However, the SIP server does not include the port number in the R-URI of the INVITE that it generates.
This port number is dynamically assigned by the firewall and is not fixed, so manipulating the pseudo variable $rp by assigning it a fixed number will not work.
If it is not mandatory to include the port number in the R-URI, how does the proxy determine the port to which the SIP message must be forwarded ?
Thanks and Regards, Vikram.
It is assumed 5060 by default.
-- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Jan 18, 2011, at 2:27 PM, Vikram Ragukumar vragukumar@signalogic.com wrote:
Hello,
Alex, Klaus thank you for your replies.
Usually the softphones register to the proxy or SIP server. Thus, the proxy or SIP server knows under which IP:port (The IP:port from which the REGISTER was received) it can contact the sofpthone.
Yes, the softphones are registered to the SIP server, and hence the SIP server has the IP:port information required to contact the softphone. However, the SIP server does not include the port number in the R-URI of the INVITE that it generates.
This port number is dynamically assigned by the firewall and is not fixed, so manipulating the pseudo variable $rp by assigning it a fixed number will not work.
If it is not mandatory to include the port number in the R-URI, how does the proxy determine the port to which the SIP message must be forwarded ?
Thanks and Regards, Vikram.
Am 18.01.2011 20:27, schrieb Vikram Ragukumar:
Hello,
Alex, Klaus thank you for your replies.
Usually the softphones register to the proxy or SIP server. Thus, the proxy or SIP server knows under which IP:port (The IP:port from which the REGISTER was received) it can contact the sofpthone.
Yes, the softphones are registered to the SIP server, and hence the SIP server has the IP:port information required to contact the softphone. However, the SIP server does not include the port number in the R-URI of the INVITE that it generates.
Does the SIP server perform NAT traversal?
Does the SIP proxy perform NAT traversal?
How does the SIP server route the INVITE requests? Does it route based on registered Contact or does it route them statically to the SIP proxy? Depending on the routing behavior on the SIP server you can build a workaround on the proxy.
regards klaus
This port number is dynamically assigned by the firewall and is not fixed, so manipulating the pseudo variable $rp by assigning it a fixed number will not work.
If it is not mandatory to include the port number in the R-URI, how does the proxy determine the port to which the SIP message must be forwarded ?
Thanks and Regards, Vikram.
Klaus, Alex,
Thank you for your replies.
Does the SIP server perform NAT traversal?
Does the SIP proxy perform NAT traversal?
The SIP proxy performs NAT traversal.
How does the SIP server route the INVITE requests? Does it route based on registered Contact or does it route them statically to the SIP proxy? Depending on the routing behavior on the SIP server you can build a workaround on the proxy.
The SIP server routes INVITES based on registered Contact.
What workaround needs to be implemented at the proxy so that the INVITE is forwarded to the appropriate port number ?
Thanks and Regards, Vikram.
Am 19.01.2011 18:21, schrieb Vikram Ragukumar:
Klaus, Alex,
Thank you for your replies.
Does the SIP server perform NAT traversal?
Does the SIP proxy perform NAT traversal?
The SIP proxy performs NAT traversal.
How? Does it change the Contact header?
How does the SIP server route the INVITE requests? Does it route based on registered Contact or does it route them statically to the SIP proxy? Depending on the routing behavior on the SIP server you can build a workaround on the proxy.
The SIP server routes INVITES based on registered Contact.
So the SIP server is the registrar?
The contact usually is the IP address of the client. So, if you the SIP server routes based on the contact header, it should send the INVITE directly to the client not to the proxy. Somehow this all does not fit together.
What workaround needs to be implemented at the proxy so that the INVITE is forwarded to the appropriate port number ?
It depends on how is the registrar - proxy or the SIP server.
The workaround also depends on the respective buggy behavior of the sip server (if there is one at all).
I think it is not possible to further debug this problem without a complete trace of the scenario:
ngrep -W byline -t -d any -P "" port 5060
regards klaus
Klaus,
Thanks for your continued help.
How? Does it change the Contact header?
Yes, the proxy changes the Contact header.
So the SIP server is the registrar?
Correct.
The contact usually is the IP address of the client. So, if you the SIP server routes based on the contact header, it should send the INVITE directly to the client not to the proxy. Somehow this all does not fit together.
Clarification : Both clients A and B have the proxy as an outbound proxy. Clients register to the SIP server through the proxy. The SIP server routes the INVITE (INVITE from A that was proxied to SIP server) to the proxy with the R-URI being constructed based on the contents of the Contact header (IP only no port info). This is what I meant by saying the SIP server routes INVITE based on registered Contact (R-URI of INVITE is based on Contact header of client B's REGISTER message).
It depends on how is the registrar - proxy or the SIP server.
The workaround also depends on the respective buggy behavior of the sip server (if there is one at all).
I think it is not possible to further debug this problem without a complete trace of the scenario:
ngrep -W byline -t -d any -P "" port 5060
Attached to the email is a sip trace captured at the proxy showing
- Registration of client B - INVITE messages originated by client A trying to call client B - The sip trace has been edited to remove "duplicate" messages arising from authentication - Towards the end, the sip trace shows 4 INVITE messages from proxy to Client B. However none of these messages reach client B because proxy is sending to port 5060, while client B is reachable at Nated port 55000. This port information is not specified in the R-URI of INVITE by SIP server. - Eventually a timeout will occur (not shown in log for sake of brevity) - Both clients A,B are behind same NAT (public ip x.x.x.226)
What needs to be done at the proxy to ensure INVITE is forwarded to the correct port (55000 in this case) instead of the default port 5060 ?
Once again thanks for your help.
Regards, Vikram.
The contact usually is the IP address of the client. So, if you the SIP server routes based on the contact header, it should send the INVITE directly to the client not to the proxy. Somehow this all does not fit together.
Clarification : Both clients A and B have the proxy as an outbound proxy. Clients register to the SIP server through the proxy. The SIP server routes the INVITE (INVITE from A that was proxied to SIP server) to the proxy with the R-URI being constructed based on the contents of the Contact header (IP only no port info). This is what I meant by saying the SIP server routes INVITE based on registered Contact (R-URI of INVITE is based on Contact header of client B's REGISTER message).
To me it seems that the SIP server also does some kind of NAT traversal: it puts the Contact IP in to the RURI but it sends the request to the IP:port from which the REGISTER was received (that's called NAT traversal).
So, either fix the SIP server (make sure it adds the port as in the Contact header also to the RURI) or try a workaround:
A woraround would be for example to put the received port in the Contact URI as an URI paramter. If the SIP server does not strip URI parameters as well, then you might be lucky and restore the port from the parameter in the RURI.
For the URI-parameter workaround try the functions add_contact_alias() and handle_ruri_alias(): http://www.kamailio.org/docs/modules/stable/modules_k/nathelper.html#id27642...
regards klaus
Klaus,
To me it seems that the SIP server also does some kind of NAT traversal: it puts the Contact IP in to the RURI but it sends the request to the IP:port from which the REGISTER was received (that's called NAT traversal).
So, either fix the SIP server (make sure it adds the port as in the Contact header also to the RURI) or try a workaround:
A woraround would be for example to put the received port in the Contact URI as an URI paramter. If the SIP server does not strip URI parameters as well, then you might be lucky and restore the port from the parameter in the RURI.
For the URI-parameter workaround try the functions add_contact_alias() and handle_ruri_alias(): http://www.kamailio.org/docs/modules/stable/modules_k/nathelper.html#id27642...
Ok, will try your suggestion for the workaround.
Thanks for all the help.
Regards, Vikram.
-
Alex Balashov -
Klaus Darilion -
Vikram Ragukumar