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