Hello, I am wondering if anyone can help me determine what the problem with my SIP signaling is here. I have attached two Excel files (can provide other formats if someone doesn't have Excel). The environments in both scenarios are almost identical... although I am dealing with two different carriers upstream.
In my environment, 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.
The two XLS files (Success.xls) and (Fail.xls) have sip_trace information for the transactions. As you can see in the Fail.xls, the ACK to the 200 OK gets looped back to the Kamailio server and never ends up reaching the Asterisk machine. In the Success.xls, this doesn't happen. The only thing I can see that's different is the Success carrier appears to be replacing the RURI in the ACK with the value of the Contact header... in the failed one, the RURI of the ACK is the IP of my Kamailio gateway.
I have read through the RFC 3261 to try and figure out what is breaking this, but haven't been able to. I basically need to determine if the signalling is correct... what is wrong with my config... and if the signalling is wrong, what the carrier is doing incorrectly.
Thanks in advance! Geoff
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. On the carrier that isn't working, the RURI in the ACK is just the IP of my Kamailio server. Here is the relevant part of my route() method which should catch all the ACK routing:
if(has_totag()) { ## ## If we are in-dialog loose_route() should return true and we should ## end up inside next IF. ## if (loose_route()) { xlog("L_INFO", "Loose route has returned true, attempting routing.\n");
## Do Accounting ## if(is_method("BYE")){setflag(2);}
route(3); //this just does a t_relay() with some extra logging exit; }
if ( is_method("ACK") ) { # relay only ACKs belonging to an active transaction # - otherwise we have no routing info for it (should have # gone via above loose_route() IF) if ( t_check_trans() ) { t_relay(); } exit; }
## ## within-dialog messages without Route are rejected ## sl_send_reply("404","Not here"); exit; }
I have read through the RFC 3261 to try and figure out what is breaking this, but haven't been able to. I basically need to determine if the signalling is correct... what is wrong with my config... and if the signalling is wrong, what the carrier is doing incorrectly.
Thanks in advance! Geoff
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
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@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@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@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@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@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@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@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/
Sorry... one typo in there. The second 200 OK block is really supposed to be labeled "Kamailio to Carrier". Apologies.
On Thu, Sep 24, 2009 at 5:11 PM, Geoffrey Mina geoffreymina@gmail.com 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@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@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@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@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@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@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@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/
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@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@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@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@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@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@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@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, 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@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@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@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@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@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@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@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@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/
Daniel-Constantin Mierla schrieb:
There is something wrong upstream, in the carrier network.
One observation -- the ACK is looping on .189.92 -- there are two Via headers.
Indeed - totally crap :-)
------------------------------------------------- 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@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
Also Route header is missing and wrong RURI.
klaus
My advice would be to get the carrier to fix the buggy stack on their equipment, not to try to hack around it in various kludgy ways.
In general, if you're going to use some sort of SIP network element to deal with interop bugs, a proxy is not the best thing to use, anyhow. A B2BUA - preferably a "fat" one (less transparent than a "thin" one) - that is tolerant and can normalise some of these interop bugs toward the other call leg would be ideal.
In this case, the problem is too fundamental for any UA to have to reasonably cope with it, so that's irrelevant. But it is a best practice in principle, at least in my opinion. A proxy is more or less constrained to relay the requests and replies exactly as it receives them, and although the IETF SIP WG keeps approving kludgy hacks for unanticipated functional needs - like the draft (is it an RFC now?) that allows a proxy to modify the From and To headers - the fundamental precept here is a misguided one.
-- Alex
Daniel-Constantin Mierla 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.
Sounds like the carrier tries to do NAT traversal (fixing contact) although it should not.
regards klaus
Geoffrey Mina schrieb:
Hello, I am wondering if anyone can help me determine what the problem with my SIP signaling is here. I have attached two Excel files (can provide other formats if someone doesn't have Excel). The environments in both scenarios are almost identical... although I am dealing with two different carriers upstream.
In my environment, 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.
The two XLS files (Success.xls) and (Fail.xls) have sip_trace information for the transactions. As you can see in the Fail.xls, the ACK to the 200 OK gets looped back to the Kamailio server and never ends up reaching the Asterisk machine. In the Success.xls, this doesn't happen. The only thing I can see that's different is the Success carrier appears to be replacing the RURI in the ACK with the value of the Contact header... in the failed one, the RURI of the ACK is the IP of my Kamailio gateway.
I have read through the RFC 3261 to try and figure out what is breaking this, but haven't been able to. I basically need to determine if the signalling is correct... what is wrong with my config... and if the signalling is wrong, what the carrier is doing incorrectly.
Thanks in advance! Geoff
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
-
Alex Balashov -
Daniel-Constantin Mierla -
Geoffrey Mina -
Klaus Darilion