Hi,
I made a simple SIP test call. The end point reply to kamailio with 180, 200 messages. The end point includes "tag=1_1555_t58918_125k" in TO field of these messages. However, kamailio reply with ACK message that includes a random tag (tag=5f08ae5f) in TO field. This tag is not the same as the one sent by the end point:
1.1.1.1 end-point ip address 2.2.2.2 kamailio ip address
INVITE From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone Call-ID: 9280396221-9479318750707221-11-7604239022
180 From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone;tag=1_1555_t58918_125k Call-ID: 9280396221-9479318750707221-11-7604239022
200 From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone;tag=1_1555_t58918_125k Call-ID: 9280396221-9479318750707221-11-7604239022
ACK From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@2.2.2.2;user=phone;tag=5f08ae5f Call-ID: 9280396221-9479318750707221-11-7604239022
How can I force it to send the correct tag?
Thanks, AR
_________________________________________________________________ Windows Live Hotmail now works up to 70% faster. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_...
Alex,
Are you sure this is not a bug with the other endpoint (the other side of the call)? The end-to-end ACK for the 200 OK would have to originate from it and Kamailio would merely be relaying it. Is it possible that it is in fact that UA which is ignoring the To tag in the 200 OK from 1.1.1.1?
-- Alex
Alex R.S.M wrote:
Hi,
I made a simple SIP test call. The end point reply to kamailio with 180, 200 messages. The end point includes "tag=1_1555_t58918_125k" in TO field of these messages. However, kamailio reply with ACK message that includes a random tag (tag=5f08ae5f) in TO field. This tag is not the same as the one sent by the end point:
1.1.1.1 end-point ip address 2.2.2.2 kamailio ip address
INVITE From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone Call-ID: 9280396221-9479318750707221-11-7604239022
180 From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone;*tag=1_1555_t58918_125k* Call-ID: 9280396221-9479318750707221-11-7604239022
200 From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone;*tag=1_1555_t58918_125k* Call-ID: 9280396221-9479318750707221-11-7604239022
ACK From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@2.2.2.2;user=phone;*tag=5f08ae5f* Call-ID: 9280396221-9479318750707221-11-7604239022
How can I force it to send the correct tag?
Alex,
The other end-point is a softswitch. I made a direct test call excluding kamailio. Everything was fine, calls go thru with correct tag value.
Date: Mon, 17 Nov 2008 10:10:26 -0500 From: abalashov@evaristesys.com To: alex_rsm@hotmail.com CC: users@lists.kamailio.org Subject: Re: [Kamailio-Users] incorrect tag in ACK message
Alex,
Are you sure this is not a bug with the other endpoint (the other side of the call)? The end-to-end ACK for the 200 OK would have to originate from it and Kamailio would merely be relaying it. Is it possible that it is in fact that UA which is ignoring the To tag in the 200 OK from 1.1.1.1?
-- Alex
Alex R.S.M wrote:
Hi,
I made a simple SIP test call. The end point reply to kamailio with 180, 200 messages. The end point includes "tag=1_1555_t58918_125k" in TO field of these messages. However, kamailio reply with ACK message that includes a random tag (tag=5f08ae5f) in TO field. This tag is not the same as the one sent by the end point:
1.1.1.1 end-point ip address 2.2.2.2 kamailio ip address
INVITE From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone Call-ID: 9280396221-9479318750707221-11-7604239022
180 From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone;*tag=1_1555_t58918_125k* Call-ID: 9280396221-9479318750707221-11-7604239022
200 From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone;*tag=1_1555_t58918_125k* Call-ID: 9280396221-9479318750707221-11-7604239022
ACK From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@2.2.2.2;user=phone;*tag=5f08ae5f* Call-ID: 9280396221-9479318750707221-11-7604239022
How can I force it to send the correct tag?
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
_________________________________________________________________ See how Windows® connects the people, information, and fun that are part of your life http://clk.atdmt.com/MRT/go/119463819/direct/01/
So, what you're saying is that the ACK (response to 200 OK from endpoint) from the softswitch comes with a To tag of 1_1555_t58918_125k to Kamailio, but the ACK that Kamailio sends out to the endpoint has an altered To tag? Have you checked?
Alex R.S.M wrote:
Alex,
The other end-point is a softswitch. I made a direct test call excluding kamailio. Everything was fine, calls go thru with correct tag value.
Date: Mon, 17 Nov 2008 10:10:26 -0500 From: abalashov@evaristesys.com To: alex_rsm@hotmail.com CC: users@lists.kamailio.org Subject: Re: [Kamailio-Users] incorrect tag in ACK message
Alex,
Are you sure this is not a bug with the other endpoint (the other side of the call)? The end-to-end ACK for the 200 OK would have to originate from it and Kamailio would merely be relaying it. Is it possible that it is in fact that UA which is ignoring the To tag in the 200 OK from 1.1.1.1?
-- Alex
Alex R.S.M wrote:
Hi,
I made a simple SIP test call. The end point reply to kamailio with
180,
200 messages. The end point includes "tag=1_1555_t58918_125k" in TO field of these messages. However, kamailio reply with ACK message that includes a random tag (tag=5f08ae5f) in TO field. This tag is not the same as the one sent by the end point:
1.1.1.1 end-point ip address 2.2.2.2 kamailio ip address
INVITE From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone Call-ID: 9280396221-9479318750707221-11-7604239022
180 From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone;*tag=1_1555_t58918_125k* Call-ID: 9280396221-9479318750707221-11-7604239022
200 From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone;*tag=1_1555_t58918_125k* Call-ID: 9280396221-9479318750707221-11-7604239022
ACK From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@2.2.2.2;user=phone;*tag=5f08ae5f* Call-ID: 9280396221-9479318750707221-11-7604239022
How can I force it to send the correct tag?
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
See how Windows® connects the people, information, and fun that are part of your life Click here http://clk.atdmt.com/MRT/go/119463819/direct/01/
Hi!
In a successful INVITE transaction Kamailio does not produce ACK messages and thus does not produce to-tags. The 200 Ok is relayd to the caller. The caller sends ACK which will be forwarded by Kamailio.
I currently see 3 possibilities: - the caller uses the wrong totag - the trace is mixed up - you change the To header manually in the configuration file
regards klaus
Alex R.S.M schrieb:
Hi,
I made a simple SIP test call. The end point reply to kamailio with 180, 200 messages. The end point includes "tag=1_1555_t58918_125k" in TO field of these messages. However, kamailio reply with ACK message that includes a random tag (tag=5f08ae5f) in TO field. This tag is not the same as the one sent by the end point:
1.1.1.1 end-point ip address 2.2.2.2 kamailio ip address
INVITE From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone Call-ID: 9280396221-9479318750707221-11-7604239022
180 From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone;*tag=1_1555_t58918_125k* Call-ID: 9280396221-9479318750707221-11-7604239022
200 From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone;*tag=1_1555_t58918_125k* Call-ID: 9280396221-9479318750707221-11-7604239022
ACK From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@2.2.2.2;user=phone;*tag=5f08ae5f* Call-ID: 9280396221-9479318750707221-11-7604239022
How can I force it to send the correct tag?
Thanks, AR
Windows Live Hotmail now works up to 70% faster. Sign up today. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_112008
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Klaus Darilion wrote:
In a successful INVITE transaction Kamailio does not produce ACK messages and thus does not produce to-tags. The 200 Ok is relayd to the caller. The caller sends ACK which will be forwarded by Kamailio.
Yep - these are end-to-end ACKs. So I don't see how Kamailio could be rewriting the To tag.
My vote is with:
- the caller uses the wrong totag
Just because it's a soft-switch (what kind?) doesn't mean it has a SIP stack any less buggy than a tropical swamp.
Klaus,
Thank you for the response. Found the problem.
Date: Mon, 17 Nov 2008 16:46:29 +0100 From: klaus.mailinglists@pernau.at To: alex_rsm@hotmail.com CC: users@lists.kamailio.org Subject: Re: [Kamailio-Users] incorrect tag in ACK message
Hi!
In a successful INVITE transaction Kamailio does not produce ACK messages and thus does not produce to-tags. The 200 Ok is relayd to the caller. The caller sends ACK which will be forwarded by Kamailio.
I currently see 3 possibilities:
- the caller uses the wrong totag
- the trace is mixed up
- you change the To header manually in the configuration file
regards klaus
Alex R.S.M schrieb:
Hi,
I made a simple SIP test call. The end point reply to kamailio with 180, 200 messages. The end point includes "tag=1_1555_t58918_125k" in TO field of these messages. However, kamailio reply with ACK message that includes a random tag (tag=5f08ae5f) in TO field. This tag is not the same as the one sent by the end point:
1.1.1.1 end-point ip address 2.2.2.2 kamailio ip address
INVITE From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone Call-ID: 9280396221-9479318750707221-11-7604239022
180 From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone;*tag=1_1555_t58918_125k* Call-ID: 9280396221-9479318750707221-11-7604239022
200 From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@x.x.x.x;user=phone;*tag=1_1555_t58918_125k* Call-ID: 9280396221-9479318750707221-11-7604239022
ACK From: sip:1.1.1.1@2.2.2.2;tag=snl-1226930829-1404351227071264-11 To: sip:14078789913@2.2.2.2;user=phone;*tag=5f08ae5f* Call-ID: 9280396221-9479318750707221-11-7604239022
How can I force it to send the correct tag?
Thanks, AR
Windows Live Hotmail now works up to 70% faster. Sign up today. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_112008
Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
_________________________________________________________________ Windows Live Hotmail now works up to 70% faster. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_...
Alex R.S.M wrote:
Klaus,
Thank you for the response. Found the problem.
I'd be curious to know what it was.
Caller make a single call, kamailio forks the INVITE and relay the call to two end-point. Both end-points response with 180. One end-point reponses with 200. Caller send ACK with the incorrect tag value. I need to drop one of the 180 (the one which didn't answer the call). I believe I should be able to drop it in onreply_route block. Correct?
Date: Mon, 17 Nov 2008 11:07:54 -0500 From: abalashov@evaristesys.com To: alex_rsm@hotmail.com CC: klaus.mailinglists@pernau.at; users@lists.kamailio.org Subject: Re: [Kamailio-Users] incorrect tag in ACK message
Alex R.S.M wrote:
Klaus,
Thank you for the response. Found the problem.
I'd be curious to know what it was.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
_________________________________________________________________ Windows Live Hotmail now works up to 70% faster. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_...
Yes, but shouldn't it go like this?
1. Caller makes a single call;
2. Kamailio forks INVITE to endpoint A and B;
3. Endpoint A responds with 200;
4. Kamailio CANCELs branch to B and passes back 200 from A to caller;
5. Caller sends ACK with tag in A's 200 reply.
Alex R.S.M wrote:
Caller make a single call, kamailio forks the INVITE and relay the call to two end-point. Both end-points response with 180. One end-point reponses with 200. Caller send ACK with the incorrect tag value. I need to drop one of the 180 (the one which didn't answer the call). I believe I should be able to drop it in onreply_route block. Correct?
Date: Mon, 17 Nov 2008 11:07:54 -0500 From: abalashov@evaristesys.com To: alex_rsm@hotmail.com CC: klaus.mailinglists@pernau.at; users@lists.kamailio.org Subject: Re: [Kamailio-Users] incorrect tag in ACK message
Alex R.S.M wrote:
Klaus,
Thank you for the response. Found the problem.
I'd be curious to know what it was.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
Windows Live Hotmail now works up to 70% faster. Sign up today. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_112008
Alex R.S.M schrieb:
Caller make a single call, kamailio forks the INVITE and relay the call to two end-point. Both end-points response with 180. One end-point reponses with 200. Caller send ACK with the incorrect tag value. I need to drop one of the 180 (the one which didn't answer the call). I believe I should be able to drop it in onreply_route block. Correct?
You can not drop the proper 180 as you do not know yet which branch will send the 200 OK.
A dirty hack (but very well working) is to use a regular expression in reply route and remove the to-tag from all 1xx responses - so the softswitch can learn the tag only with the 200 ok.
klaus
Date: Mon, 17 Nov 2008 11:07:54 -0500 From: abalashov@evaristesys.com To: alex_rsm@hotmail.com CC: klaus.mailinglists@pernau.at; users@lists.kamailio.org Subject: Re: [Kamailio-Users] incorrect tag in ACK message
Alex R.S.M wrote:
Klaus,
Thank you for the response. Found the problem.
I'd be curious to know what it was.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
Windows Live Hotmail now works up to 70% faster. Sign up today. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_112008
Klaus Darilion wrote:
A dirty hack (but very well working) is to use a regular expression in reply route and remove the to-tag from all 1xx responses - so the softswitch can learn the tag only with the 200 ok.
Won't that cause the provisional response to not be matched to the right transaction?
Alex Balashov schrieb:
Klaus Darilion wrote:
A dirty hack (but very well working) is to use a regular expression in reply route and remove the to-tag from all 1xx responses - so the softswitch can learn the tag only with the 200 ok.
Won't that cause the provisional response to not be matched to the right transaction?
No. This is fine. A response need not to have the totag (for compatibility with the old SIP RFC) and actually transaction matching is based on branch id in Via header, dialog matching is based on callid+fromatg+totag
klaus
Klaus Darilion wrote:
actually transaction matching is based on branch id in Via header
Entirely? Interesting. Didn't know that.
Alex Balashov wrote:
Klaus Darilion wrote:
actually transaction matching is based on branch id in Via header
Entirely?
I do not know either. RFC 3261 is your friend :-)
The branch parameter in the topmost Via header field of the request is examined. If it is present and begins with the magic cookie "z9hG4bK", the request was generated by a client transaction compliant to this specification. Therefore, the branch parameter will be unique across all transactions sent by that client. The request matches a transaction if:
1. the branch parameter in the request is equal to the one in the top Via header field of the request that created the transaction, and
2. the sent-by value in the top Via of the request is equal to the one in the request that created the transaction, and
3. the method of the request matches the one that created the transaction, except for ACK, where the method of the request that created the transaction is INVITE.
So actually the Via header and CSEq header
regards klaus
-
Alex Balashov -
Alex R.S.M -
Klaus Darilion