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@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@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@sip.xyz.com;user=phone>;tag=10f10cec586cbf45
           SIP from address: sip:88008@sip.xyz.com
           SIP tag: 10f10cec586cbf45
       To: "test-gxp2000" <sip:88009@sip.xyz.com;user=phone>;tag=c6bad1edef48137f
           SIP Display info: "test-gxp2000"             SIP to address: sip:88009@sip.xyz.com
           SIP tag: c6bad1edef48137f
       Contact: <sip:88008@x.x.x.x70:1025>
           Contact Binding: <sip:88008@x.x.x.x70:1025>
               URI: <sip:88008@x.x.x.x70:1025>
                   SIP contact address: sip:88008@x.x.x.x70:1025
       Supported: replaces, timer
       Call-ID: 98176a3a3b1280d6@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@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
     
          

  
_______________________________________________
Serusers mailing list
Serusers@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers