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:[email protected]>;tag=81dd > To: "+44739790XXXX" <sip:[email protected]>;tag=XXgZtQND1H8rD > Call-ID: 9bbd818c-d1c8-4c62-9fed-7878ed05cf721 > CSeq: 1 INVITE > Contact: <sip:[email protected]: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:[email protected]> > > 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:[email protected]: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:[email protected] > To: "+44739790XXXX" <sip:[email protected]>;tag=XXgZtQND1H8rD > From: "+44128084XXXX" <sip:[email protected]>;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 > [email protected] > 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 _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
