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@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
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users