Thanks. Here is the relevant bits of the failed SIP session
------------------------------------------------- INVITE Carrier To Kamailio: ------------------------------------------------- INVITE sip:+18889160...@208.72.190.171:5060 SIP/2.0 Record-Route: <sip:208.72.189.92;lr=on;ftag=f3ec973c-251ccd56-7c640a0a> Record-Route: <sip:208.72.190.201;lr=on> t: <sip:+18889160...@208.72.190.201:5060;user=phone> f: <sip:+19496776...@10.10.100.124:5060;user=phone>;tag=f3ec973c-251ccd56-7c640a0a Remote-Party-Id: <sip:+19496776...@10.10.100.124:5060;user=phone>;screen=yes;id-type=subscriber;party=calling;privacy=off i: 01263185-ac-251cc...@10.10.100.124 CSeq: 1027265 INVITE Via: SIP/2.0/UDP 208.72.189.92;branch=z9hG4bK4ffc.321fc1c6.0 Via: SIP/2.0/UDP 208.72.190.201;branch=z9hG4bK4ffc.0f42a522.0 v: SIP/2.0/UDP 10.10.100.124:5060;branch=z9hG4bK009cc5864d6d3965 Max-Forwards: 68 m: <sip:+19496776...@10.10.100.124:5060;user=phone> k: replaces c: application/sdp Accept: application/sdp Accept-Encoding: Accept-Language: en User-Agent: Lucent-Universal-Gateway l: 253 ------------------------------------------------- INVITE Kamailio To Asterisk : ------------------------------------------------- INVITE sip:+18889160...@208.72.190.183:5060 SIP/2.0 Record-Route: <sip:208.72.190.171;lr;ftag=f3ec973c-251ccd56-7c640a0a> Record-Route: <sip:208.72.189.92;lr=on;ftag=f3ec973c-251ccd56-7c640a0a> Record-Route: <sip:208.72.190.201;lr=on> t: <sip:+18889160...@208.72.190.201:5060;user=phone> f: <sip:+19496776...@10.10.100.124:5060;user=phone>;tag=f3ec973c-251ccd56-7c640a0a Remote-Party-Id: <sip:+19496776...@10.10.100.124:5060;user=phone>;screen=yes;id-type=subscriber;party=calling;privacy=off i: 01263185-ac-251cc...@10.10.100.124 CSeq: 1027265 INVITE Via: SIP/2.0/UDP 208.72.190.171;branch=z9hG4bK4ffc.659965f3.0 Via: SIP/2.0/UDP 208.72.189.92;branch=z9hG4bK4ffc.321fc1c6.0 Via: SIP/2.0/UDP 208.72.190.201;branch=z9hG4bK4ffc.0f42a522.0 v: SIP/2.0/UDP 10.10.100.124:5060;branch=z9hG4bK009cc5864d6d3965 Max-Forwards: 67 m: <sip:+19496776...@10.10.100.124:5060;user=phone> k: replaces c: application/sdp Accept: application/sdp Accept-Encoding: Accept-Language: en User-Agent: Lucent-Universal-Gateway l: 253 ------------------------------------------------- OK Asterisk To Kamailio: ------------------------------------------------- SIP/2.0 200 OK Via: SIP/2.0/UDP 208.72.190.171;branch=z9hG4bK4ffc.659965f3.0;received=208.72.190.171 Via: SIP/2.0/UDP 208.72.189.92;branch=z9hG4bK4ffc.321fc1c6.0 Via: SIP/2.0/UDP 208.72.190.201;branch=z9hG4bK4ffc.0f42a522.0 Via: SIP/2.0/UDP 10.10.100.124:5060;branch=z9hG4bK009cc5864d6d3965 Record-Route: <sip:208.72.190.171;lr;ftag=f3ec973c-251ccd56-7c640a0a> Record-Route: <sip:208.72.189.92;lr=on;ftag=f3ec973c-251ccd56-7c640a0a> Record-Route: <sip:208.72.190.201;lr=on> From: <sip:+19496776...@10.10.100.124:5060;user=phone>;tag=f3ec973c-251ccd56-7c640a0a To: <sip:+18889160...@208.72.190.201:5060;user=phone>;tag=as233f7874 Call-ID: 01263185-ac-251cc...@10.10.100.124 CSeq: 1027265 INVITE User-Agent: G-Tel v1.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:+18889160...@208.72.190.183> Content-Type: application/sdp Content-Length: 244 ------------------------------------------------- OK Kamilio to Asterisk: ------------------------------------------------- SIP/2.0 200 OK Via: SIP/2.0/UDP 208.72.189.92;branch=z9hG4bK4ffc.321fc1c6.0 Via: SIP/2.0/UDP 208.72.190.201;branch=z9hG4bK4ffc.0f42a522.0 Via: SIP/2.0/UDP 10.10.100.124:5060;branch=z9hG4bK009cc5864d6d3965 Record-Route: <sip:208.72.190.171;lr;ftag=f3ec973c-251ccd56-7c640a0a> Record-Route: <sip:208.72.189.92;lr=on;ftag=f3ec973c-251ccd56-7c640a0a> Record-Route: <sip:208.72.190.201;lr=on> From: <sip:+19496776...@10.10.100.124:5060;user=phone>;tag=f3ec973c-251ccd56-7c640a0a To: <sip:+18889160...@208.72.190.201:5060;user=phone>;tag=as233f7874 Call-ID: 01263185-ac-251cc...@10.10.100.124 CSeq: 1027265 INVITE User-Agent: G-Tel v1.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:+18889160...@208.72.190.183> Content-Type: application/sdp Content-Length: 244 ------------------------------------------------- ACK Carrier to Kamailio: ------------------------------------------------- ACK sip:208.72.190.171;lr;ftag=f3ec973c-251ccd56-7c640a0a SIP/2.0 t: <sip:+18889160...@208.72.190.201:5060;user=phone>;tag=as233f7874 f: <sip:+19496776...@10.10.100.124:5060;user=phone>;tag=f3ec973c-251ccd56-7c640a0a i: 01263185-ac-251cc...@10.10.100.124 CSeq: 1027265 ACK Via: SIP/2.0/UDP 208.72.189.92;branch=z9hG4bK4ffc.321fc1c6.2 Via: SIP/2.0/UDP 208.72.189.92;branch=z9hG4bK4ffc.321fc1c6.2 Via: SIP/2.0/UDP 208.72.190.201;branch=z9hG4bK4ffc.0f42a522.2 v: SIP/2.0/UDP 10.10.100.124:5060;branch=z9hG4bK009cc59b4f4d6d16 Max-Forwards: 67 User-Agent: Lucent-Universal-Gateway l: 0 ------------------------------------------------- ACK Kamilio to Kamailio: (we are no into the loop) ------------------------------------------------- ACK sip:208.72.190.171;lr;ftag=f3ec973c-251ccd56-7c640a0a SIP/2.0 t: <sip:+18889160...@208.72.190.201:5060;user=phone>;tag=as233f7874 f: <sip:+19496776...@10.10.100.124:5060;user=phone>;tag=f3ec973c-251ccd56-7c640a0a i: 01263185-ac-251cc...@10.10.100.124 CSeq: 1027265 ACK Via: SIP/2.0/UDP 208.72.190.171;branch=z9hG4bK4ffc.659965f3.2 Via: SIP/2.0/UDP 208.72.189.92;branch=z9hG4bK4ffc.321fc1c6.2 Via: SIP/2.0/UDP 208.72.189.92;branch=z9hG4bK4ffc.321fc1c6.2 Via: SIP/2.0/UDP 208.72.190.201;branch=z9hG4bK4ffc.0f42a522.2 v: SIP/2.0/UDP 10.10.100.124:5060;branch=z9hG4bK009cc59b4f4d6d16 Max-Forwards: 66 User-Agent: Lucent-Universal-Gateway l: 0 On Thu, Sep 24, 2009 at 4:51 PM, Daniel-Constantin Mierla <mico...@gmail.com> wrote: > Hello, > > On 24.09.2009 22:36 Uhr, Geoffrey Mina wrote: >> >> Hello, >> I am wondering if anyone can help me determine what the problem is >> with some SIP signaling. I have two environments and in both >> scenarios my configuration and topology are almost identical... >> although I am dealing with two different carriers upstream. >> >> In my environments, I have Kamailio (1.5) sitting in front of a >> multitude of Asterisk machines. I am using the dispatcher module to >> distribute INVITE requests across the network. I am doing some >> interop with a new carrier and we are struggling a bit with some >> looping scenarios. They are sending invites to my Kamailio server, I >> am forwarding to asterisk. >> >> On the one that is not working, I am seeing the following in sip_trace >> >> INVITE (from carrier) >> INVITE (to asterisk) >> 100 TRYING (from asterisk) >> 200 OK (from asterisk) >> 200 OK (to carrier) >> ACK (from carrier) - this is where the loop starts. Kamailio sends >> the ACK to itself until the "max-hops" is reached... then it dies >> ACK (from itself to itself) >> ACK (from itself to itself) >> ACK (from itself to itself) >> ... >> 200 OK (from asterisk - because it never got ACK) >> 200 OK (to carrier) >> ACK (from carrier) - again the loop. >> ACK (from itself to itself) >> >> >> The only thing I can see that is different between the two carriers >> (working and non-working) is that the working carrier appears to send >> the ACK with an RURI equivalent to the Contact: header from the 200 >> OK. > > this is the correct behavior for loose routing. > > it looks like the one of the devices (very likely the carrier) is doing bad > record routing handling. There might be a strict router combined with a > loose router. > > I could really follow the sip messages in the excel you sent, maybe you can > paste text here in email the invite, the 200ok and ACK captured on kamailio > server. Then is easier to troubleshoot. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla > * Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin > * http://www.asipto.com/index.php/sip-router-masterclass/ > > _______________________________________________ Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
