[OpenSIPS-Users] NAT and Re-INVITE
Kennard_White at logitech.com
Kennard_White at logitech.com
Tue Oct 12 21:19:32 CEST 2010
Hi Doug,
Here are the relevant sections (with a lot of other stuff deleted).
Unfortunately, due the embedded biz logic I cannot post whole script.
if (loose_route()) {
if(is_method("INVITE")) {
t_check_trans();
if (check_route_param("mr=1")) {
use_media_proxy();
# Set flag so response will also get proxy applied
setbflag(BFLAG_USED_MPROXY);
};
t_on_reply("reply_reinvite");
t_relay();
exit;
}
Within branch-route for initial INVITE (populated from usrloc):
if ( need-mproxy ) {
use_media_proxy();
add_rr_param(";mr=1");
setbflag(BFLAG_USED_MPROXY);
}
Both the reply handler for invite and reinvite have sections like:
onreply_route[reply_reinvite] {
if (isbflagset(BFLAG_USED_MPROXY)) {
use_media_proxy();
}
}
The logic for "need-mproxy" for me is quite complicated due to the number
of different use cases I have to support. For the case you describe, it is
just the cflag coming from usrloc.
Regarding B's reply's Contact header, I used to do the same with
nat_uac_test() and fix_nated_contact() but eventually gave up on it. As you
say many ALGs break this. (Either out-right corruption or just put the
wrong number in). Also, if B is behind a proxy that does outbound flow
routing (RFC 5626) it will leave the private IP in the Contact header and
the check will false trigger and corrupt the path. I ended up implementing
flow-routing within opensips instead.
Regards,
Kennard
From: Doug <doug at wd.co.za>
To: users at lists.opensips.org
Date: 10/12/2010 11:36 AM
Subject: Re: [OpenSIPS-Users] NAT and Re-INVITE
Sent by: users-bounces at lists.opensips.org
Hi Kennard,
Would you be so kind as to post what you did in regards to the reply
handler? Also do you set the bflag if check_route_param succeeds and then
let your reply handler check for a bflag?
In regards to the private IP address, thats handled easily with the
following:
if(nat_uac_test("1"))
{
fix_nated_contact();
}
I also modded the code of nathelper.c to include a 64 check for
nat_uac_test that checks the port number in the contact header against the
source port of the packet (not sure if this breaks RFC's?), as I had an
issue with a dumb ALG device stuffing up the port in the contact header on
the 180 Ringing. It was suppose to be something like:
sip:xxxx at 1.2.3.4:17319
but instead, came through as:
sip:xxxx at 1.2.3.4:17319319
which just broke everything else, so I added my check and if the contact
header port and source port did not match, I simply called
fix_nated_contact() to resolve it - this fixed the ALG issue, but still
left the re-INVITE issue.
I look forward to your assistance.
Thanks
Doug
On 2010/10/12 8:02 PM, Kennard_White at logitech.com wrote:
Hi Doug,
I had similar problem. My solution is to use record-route variable:
add_rr_param("mr=1") on initial INVITE at same time as first call to
use_media_relay(). The later within loose_route block, I use
check_route_param("mr=1") for re-INVITES and then re-invoke media
relay if found. In that case I also install a reply handler for the
reinvite and set the bflag. The reinvite reply handler then checks
the bflag and invokes use_media_proxy on the reply. That solves the
media problem for me.
How are you handling the private IP in the Contact address in B's 200
response to A's re-INVITE? This contact address will become the R-URI
of all subsequent in-dialog messages from A (e.g., INFO, MESSAGE,
BYE).
Regards,
Kennard
Inactive
hide details for Doug ---10/12/2010 08:47:39 AM---
Hi All,
I've got a problem I'm not 100% sure how to resolve.
Doug ---10/12/2010 08:47:39 AM--- Hi All, I've got a problem I'm not
100% sure how to resolve.
From: Doug <doug at wd.co.za>
To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: 10/12/2010 08:47 AM
Subject: [OpenSIPS-Users] NAT and Re-INVITE
Sent by: users-bounces at lists.opensips.org
Hi All,
I've got a problem I'm not 100% sure how to resolve.
Ok the scenario is, client A is on a public interface, Client B is on
a
private IP address and has cflag 6 set in the location table.
Client A calls Client B via Opensips.
Now during the initial INVITE, opensips locates Client B, loads the
information, and naturally bflag is set to 6 (my NAT flag). This then
triggers mediaproxy to get involved, and the call is established
correctly, media passes from Client A ----> Mediaproxy ----> Client
B.
Now the problem is, the Client A device (Audiocodes ATA) sends a
Re-INVITE to switchover to T.38. The process works pretty much the
same,
but follows the loose_route path due the call already being in a
dialog
(i think thats the right terminology).
Client B receives the Re-INVITE, however, because loose_route doesn't
know about the bflag (I've check with xlog and its not set during
this
phase), mediaproxy is not engaged (as the INVITE is coming form
Client A
who is not behind NAT). So when Client B responds, the SDP is a
private
IP address, and the call falls apart.
Now I suppose what I could do is call "use_media_proxy()" from the
onreply_route if the SDP is RFC1918 (nat_uac_test("8")), however,
this
would engage mediaproxy for only one leg of the call and not the
Client
A leg.
The other option is I can force mediaproxy on all calls, which works,
but now I have to have RTP flowing through my links for devices that
could be speaking directly to each other.
Has anyone had experience with this, or an idea of how to check
during
the loose_route phase if the Client B sisde is behind nat, or set a
flag
that remains consistent throughout the entire call flow (INVITE,
200Ok,
Re-INVITE, 200OK, BYE).
I look forward to your assistance.
Many thanks
Doug
_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
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/20101012/6d1e68b1/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://lists.opensips.org/pipermail/users/attachments/20101012/6d1e68b1/attachment.gif
More information about the Users
mailing list