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

Fri Sep 25 03:23:10 CEST 2009

Daniel,
As usual your knowledge is greatly appreciated.  This type of
community support is the reason I chose Kamailio over OpenSIPs.  Every
time I have had an issue you (or someone) has been there to help me
out.  It gives me a great level of comfort to know that a core
component of our network has you guys standing behind it.

Thank You!
-Geoff

On Thu, Sep 24, 2009 at 5:25 PM, Daniel-Constantin Mierla
<miconda at gmail.com> wrote:
> There is something wrong upstream, in the carrier network.
>
> One observation -- the ACK is looping on .189.92 -- there are two Via
> headers.
>
> Since the contact from 200ok is lost, the proxy does not how to handle the
> ACK which is part of INVITE dialog. You have to ask the carrier to fix it in
> its side. It is not much you can do unless you try some hacks, e.g., use a
> htable to store target asterisk based on callid, detect bad ACK and forward
> them using the IP from htable.
>
> However, you probably have to do the same hacks for BYE (and other in-dialog
> requests), when coming from carrier.
>
> Cheers,
> Daniel
>
>
> On 24.09.2009 23:11 Uhr, Geoffrey Mina wrote:
>>
>> 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/
>>>
>>>
>>>
>
> --
> Daniel-Constantin Mierla
> * Kamailio SIP Masterclass, Nov 9-13, 2009, Berlin
> * http://www.asipto.com/index.php/sip-router-masterclass/
>
>