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]> 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]> on behalf of Richard Robson < > [email protected]> > *Organization: *Greenlight Innovation > *Reply-To: *OpenSIPS users mailling list <[email protected]> > *Date: *Friday, October 7, 2016 at 12:46 PM > *To: *OpenSIPS users mailling list <[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] 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]>;tag=0UUHS000003000 > > 17:42:38.535526 │ <────────────────────────── │ > > │1D01001u1J9XWPK0DDUY6X > > +0.128720 │ 180 Ringing │ │To: > > <sip:[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> > > 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] > > > > > > _______________________________________________ > > Users mailing list > > [email protected] > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
