Fixing the Contact Header for NAT

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Fixing the Contact Header for NAT

Juan Backson
Hi,

I am having a problem with using B2BUA -> Opensips -> xLite behind NAT.  When the B2BUA sends back a 200OK, it is received by the SIP client behind NAT, but the SIP client does not response properly with ACK when the xLite is not in the same local LAN as the Opensips.  If xLite is connected within the local LAN of Opensips, then xLite can response properly with ACK.  I think this is due to Contact header not properly configured, but I did use fix_nated_contact() inside the onreply_route[1]. 

onreply_route[1] {
    xlog("L_INFO", "Reply - S=$rs D=$rr F=$fu T=$tu IP=$si ID=$ci\n");
        search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');
    fix_nated_contact();
    exit;

 
}

Any suggestion on how to resolve this problem will be greatly appreciated.

JB

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fixing the Contact Header for NAT

Iñaki Baz Castillo
El Miércoles, 26 de Noviembre de 2008, Juan Backson escribió:
> I am having a problem with using B2BUA -> Opensips -> xLite behind NAT. 
> When the B2BUA sends back a 200OK, it is received by the SIP client behind
> NAT, but the SIP client does not response properly with ACK when the xLite
> is not in the same local LAN as the Opensips.  If xLite is connected within
> the local LAN of Opensips, then xLite can response properly with ACK.  I
> think this is due to Contact header not properly configured, but I did use
> fix_nated_contact() inside the onreply_route[1]. 


Well, how is the Contact the callee receives in the 200 OK?
Does OpenSIPS add Record-Route?

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fixing the Contact Header for NAT

Juan Backson
Hi,
Sorry for double posting for the same problem.  This second post was meant to nail down on the exact issue for the first post.  I am very sorry for any inconvenience caused.
 
Inaki,
 
In the 200OK received by the nated client, the Contact is :Contact: <sip:1000@192.168.1.100:33756>
Opensips did not add the Record-Route even though I did specify fix_nated_contact in on_reply_route.  Do you have any idea why that is the case?
 
Thanks alot for all your help.
 
JB


 
On Wed, Nov 26, 2008 at 7:47 PM, Iñaki Baz Castillo <[hidden email]> wrote:
El Miércoles, 26 de Noviembre de 2008, Juan Backson escribió:
> I am having a problem with using B2BUA -> Opensips -> xLite behind NAT. 
> When the B2BUA sends back a 200OK, it is received by the SIP client behind
> NAT, but the SIP client does not response properly with ACK when the xLite
> is not in the same local LAN as the Opensips.  If xLite is connected within
> the local LAN of Opensips, then xLite can response properly with ACK.  I
> think this is due to Contact header not properly configured, but I did use
> fix_nated_contact() inside the onreply_route[1]. 


Well, how is the Contact the callee receives in the 200 OK?
Does OpenSIPS add Record-Route?

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fixing the Contact Header for NAT

Iñaki Baz Castillo
El Jueves, 27 de Noviembre de 2008, Juan Backson escribió:
> In the 200OK received by the nated client, the Contact is :Contact:
> <sip:1000@192.168.1.100:33756>

> Opensips did not add the Record-Route even
> though I did specify fix_nated_contact in on_reply_route.

Perhaps you don't understand the meaning of adding Record-Route, it has
*nothing* to do with fix_nated_contact.

Adding Record-Route means that in-dialog requests (as the ACK for the 200 OK)
will pass through the proxy, so the ACK will contain a Route header and a
RURI with the value of the Contact received in the 200 OK:

  ACK sip:1000@192.168.1.100:33756
  From: zzzzzzz
  To: zzzz
  Route: <sip:ip_proxy>

This ACK will arrive to the proxy (it has a Route so the device/phone MUST
send the request there), but whe this ACK arrives to the proxy it will remove
the Route header and route it based on the RURI, this is: the proxy will
forward this ACK to IP 192.168.1.100:33756.
Do you understand the problem? Most probably, the proxy is in a different
network (hopefully with public IP) so it cannot reach that private IP.

To solve it, the proxy must run "fix_nated_contact" in on_reply_route. This
will replace the IP in the Contact of the 200 OK with the received public IP.

In your case, this last point is not working since the UAS receives a Contact
with a private IP. Verify it.


--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fixing the Contact Header for NAT

Juan Backson
Hi Inaki,
 
Thank you for your kindness in helping me out. 
I think your diagnosis of the problem is exactly what I am facing right now. 
I tried to solve it by putting in :
 
    if (nat_uac_test("19")) {
        xlog("nat client detected\n");   
            if (method=="REGISTER") {
                    fix_nated_register();
            } else {
                fix_nated_contact();
            };
            setflag(5);
        };
   
     if(!is_method("REGISTER")){
            if(nat_uac_test("19")){
        xlog("record route with nat = yes\n");
               record_route(";nat=yes");
            } else {
        xlog("normal record route\n");
               record_route();
            };
     };
 
 
But it is still not working.  My opensips and B2BUA are within on NAT and my xlite is within another NAT, is this going to work?
 
Thanks,
JB

On Thu, Nov 27, 2008 at 9:20 PM, Iñaki Baz Castillo <[hidden email]> wrote:
El Jueves, 27 de Noviembre de 2008, Juan Backson escribió:
> In the 200OK received by the nated client, the Contact is :Contact:
> <sip:1000@192.168.1.100:33756>

> Opensips did not add the Record-Route even
> though I did specify fix_nated_contact in on_reply_route.

Perhaps you don't understand the meaning of adding Record-Route, it has
*nothing* to do with fix_nated_contact.

Adding Record-Route means that in-dialog requests (as the ACK for the 200 OK)
will pass through the proxy, so the ACK will contain a Route header and a
RURI with the value of the Contact received in the 200 OK:

 ACK sip:1000@192.168.1.100:33756
 From: zzzzzzz
 To: zzzz
 Route: <sip:ip_proxy>

This ACK will arrive to the proxy (it has a Route so the device/phone MUST
send the request there), but whe this ACK arrives to the proxy it will remove
the Route header and route it based on the RURI, this is: the proxy will
forward this ACK to IP 192.168.1.100:33756.
Do you understand the problem? Most probably, the proxy is in a different
network (hopefully with public IP) so it cannot reach that private IP.

To solve it, the proxy must run "fix_nated_contact" in on_reply_route. This
will replace the IP in the Contact of the 200 OK with the received public IP.

In your case, this last point is not working since the UAS receives a Contact
with a private IP. Verify it.


--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fixing the Contact Header for NAT

Iñaki Baz Castillo
El Jueves, 27 de Noviembre de 2008, Juan Backson escribió:

> Hi Inaki,
>
> Thank you for your kindness in helping me out.
> I think your diagnosis of the problem is exactly what I am facing right
> now.
> I tried to solve it by putting in :
>
>     if (nat_uac_test("19")) {
>         xlog("nat client detected\n");
>             if (method=="REGISTER") {
>                     fix_nated_register();
>             } else {
>                 fix_nated_contact();
>             };
>             setflag(5);
>         };
>
>      if(!is_method("REGISTER")){
>             if(nat_uac_test("19")){
>         xlog("record route with nat = yes\n");
>                record_route(";nat=yes");
>             } else {
>         xlog("normal record route\n");
>                record_route();
>             };
>      };
>
>
> But it is still not working.

In the above code there is no "onreply_route" in which you should
run "fix_nated_contact()" in 18X and 200 responses to an INVITE.

 
> My opensips and B2BUA are within on NAT and
> my xlite is within another NAT, is this going to work?

Sure.


--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fixing the Contact Header for NAT

Juan Backson
Hi Inaki,
 
Thanks for the help.  I think I should be closed to getting the final resolution. 
 
In my onreply_route, I have:
 
onreply_route[1] {
fix_nated_contact();
exit;

}
 
But that alone does not work.  Is ther anything else that I should add to thie onrply_route?
 
JB
 
 

On Thu, Nov 27, 2008 at 10:07 PM, Iñaki Baz Castillo <[hidden email]> wrote:
El Jueves, 27 de Noviembre de 2008, Juan Backson escribió:
> Hi Inaki,
>
> Thank you for your kindness in helping me out.
> I think your diagnosis of the problem is exactly what I am facing right
> now.
> I tried to solve it by putting in :
>
>     if (nat_uac_test("19")) {
>         xlog("nat client detected\n");
>             if (method=="REGISTER") {
>                     fix_nated_register();
>             } else {
>                 fix_nated_contact();
>             };
>             setflag(5);
>         };
>
>      if(!is_method("REGISTER")){
>             if(nat_uac_test("19")){
>         xlog("record route with nat = yes\n");
>                record_route(";nat=yes");
>             } else {
>         xlog("normal record route\n");
>                record_route();
>             };
>      };
>
>
> But it is still not working.

In the above code there is no "onreply_route" in which you should
run "fix_nated_contact()" in 18X and 200 responses to an INVITE.


> My opensips and B2BUA are within on NAT and
> my xlite is within another NAT, is this going to work?

Sure.


--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fixing the Contact Header for NAT

Iñaki Baz Castillo
El Jueves, 27 de Noviembre de 2008, Juan Backson escribió:
> In my onreply_route, I have:
>  
> onreply_route[1] {
> fix_nated_contact();
> exit;
>
> }
>  
> But that alone does not work.

Can you check it by doing a SIP capture? the Contact in 200 arriving to
OpenSIPS will contain a private IP, while the Contact in 200 leaving OpenSIPS
will contain a public IP (should contain).

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fixing the Contact Header for NAT

Juan Backson
Hi Inaki
 
Here is the sip trace from b2bua to opensips.  The contact in 200OK has public ip:
 
U 233.32.345.5:5800 -> 192.168.1.101:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.1.101;branch=z9hG4bK3ab5.9b17c4a1.0;received=233.32.345.5.
Via: SIP/2.0/UDP 192.168.1.100:26682;received=116.24.163.21;branch=z9hG4bK-d87543-1a09c008b901bc5c-1--d87543-;rport=2751.
Record-Route: <sip:192.168.1.101;lr=on;ftag=b81a6b5e;nat=yes>.
From: "1000" <sip:1000@233.32.345.5:5060>;tag=b81a6b5e.
To: "0" <sip:0@233.32.345.5:5060>;tag=Sy7K9eUFg61tB.
Call-ID: ODRiMGUzMGFiZDg2OGU0OGNiYmE0MWY5OWRkMTMxOTA..
CSeq: 2 INVITE.
Contact: <sip:mod_sofia@233.32.345.5:5800;transport=udp>.
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-10454M.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO.
Supported: timer, precondition, path, replaces.
Allow-Events: talk.
Session-Expires: 120;refresher=uas.
Min-SE: 120.
Content-Type: application/sdp.
Content-Disposition: session.
Content-Length: 269.
.
v=0.
o=FreeSWITCH 5494423604621376967 2638962022927722250 IN IP4 233.32.345.5.
s=FreeSWITCH.
c=IN IP4 233.32.345.5.
t=0 0.
m=audio 10272 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
 
Here is the sip trace from opensips to xlite.  The contact in 200OK has public ip:
U 192.168.1.101:5060 -> 116.24.163.21:2751
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.1.100:26682;received=116.24.163.21;branch=z9hG4bK-d87543-1a09c008b901bc5c-1--d87543-;rport=2751.
Record-Route: <sip:192.168.1.101;lr=on;ftag=b81a6b5e;nat=yes>.
From: "1000" <sip:1000@233.32.345.5:5060>;tag=b81a6b5e.
To: "0" <sip:0@233.32.345.5:5060>;tag=Sy7K9eUFg61tB.
Call-ID: ODRiMGUzMGFiZDg2OGU0OGNiYmE0MWY5OWRkMTMxOTA..
CSeq: 2 INVITE.
Contact: <sip:mod_sofia@233.32.345.5:5800;transport=udp>.
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-10454M.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO.
Supported: timer, precondition, path, replaces.
Allow-Events: talk.
Session-Expires: 120;refresher=uas.
Min-SE: 120.
Content-Type: application/sdp.
Content-Disposition: session.
Content-Length: 269.
.
v=0.
o=FreeSWITCH 5494423604621376967 2638962022927722250 IN IP4 233.32.345.5.
s=FreeSWITCH.
c=IN IP4 233.32.345.5.
t=0 0.
m=audio 10272 RTP/AVP 0 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.

It looks to like it is fine. 
 
JB
 
 
On Thu, Nov 27, 2008 at 10:48 PM, Iñaki Baz Castillo <[hidden email]> wrote:
El Jueves, 27 de Noviembre de 2008, Juan Backson escribió:
> In my onreply_route, I have:
>  
> onreply_route[1] {
> fix_nated_contact();
> exit;
>
> }
>  
> But that alone does not work.

Can you check it by doing a SIP capture? the Contact in 200 arriving to
OpenSIPS will contain a private IP, while the Contact in 200 leaving OpenSIPS
will contain a public IP (should contain).

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fixing the Contact Header for NAT

Iñaki Baz Castillo
El Jueves, 27 de Noviembre de 2008, Juan Backson escribió:

The UAC receive this 200 OK:

  Record-Route: <sip:192.168.1.101;lr=on;ftag=b81a6b5e;nat=yes>.
  Contact: <sip:mod_sofia@233.32.345.5:5800;transport=udp>.

So this will create an ACK:

  ACK sip:mod_sofia@233.32.345.5:5800;transport=udp SIP/2.0
  Route: <sip:192.168.1.101;lr=on;ftag=b81a6b5e;nat=yes>

So this ACK will be sent to 192.168.1.101 (OpenSIPS), and OpenSIPS will
forward it to 233.32.345.5:5800.
Can you verify if this ACK is doing that?



--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fixing the Contact Header for NAT

Juan Backson
Hi Inaki,
 
Using wireshark in the nated client's box, I can see that it is getting the 200OK, but the client is not sending the ACK back.  I am kind of clueless on why it is happening like that.  What do you think maybe causing this problem?  Here is teh 200OK the nated client is getting:
 
 
[hidden email] 200 OK
Via: SIP/2.0/UDP 192.168.1.100:10314;received=121.15.89.95;branch=z9hG4bK-d87543-822f892d753fdb57-1--d87543-;rport=10152
Record-Route: <sip:192.168.1.101;lr=on;ftag=795a0d32;nat=yes>
From: "1000" <sip:1000@233.32.345.5:5060>;tag=795a0d32
To: "0" <sip:0@233.32.345.5:5060>;tag=c90BpypDcDXZc
Call-ID: MDFjZjk0ZjIyYjQ4MTU4NWUxNjEzYjc0MmI0MWU5ZWE.
CSeq: 2 INVITE
Contact: <sip:mod_sofia@233.32.345.5:5800;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-10454M
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO
Supported: timer, precondition, path, replaces
Allow-Events: talk
Session-Expires: 120;refresher=uas
Min-SE: 120
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 269
v=0
o=FreeSWITCH 5749698493361694539 8708172188234254362 IN IP4 233.32.345.5
s=FreeSWITCH
c=IN IP4 61.141.158.178
t=0 0
m=audio 15000 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20

On Thu, Nov 27, 2008 at 11:10 PM, Iñaki Baz Castillo <[hidden email]> wrote:
El Jueves, 27 de Noviembre de 2008, Juan Backson escribió:

The UAC receive this 200 OK:

 Record-Route: <sip:192.168.1.101;lr=on;ftag=b81a6b5e;nat=yes>.
 Contact: <sip:mod_sofia@233.32.345.5:5800;transport=udp>.

So this will create an ACK:

 ACK sip:mod_sofia@233.32.345.5:5800;transport=udp SIP/2.0
 Route: <sip:192.168.1.101;lr=on;ftag=b81a6b5e;nat=yes>

So this ACK will be sent to 192.168.1.101 (OpenSIPS), and OpenSIPS will
forward it to 233.32.345.5:5800.
Can you verify if this ACK is doing that?



--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fixing the Contact Header for NAT

Iñaki Baz Castillo
El Viernes, 28 de Noviembre de 2008, Juan Backson escribió:
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP
> 192.168.1.100:10314;received=121.15.89.95;branch=z9hG4bK-d87543-822f892d753
>fdb57-1--d87543-;rport=10152
> Record-Route: <sip:192.168.1.101;lr=on;ftag=795a0d32;nat=yes>

This Record-Route means that the UAC MUST send the ACK to address
192.168.1.101 adding a Route header with same content. Is it feasible for the
UAC to send the ACK to that private address?


> Contact: <sip:mod_sofia@233.32.345.5:5800;transport=udp>

This Contact means that, when the ACK arrives to the proxy, it must forward it
to address 233.32.345.5:5800 (since proxy does loose_routing and deletes top
Route).

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fixing the Contact Header for NAT

Juan Backson
Hi Inaki
 
Thank you for taking a look at the problem.  I get that it is the Record-Route that is not pointing back to opensips's public address and instead it is using opensips private address. 
 
The only place that I specified the private address 192.168.1.101 is when I start up opensips with the command:
/usr/local/sbin/opensips -l 192.168.1.101:5060 -f opensips.cfg
If I changed that to /usr/local/sbin/opensips -l 233.32.345.5:5060 -f opensips.cfg, I am getting error saying:
ERROR:core;udp_init: bind(5,0x76512c,16) on 233.32.345.5: Cannot assign requested address.
 
Is this the place where my setup is having problem or is this something else? 
 
Thanks alot for all your kind help.
 
JB

On Fri, Nov 28, 2008 at 8:23 PM, Iñaki Baz Castillo <[hidden email]> wrote:
El Viernes, 28 de Noviembre de 2008, Juan Backson escribió:
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP
> 192.168.1.100:10314;received=121.15.89.95;branch=z9hG4bK-d87543-822f892d753
>fdb57-1--d87543-;rport=10152
> Record-Route: <sip:192.168.1.101;lr=on;ftag=795a0d32;nat=yes>

This Record-Route means that the UAC MUST send the ACK to address
192.168.1.101 adding a Route header with same content. Is it feasible for the
UAC to send the ACK to that private address?


> Contact: <sip:mod_sofia@233.32.345.5:5800;transport=udp>

This Contact means that, when the ACK arrives to the proxy, it must forward it
to address 233.32.345.5:5800 (since proxy does loose_routing and deletes top
Route).

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fixing the Contact Header for NAT

Iñaki Baz Castillo
El Viernes, 28 de Noviembre de 2008, Juan Backson escribió:
> Thank you for taking a look at the problem.  I get that it is the
> Record-Route that is not pointing back to opensips's public address and
> instead it is using opensips private address. 

Well, which is the REAL IP of OpenSIPS? a private or public one? both?


> The only place that I specified the private address 192.168.1.101 is when I
> start up opensips with the command: /usr/local/sbin/opensips -l
> 192.168.1.101:5060 -f opensips.cfg
> If I changed that to /usr/local/sbin/opensips -l 233.32.345.5:5060 -f
> opensips.cfg, I am getting error saying: ERROR:core;udp_init:
> bind(5,0x76512c,16) on 233.32.345.5: Cannot assign requested address.

So OpenSIPS host has not that public IP, is it?


> Is this the place where my setup is having problem or is this something
> else? 

In case OpenSIPS is behind NAT and the client has public IP is really
difficult. The Record-Route added by OpenSIPS must point to the mapped public
IP (the source IP the client will see). This can be achieved manually with a
function in "rr" module.
But be carefull if you also have natted clients since if they do a request,
they must see a Record-Route (in the 200 OK they receive) pointing to the
private address of the proxy, not the public one.





--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fixing the Contact Header for NAT

Juan Backson
Hi Inaki,
 
Thanks again for your help.  I still have a bit of problem:
 
> Record-Route that is not pointing back to opensips's public address and
> instead it is using opensips private address. 

Well, which is the REAL IP of OpenSIPS? a private or public one? both?
 
 
 233.32.345.5:5060  is the real ip and 192.168.1.101:5060 is the private IP.
 
> If I changed that to /usr/local/sbin/opensips -l 233.32.345.5:5060 -f
> opensips.cfg, I am getting error saying: ERROR:core;udp_init:
> bind(5,0x76512c,16) on 233.32.345.5: Cannot assign requested address.

So OpenSIPS host has not that public IP, is it?
 
 
The opensips host does not have that IP.  The router points the public IP to the opensips box only for port 5060.
 


> Is this the place where my setup is having problem or is this something
> else? 

In case OpenSIPS is behind NAT and the client has public IP is really
difficult. The Record-Route added by OpenSIPS must point to the mapped public
IP (the source IP the client will see). This can be achieved manually with a
function in "rr" module.
But be carefull if you also have natted clients since if they do a request,
they must see a Record-Route (in the 200 OK they receive) pointing to the
private address of the proxy, not the public one.

 
 
I tried using record_route_preset("233.32.345.5:5060") in the onreply_route, so when 200OK passes through opensips, it will hange the record route to is public IP, but it seems like this command can't be used in the block.  Is there any other function that I can use to see the value of record route?
 
I am not sure about the last one.  In my situation, the SUC is inside one nat and opensips is within another nat.  Can it work that way?
 
 
Thanks alot for all your help.
 
JB
 




--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fixing the Contact Header for NAT

Iñaki Baz Castillo
El Viernes, 28 de Noviembre de 2008, Juan Backson escribió:
> I tried using record_route_preset("233.32.345.5:5060") in the
> onreply_route, so when 200OK passes through opensips, it will hange the
> record route to is public IP, but it seems like this command can't be used
> in the block.  Is there any other function that I can use to see the value
> of record route?

Not sure, I've never handled this scenario.


> I am not sure about the last one.  In my situation, the SUC is inside one
> nat and opensips is within another nat.  Can it work that way?

My recommendation: do whatever you can in order to put the proxy with a public
IP.

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users