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:
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.
_________________________________________________________________ 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:
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:
Klaus Darilion wrote:
Yep - these are end-to-end ACKs. So I don't see how Kamailio could be rewriting the To tag.
My vote is with:
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.
_________________________________________________________________ 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:
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?
_________________________________________________________________ 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:
Alex R.S.M schrieb:
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
Klaus Darilion wrote:
Won't that cause the provisional response to not be matched to the right transaction?
Klaus Darilion wrote:
actually transaction matching is based on branch id in Via header
Entirely? Interesting. Didn't know that.
Alex Balashov wrote:
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