Not seeing ACK to 200 as existing transaction - sr-users

21 Sep 2020

Hello all,

If there is someone that can help with this, that would be rather good!

I can supply further details upon anyone having seen this before.......

In NORMAL operation, I get an INVITE and process this (My Kamailio is 
processing SS7 CAMEL, and does an MRSN lookup)

It then makes the INVITE onwards to the MSRN collected.

When answered, I see the 200.

I pass the 200 back to the source of the INVITE

I get the ACK, and use "t_check_trans()" and if that returns true will 
route the ACK onward (I am in the ACK path having set Record-route on 
the 200)

This all works.

FAILURE occurs when I get INVITE from another source (one step removed 
from the generating gateway)

All works as it should *BUT* the t_check_trans() returns FALSE, so I 
guess there is a matching issue to the live transaction?

I have tried a "work around" and routed the ACK anyway. This *does* 
work, and is routed correctly forward to the original "contact" and the 
200 messages stop being repeated.. *BUT* the Kamailio instance here 
times out the dialog as the ACK was not seen correctly.

I also popped a "t_check_trans()" into the reply route to test the 200 
OK that I get, and that returns TRUE.

Here is the 200 message that I send back to the INVITE sender:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 
52.1.2.3;rport=5060;branch=z9hG4bK7bb7.62ce43198ddade3212c715259623a75f.1
Via: SIP/2.0/UDP 
149.1.2.3:5060;received=149.1.2.3;rport=5060;branch=z9hG4bK905c7e6e
Record-Route: 
<sip:3.1.2.3;lr;ftag=81dd;did=08b.0141;vsf=AAAAAB8ABQMKCAgMAwUCCHgzWEQXXl5WSUNYQ14cUF5t>

Record-Route: <sip:52.1.2.3:5060;lr>
From: "+44128084XXXX" <sip:+44128084XXXX@149.1.2.3>;tag=81dd
To: "+44739790XXXX" <sip:+44739790XXXX@52.1.2.3>;tag=XXgZtQND1H8rD
Call-ID: 9bbd818c-d1c8-4c62-9fed-7878ed05cf721
CSeq: 1 INVITE
Contact: <sip:+44739790XXXX@185.1.2.3:5060;transport=udp>
User-Agent: Ziron
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, 
NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, 
dialog, line-seize, call-info, sla, include-session-description, 
presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 216
P-Asserted-Identity: "Outbound Call" <sip:44780204XXXX@52.1.2.3>

v=0
o=MSX53 11014726 11014726 IN IP4 88.1.2.3
s=sip call
c=IN IP4 88.1.2.3
t=0 0
a=sendrecv
m=audio 14810 RTP/AVP 8 99
a=rtpmap:8 PCMA/8000
a=rtpmap:99 telephone-event/8000
a=fmtp:99 0-15
a=ptime:20

And this is the ACK I get back:

ACK sip:+44739790XXXX@185.1.2.3:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 
52.1.2.3;branch=z9hG4bK7bb7.cca0ec5a2c96b8fe82344d9835163595.0
Via: SIP/2.0/UDP 
149.1.2.3:5060;received=149.1.2.3;rport=5060;branch=z9hG4bK6b8f7781
Contact: sip:+44128084XXXX@149.1.2.3
To: "+44739790XXXX" <sip:+44739790XXXX@52.1.2.3>;tag=XXgZtQND1H8rD
From: "+44128084XXXX" <sip:+44128084XXXX@149.1.2.3>;tag=81dd
Call-ID: 9bbd818c-d1c8-4c62-9fed-7878ed05cf721
CSeq: 1 ACK
User-Agent: PartitionwareTM SIP Toolkit v4.0.30319
Content-Length: 0
Max-Forwards: 69
Allow: INVITE, ACK, CANCEL, BYE, INFO, OPTIONS, PRACK
Supported: timer,100rel
Allow-Events: telephone-event
P-hint: outbound

Any thoughts would be great,

Steve