[SR-Users] Not seeing ACK to 200 as existing transaction

[Daniel-Constantin Mierla]

Hello,

a few generic remarks from SIP/kamailio point of view:

  -  the ACK for 200ok is its own (special) transaction, it can take a
different path that the INVITE, a matter of record routing

  - given that the ACK is not expected to come to Kamailio always, there
is no retransmission done by Kamailio for 200ok, it means the callee is
resending it because it didn't receive the ACK

  - also, because it is own special transaction, the t_check_trans() is
not going to match on the INVITE transaction, even that is still not
destroyed (ie, it stays like 5secs more after 200ok). I say special
transaction because ACK does not have responses, thus is no transaction
state kept by kamailio for them, ACKs for 200ok being forwarded stateless.

Otherwise I understood it was found that record routing was missing in
this particular situation and the case was solved.

Cheers,
Daniel

On 21.09.20 16:19, Steve Bucklin wrote:
> 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 at 149.1.2.3>;tag=81dd
> To: "+44739790XXXX" <sip:+44739790XXXX at 52.1.2.3>;tag=XXgZtQND1H8rD
> Call-ID: 9bbd818c-d1c8-4c62-9fed-7878ed05cf721
> CSeq: 1 INVITE
> Contact: <sip:+44739790XXXX at 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 at 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 at 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 at 149.1.2.3
> To: "+44739790XXXX" <sip:+44739790XXXX at 52.1.2.3>;tag=XXgZtQND1H8rD
> From: "+44128084XXXX" <sip:+44128084XXXX at 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
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla