[Serusers] on hold problem
Atle Samuelsen
clona at cyberhouse.no
Mon Oct 30 12:54:40 CET 2006
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.
-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
More information about the sr-users
mailing list