The Route header in this scenario is being used by a SIP client using kamailio as the proxy.  You can see that it takes the value of the Route header and uses it as the URI on the outgoing side.

What is causing it to modify the Route header and put it back in?  The first INVITE I supplied is coming into the kamailio server. The second is what t_relay sent upstream. 

Should I just not call the loose_route function and go straight to t_relay after calling remove_hf("Route")?

Thanks. 

Geoff Mina
Founder/CTO
Connect First Inc.
720.335.5924
888.410.3071
gmina@ConnectFirst.com

Sent from my iPhone

On May 2, 2012, at 12:42 AM, Daniel-Constantin Mierla <miconda@gmail.com> wrote:

Hello,

the Route header in initial invite is usually set by phones that have an outbound proxy setting. Kamailio doesn't add any Route header itself, unless append_hf()/insert_hf() is used -- record_route() adds Record-Route headers.

To deal with this case you should do loose_route() only for requests within dialog (those that have To header tag). For the rest just remove the Route header. If you look at default config file in v3.2.x, you will see this kind of processing (just to analyze it, not need to upgrade to 3.2.x).

Cheers,
Daniel

On 5/2/12 12:26 AM, Geoffrey Mina wrote:
Greetings,
I am confused at some functionality I am seeing with Kamailio 1.5.4.  I know this is an old version, but I don't have the time to go through a lengthy upgrade process right now.  The issue I am seeing is that the server is inserting a Route header with it's own IP address for an unknown reason.  Here is the initial invite (removed SDP for simplicity):

INVITE sip:13@67.207.130.146:5060 SIP/2.0
Via: SIP/2.0/UDP 68.64.220.108:5060;branch=z9hG4bK78dd33c6;rport
From: "WIRELESS CALLER" <sip:9546496707@dev-asterisk.mydomain.com>;tag=as1cad6370
To: <sip:13@67.207.130.146:5060>
Contact: <sip:9546496707@68.64.220.108>
Call-ID: 43134ece101abfca6ecab20212295909@dev-asterisk.mydomain.com
CSeq: 102 INVITE
User-Agent: G-Tel v1.0
Max-Forwards: 70
Remote-Party-ID: "WIRELESS CALLER" <sip:9546496707@dev-asterisk.mydomain.com>;privacy=off;screen=no
Date: Tue, 01 May 2012 18:17:50 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Route: <sip:13@boulder-voip.mydomain.com>
P-Account-ID: 99990023
P-Proxy-Route: Yes
Content-Type: application/sdp
Content-Length: 240

The basics of what happen next are:

t_check_trans();
record_route();
remove_hf("P-Proxy-Route");
if(loose_route()){
   route(3);
}


route[3]{
        t_on_reply("1");
        if(!t_relay()){
                sl_reply_error();
        }
}

The INVITE that goes out has the funky Route: header with the Kamailio IP in there.  This is causing problems for some of the upstream proxy servers (obviously). 

INVITE sip:13@boulder-voip.mydomain.com SIP/2.0
Record-Route: <sip:67.207.130.146;lr;ftag=as1cad6370>
Via: SIP/2.0/UDP 67.207.130.146;branch=z9hG4bKf183.456d51e1.0
Via: SIP/2.0/UDP 68.64.220.108:5060;received=68.64.220.108;branch=z9hG4bK78dd33c6;rport=5060
From: "WIRELESS CALLER" <sip:9546496707@dev-asterisk.mydomain.com>;tag=as1cad6370
To: <sip:13@67.207.130.146:5060>
Contact: <sip:9546496707@68.64.220.108>
Call-ID: 43134ece101abfca6ecab20212295909@dev-asterisk.mydomain.com
CSeq: 102 INVITE
User-Agent: G-Tel v1.0
Max-Forwards: 69
Remote-Party-ID: "WIRELESS CALLER" <sip:9546496707@dev-asterisk.mydomain.com>;privacy=off;screen=no
Date: Tue, 01 May 2012 18:17:50 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
P-Account-ID: 99990023
Content-Type: application/sdp
Content-Length: 240
Route: <sip:13@67.207.130.146:5060>


Any idea what may be causing this to happen and how I could prevent it?  I have tried removing the Route header using the remove_hf("Route") before doing the t_relay, but that doesn't seem to help.

Thanks,
Geoff




_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda