[Kamailio-Users] Need Assistance Tracking Down A SIP Signaling Problem

Thu Sep 24 23:11:24 CEST 2009

Thanks.  Here is the relevant bits of the failed SIP session

-------------------------------------------------
INVITE Carrier To Kamailio:
-------------------------------------------------
INVITE sip:+18889160750 at 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:+18889160750 at 208.72.190.201:5060;user=phone>
f: <sip:+19496776128 at 10.10.100.124:5060;user=phone>;tag=f3ec973c-251ccd56-7c640a0a
Remote-Party-Id:
<sip:+19496776128 at 10.10.100.124:5060;user=phone>;screen=yes;id-type=subscriber;party=calling;privacy=off
i: 01263185-ac-251ccd56 at 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:+19496776128 at 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:+18889160750 at 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:+18889160750 at 208.72.190.201:5060;user=phone>
f: <sip:+19496776128 at 10.10.100.124:5060;user=phone>;tag=f3ec973c-251ccd56-7c640a0a
Remote-Party-Id:
<sip:+19496776128 at 10.10.100.124:5060;user=phone>;screen=yes;id-type=subscriber;party=calling;privacy=off
i: 01263185-ac-251ccd56 at 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:+19496776128 at 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:+19496776128 at 10.10.100.124:5060;user=phone>;tag=f3ec973c-251ccd56-7c640a0a
To: <sip:+18889160750 at 208.72.190.201:5060;user=phone>;tag=as233f7874
Call-ID: 01263185-ac-251ccd56 at 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:+18889160750 at 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:+19496776128 at 10.10.100.124:5060;user=phone>;tag=f3ec973c-251ccd56-7c640a0a
To: <sip:+18889160750 at 208.72.190.201:5060;user=phone>;tag=as233f7874
Call-ID: 01263185-ac-251ccd56 at 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:+18889160750 at 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:+18889160750 at 208.72.190.201:5060;user=phone>;tag=as233f7874
f: <sip:+19496776128 at 10.10.100.124:5060;user=phone>;tag=f3ec973c-251ccd56-7c640a0a
i: 01263185-ac-251ccd56 at 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:+18889160750 at 208.72.190.201:5060;user=phone>;tag=as233f7874
f: <sip:+19496776128 at 10.10.100.124:5060;user=phone>;tag=f3ec973c-251ccd56-7c640a0a
i: 01263185-ac-251ccd56 at 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
<miconda at 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/
>
>