[Serusers] on hold problem
Greger V. Teigre
greger at teigre.com
Tue Oct 31 11:28:59 CET 2006
Yes, it has some interesting effects :-) Also, you shouldn't let lookup
change the r-uri (even with no branch).
g-)
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.
>
> -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
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20061031/f6ac622c/attachment.htm>
More information about the sr-users
mailing list