[Serusers] on hold problem
Greger V. Teigre
greger at teigre.com
Tue Oct 31 11:34:50 CET 2006
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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20061031/30f28108/attachment.htm>
More information about the sr-users
mailing list