So you are saying the issue has been resolved by performing matching on the ACK?
If not, I would still need a full transaction trace. Many components of the ACK for a failure response are dependent on fields in the initial INVITE, which was not included. Ben Newlin From: <[email protected]> on behalf of Richard Robson <[email protected]> Organization: Greenlight Innovation Reply-To: OpenSIPS users mailling list <[email protected]> Date: Wednesday, October 12, 2016 at 8:08 AM To: "[email protected]" <[email protected]> Subject: Re: [OpenSIPS-Users] multiple retransmissions on 4XX after ACK [Solved] OK, I am using topolgy hiding and checking for this but the ACK wasn't being handled in the topology_hiding_match On 11/10/2016 14:04, Richard Robson wrote: Does this help? 4XX 2016/10/11 14:02:44.810905 192.168.36.141:5060 -> 192.168.36.68:5060 SIP/2.0 487 Request Terminated Via: SIP/2.0/UDP 192.168.36.68:5060;received=192.168.36.68;rport=5060;branch=z9hG4bK789668db From: <sip:[email protected]><sip:[email protected]>;tag=as04ad0c35 To: <sip:[email protected]><sip:[email protected]>;tag=as3154cbe9 Call-ID: [email protected]:5060<mailto:[email protected]:5060> CSeq: 103 INVITE Server: FPBX-12.0.76.4(11.5.1) Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Length: 0 ACK 2016/10/11 14:02:44.811879 192.168.36.68:5060 -> 192.168.36.141:5060 ACK sip:[email protected]:5060;did=a8f.46c3a1f1 SIP/2.0 Via: SIP/2.0/UDP 192.168.36.68:5060;branch=z9hG4bK789668db;rport Max-Forwards: 70 From: <sip:[email protected]><sip:[email protected]>;tag=as04ad0c35 To: <sip:[email protected]><sip:[email protected]>;tag=as3154cbe9 Contact: <sip:[email protected]:5060><sip:[email protected]:5060> Call-ID: [email protected]:5060<mailto:[email protected]:5060> CSeq: 103 ACK User-Agent: FPBX-12.0.76.4(11.5.1) Content-Length: 0 Regards, Richard On 10/10/2016 17:52, Newlin, Ben wrote: It’s impossible to say whether the ACK or the 4XX response are formatted properly from just seeing the ACK. The entire transaction is necessary. Ben Newlin From: <[email protected]><mailto:[email protected]> on behalf of Richard Robson <[email protected]><mailto:[email protected]> Organization: Greenlight Innovation Reply-To: OpenSIPS users mailling list <[email protected]><mailto:[email protected]> Date: Monday, October 10, 2016 at 12:33 PM To: OpenSIPS users mailling list <[email protected]><mailto:[email protected]> Subject: Re: [OpenSIPS-Users] multiple retransmissions on 4XX after ACK Hi All I've made tha call from an internal machine and opensips still appears to ignore the ACKs The ACK looks to be OK 2016/10/10 17:28:20.183387 192.168.36.92:5060 -> 192.168.36.141:5060 ACK sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.36.92:5060;branch=z9hG4bK665e6330;rport Max-Forwards: 70 From: <sip:[email protected]><sip:[email protected]>;tag=as27a256cc To: <sip:[email protected]><sip:[email protected]>;tag=gK0ca8d98e Contact: <sip:[email protected]:5060><sip:[email protected]:5060> Call-ID: [email protected]:5060<mailto:[email protected]:5060> CSeq: 103 ACK User-Agent: FPBX-12.0.76.2(11.7.0) Content-Length: 0 this is from an asterisk box in response to a 404 from the Opensips Box. Opensips sends several 404s and there are ACKs to the fist four and it still sends subsequebt ones Regards Richard On 07/10/2016 19:46, Richard Robson wrote: The ack is from the cp. opensips is sending the 4xx. I'll try the same on another provider. Thanks for the info On 7 Oct 2016 18:27, "Newlin, Ben" <[email protected]<mailto:[email protected]>> wrote: The most likely cause is that there is something wrong in the format of the ACK which is causing the far end to not recognize it as being the ACK for that 4XX response. So the far end will continue to retransmit the 4XX response. On the OpenSIPS side, these are recognized as retransmissions so the previous response is resent without triggering the failure route. The reason it happens on 4XX but not on 200 OK is that ACKs within a dialog – for 200 OK responses to INVITE or BYE – are actually requests themselves and are sent end-to-end just like INVITEs and BYEs. These ACKs are constructed following the rules for any request within a dialog [1]. ACKs to failure responses, however, are transmitted at the transaction layer which means in this case they are being generated by OpenSIPS directly. Transactional ACKs are not requests and the rules for constructing them are different [2]. The most important parts are that the Via and Request-URI headers must match those in the initial request exactly. I have encountered this problem several times when my manipulations of messages in the routing script cause the ACKs to be malformed. I would suggest capturing a SIP trace of the failing transaction and verify the ACK is constructed properly. [1] https://tools.ietf.org/html/rfc3261#section-12.2.1.1 [2] https://tools.ietf.org/html/rfc3261#section-17.1.1.3 Ben Newlin From: <[email protected]<mailto:[email protected]>> on behalf of Richard Robson <[email protected]<mailto:[email protected]>> Organization: Greenlight Innovation Reply-To: OpenSIPS users mailling list <[email protected]<mailto:[email protected]>> Date: Friday, October 7, 2016 at 12:46 PM To: OpenSIPS users mailling list <[email protected]<mailto:[email protected]>> Subject: [OpenSIPS-Users] multiple retransmissions on 4XX after ACK Hi Guys, Not sure if this a problem or normal behaviour or I'm doing something wrong. after a 4XX is sent and the ACK recieved I can see 3 retransmissions of the 4XX message all with corresponding ACKs. Whywould it re transmit after an ACK in the logs in the reply route I only see one. Is there something I should be doing or is this normal behaviour. It doesnt do it with BYEs We are testing with BT next wee and I'd like everything to be shipshape this is from the carrier to opensips │INVITE sip:[email protected]<mailto:[email protected]> SIP/2. PSTN CARRIER OPENSIPS │Record-Route: <sip:109.239.96.133;lr;ftag=0UUHS0000030000E ──────────┬───────── ──────────┬─────────│01001u1J9XWPK0DDUY6X;did=e7f.7bf9fe87> │ INVITE (SDP) │ │Via: SIP/2.0/UDP 109.239.96.133:5060;branch=z9hG4bK547c.48 17:42:38.425641 │ ──────────────────────────> │ │a4d4.0 +0.004634 │ 100 Giving a try │ │Via: SIP/2.0/UDP 194.145.191.131:5060;branch=z9hG4bK00E0F5 17:42:38.430275 │ <────────────────────────── │ │0E45333EAEE2FDC3E18D +0.105251 │ 180 Ringing │ │From: <sip:[email protected]<mailto:[email protected]>>;tag=0UUHS000003000 17:42:38.535526 │ <────────────────────────── │ │1D01001u1J9XWPK0DDUY6X +0.128720 │ 180 Ringing │ │To: <sip:[email protected]<mailto:[email protected]>> 17:42:38.664246 │ <<<──────────────────────── │ │Call-ID: 4515e0000ef5-57f7d085-4d7d4603-f256d18-48e7f14@12 +10.118555 │ 408 Request Timeout │ │0.0.1 17:42:48.782801 │ <────────────────────────── │ │CSeq: 33717 INVITE +0.000610 │ ACK │ │Contact: <sip:194.145.191.131:5060<http://194.145.191.131:5060>> 17:42:48.783411 │ ──────────────────────────> │ │Allow-Events: refer +0.436750 │ 408 Request Timeout │ │Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, INFO, REF 17:42:49.220161 │ <<<──────────────────────── │ │, NOTIFY, SUBSCRIBE, UPDATE +0.000636 │ ACK │ │Content-Type: application/sdp 17:42:49.220797 │ ────────────────────────>>> │ │Max-Forwards: 69 +1.003961 │ 408 Request Timeout │ │Supported: timer, replaces, histinfo, 100rel 17:42:50.224758 │ <<<──────────────────────── │ │User-Agent: TELES-SBC +0.000705 │ ACK │ │Content-Length: 463 17:42:50.225463 │ ────────────────────────>>> │ │ +2.005938 │ 408 Request Timeout │ │v=0 17:42:52.231401 │ <<<──────────────────────── │ │o=- 1890151066 0 IN IP4 194.145.191.134 +0.000651 │ ACK │ │s=TELES-SBC 17:42:52.232052 │ ────────────────────────>>> │ │c=IN IP4 194.145.191.134 │ │ │t=0 0 │ Regards, -- Richard Robson Greenlight Support 01382 843843 [email protected]<mailto:[email protected]> _______________________________________________ Users mailing list [email protected]<mailto:[email protected]> http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list [email protected]<mailto:[email protected]> http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Richard Robson Greenlight Support 01382 843843 [email protected]<mailto:[email protected]> _______________________________________________ Users mailing list [email protected]<mailto:[email protected]> http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Richard Robson Greenlight Support 01382 843843 [email protected]<mailto:[email protected]> -- Richard Robson Greenlight Support 01382 843843 [email protected]<mailto:[email protected]>
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
