[Serusers] on hold problem
Shaun Hofer
shaun.hofer at voxpak.com
Wed Nov 1 01:58:14 CET 2006
I'm wanting to check for the tag=xyz in from and to fields so that I know its a on going conversation/dialog.
If it's ongoing conversation and reINVITES are sent, then the call will use mediaproxy. Very few calls should have reINVITES that aren't already NAT'ed.
By doing this I catch the off hold reINVITES and put them through mediaproxy. This may mean abit of extra load for mediaproxy in the long run.
Thus far I havn't had any problems with this. I guess I could get rid of the has_totag() seeing its already checked for.
Heres my whole loose route:
if (loose_route()) {
if (!has_totag()) {
sl_send_reply("403", "Forbidden");
break;
};
if (method=="INVITE") {
# some extra checks on reINVITE's
if ((method=="INVITE" || method=="REFER") && !has_totag()) {
if (!proxy_authorize("","subscriber")) {
proxy_challenge("","0");
break;
} else if (!check_from()) {
sl_send_reply("403", "Use From=ID");
break;
};
consume_credentials();
};
if (client_nat_test("3")||search("^Route:.*;nat=yes")){
setflag(6);
use_media_proxy();
# Checks its ongoing conversation thats been NAT'ed, eg taken off hold
} else if(has_totag() && search("[Ff]rom:.*;tag=.*")){
setflag(6);
use_media_proxy();
};
};
route(1);
break;
};
On Tuesday 31 October 2006 20:34, Greger V. Teigre wrote:
> I'm not sure what the search for a from tag really does for you?
> if(loose_route() && method=="INVITE" && has_totag()) will catch all
> in-dialog INVITEs in general.
> When does the in-dialog INVITE not have a from tag?
> g-)
>
> Shaun Hofer wrote:
> > It was suggested to me (on irc) that I should use the tag in the To and From
> > fields to see if the INVITE belonged to a on going conversation. Thus catch
> > the take off hold INVITE.
> > In my loose route under INVITE section I have:
> > if (client_nat_test("3")||search("^Route:.*;nat=yes")){
> > setflag(6);
> > use_media_proxy();
> > } else if(has_totag() && search("[Ff]rom:.*;tag=.*")){
> > setflag(6);
> > use_media_proxy();
> > };
> >
> > This seems to work fine. It will mean tiny abit of extra load if the person
> > isn't nated and uses on hold, but I can live with that.
> >
> >
> > On Monday 30 October 2006 21:54, Atle Samuelsen wrote:
> >
> >> Hi,
> >>
> >> * Greger V. Teigre <greger at teigre.com> [061030 12:44]:
> >>
> >>> That's what the nat=yes is for. This means that you have a client that
> >>> does not keep the route parameter as it should. Depending on which UA
> >>> puts on hold (NATed or not), you may not be able to use the NAT tests to
> >>> detect NATed (because they are not).
> >>> A workaround would be to lookup("location") for reINVITEs.
> >>>
> >> This could cause intresting other issues. If a user has 2 phones
> >> registerd. the reinvite might get forked to both phones, wich (in a case
> >> I saw) made one phone ring, while the other picked up the call.
> >>
> > This looks abit trickie. I'm abit lost as how lookup('location') is going to
> > help mediaproxy (maybe I'm missing something here). Both parties are NAT'ed,
> > the problem is that mediaproxy isn't being called on the reINVITE so this
> > NAt'ed session through mediaproxy can keep going.
> >
> >
> >
> >> -A
> >>
> >>
> >>> g-)
> >>>
> >>> Shaun Hofer wrote:
> >>>
> >>>> I found nat=yes was set for the first reINVITE to set hold but not the
> >>>> second. All the nat tests (tried all the modes for client_nat_test and
> >>>> nat_uac_test) seem to fail picking up that the second reINVITE (take
> >>>> off hold INVITE) is being nated, thus mediaproxy isn't used. From what
> >>>> I can see in the packet captures and what the nat tests test for, they
> >>>> would fail to pick up the fact that it is NAt'ed. (Packet Capture at
> >>>> the bottom)
> >>>>
> >>>> At the monment I'm trying to figure a way to compare the owner field
> >>>> with source ip address. These two IP address are different if NAT'ed.
> >>>> Owner is the private IP address while the source IP has the NAT public
> >>>> IP address.
> >>>>
> >>>> Been trying something like: if(!search("o=[0-9]* [0-9]* [0-9]* IN IP4
> >>>> \Q$src_ip\E$")) { setflag(6);
> >>>> use_media_proxy();
> >>>> }
> >>>> The problem I'm facing is it seems that search doesn't take in variables
> >>>> ($src_ip). The \Q and \E are used to quote thus avoid escaping the
> >>>> dots.
> >>>> Is there way for search to take in variables ? Or better way to compare
> >>>> these values?
> >>>>
> >>>> Another idea that came to me: Would checking the ruri or Route for ser's
> >>>> server ip address be better way, or is this abit dangerous to be
> >>>> routing/mediaproxying according to this?
> >>>> -Shaun
> >>>>
> >>>>
> >>>> The Following is a Packet Capture of a packet sent to SER to take the
> >>>> phones off hold (x.x.x.x3 = sip.xyz.com):
> >>>>
> >>>> Session Initiation Protocol
> >>>> Request-Line: INVITE sip:88009 at x.x.x.x6:5516;user=phone SIP/2.0
> >>>> Method: INVITE
> >>>> Resent Packet: False
> >>>> Message Header
> >>>> Via: SIP/2.0/UDP x.x.x.x70:1025;branch=z9hG4bK2d93cdb6357ddb75
> >>>> Route: <sip:x.x.x.x3;ftag=10f10cec586cbf45;lr=on>
> >>>> From: <sip:88008 at sip.xyz.com;user=phone>;tag=10f10cec586cbf45
> >>>> SIP from address: sip:88008 at sip.xyz.com
> >>>> SIP tag: 10f10cec586cbf45
> >>>> To: "test-gxp2000"
> >>>> <sip:88009 at sip.xyz.com;user=phone>;tag=c6bad1edef48137f SIP Display
> >>>> info: "test-gxp2000" SIP to address: sip:88009 at sip.xyz.com
> >>>> SIP tag: c6bad1edef48137f
> >>>> Contact: <sip:88008 at x.x.x.x70:1025>
> >>>> Contact Binding: <sip:88008 at x.x.x.x70:1025>
> >>>> URI: <sip:88008 at x.x.x.x70:1025>
> >>>> SIP contact address: sip:88008 at x.x.x.x70:1025
> >>>> Supported: replaces, timer
> >>>> Call-ID: 98176a3a3b1280d6 at 192.168.1.3
> >>>> CSeq: 22284 INVITE
> >>>> User-Agent: Grandstream GXP2000 1.1.0.16
> >>>> Max-Forwards: 70
> >>>> Allow:
> >>>> INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK
> >>>> Content-Type: application/sdp
> >>>> Content-Length: 267
> >>>> Message body
> >>>> Session Description Protocol
> >>>> Session Description Protocol Version (v): 0
> >>>> Owner/Creator, Session Id (o): 88008 8000 8002 IN IP4
> >>>> 10.0.10.111 Owner Username: 88008
> >>>> Session ID: 8000
> >>>> Session Version: 8002
> >>>> Owner Network Type: IN
> >>>> Owner Address Type: IP4
> >>>> Owner Address: 10.0.10.111
> >>>> Session Name (s): SIP Call
> >>>> Connection Information (c): IN IP4 x.x.x.x70
> >>>> Connection Network Type: IN
> >>>> Connection Address Type: IP4
> >>>> Connection Address: x.x.x.x70
> >>>> Time Description, active time (t): 0 0
> >>>> Session Start Time: 0
> >>>> Session Stop Time: 0
> >>>> ---snip----
> >>>>
> >>>> On Wednesday 25 October 2006 17:14, Greger V. Teigre wrote:
> >>>>
> >>>>> - Make sure nat=yes is found in the Route set of the reINVITE.
> >>>>> - Look at the mediaproxy messages in /var/log/messages, you should get
> >>>>> one for the INVITE and then one for the OK, but not '' empty response.
> >>>>> g-)
> >>>>>
> >>>>> Shaun Hofer wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I've been having a problem, where audio is lost either in one or both
> >>>>>> directions when conversaion is taken off 'hold'. The parties are both
> >>>>>> behind NAT and depending UA as whether one or both loose audio. From
> >>>>>> what I can tell its to do with my loose route and nathelper, and how
> >>>>>> my ser.cfg deals with the take off hold INVITE from the phones. When
> >>>>>> the call is taken off hold the rtp streams aren't setup properly
> >>>>>> again (eg not using mediaproxy correctly). What is the best way to
> >>>>>> solve this problem?
> >>>>>>
> >>>>>> I've seen similarly posts to the mailing list about this problem with
> >>>>>> no solution posted.
> >>>>>> http://lists.iptel.org/pipermail/serusers/2006-March/027424.html
> >>>>>> http://lists.iptel.org/pipermail/serusers/2006-April/027885.html
> >>>>>> http://lists.iptel.org/pipermail/serusers/2006-May/028407.html
> >>>>>>
> >>>>>> Thanks
> >>>>>> Shaun
> >>>>>>
> >>>>>>
> >>>>>> I have a similarly config to getting started guides ser.cfg
> >>>>>>
> >>>>>> # -----------------------------------------------------------------
> >>>>>> # Loose Route Section
> >>>>>> # -----------------------------------------------------------------
> >>>>>>
> >>>>>> if (loose_route()) {
> >>>>>> if (!has_totag()) {
> >>>>>> sl_send_reply("403", "Forbidden");
> >>>>>> break;
> >>>>>> };
> >>>>>> if (method=="INVITE") {
> >>>>>> if ((method=="INVITE" || method=="REFER")
> >>>>>> && !has_totag()) {
> >>>>>> if (!proxy_authorize("","subscriber"))
> >>>>>> { proxy_challenge("","0"); break;
> >>>>>> } else if (!check_from()) {
> >>>>>> sl_send_reply("403", "Use
> >>>>>> From=ID"); break;
> >>>>>> };
> >>>>>> consume_credentials();
> >>>>>> };
> >>>>>> if
> >>>>>> (client_nat_test("3")||search("^Route:.*;nat=yes")) {
> >>>>>> setflag(6);
> >>>>>> use_media_proxy();
> >>>>>> };
> >>>>>> };
> >>>>>> route(1);
> >>>>>> break;
> >>>>>> };
> >>>>>> _______________________________________________
> >>>>>> Serusers mailing list
> >>>>>> Serusers at lists.iptel.org
> >>>>>> http://lists.iptel.org/mailman/listinfo/serusers
> >>>>>>
> >>> _______________________________________________
> >>> Serusers mailing list
> >>> Serusers at lists.iptel.org
> >>> http://lists.iptel.org/mailman/listinfo/serusers
> >>>
> >
> > _______________________________________________
> > Serusers mailing list
> > Serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> >
> >
> >
>
--
Shaun Hofer
System Administrator
Voxpak Pty Ltd
Telephone: +61 (07) 55913588
Facsimile: +61 (07) 55916588
Email: shaun.hofer at voxpak.com
*******************************************************
If you receive this email by mistake, please notify us and do not make any
use of the email. We do not waive any privilege, confidentiality or
copyright associated with it.
More information about the sr-users
mailing list