[OpenSIPS-Users] multiple retransmissions on 4XX after ACK

Mon Oct 10 18:52:24 CEST 2016

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: <users-bounces at lists.opensips.org> on behalf of Richard Robson <rrobson at greenlightcrm.com>
Organization: Greenlight Innovation
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: Monday, October 10, 2016 at 12:33 PM
To: OpenSIPS users mailling list <users at lists.opensips.org>
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:01382250631 at 192.168.36.141 SIP/2.0
Via: SIP/2.0/UDP 192.168.36.92:5060;branch=z9hG4bK665e6330;rport
Max-Forwards: 70
From: <sip:01382250029 at 192.168.36.92><sip:01382250029 at 192.168.36.92>;tag=as27a256cc
To: <sip:01382250631 at 192.168.36.141><sip:01382250631 at 192.168.36.141>;tag=gK0ca8d98e
Contact: <sip:01382250029 at 192.168.36.92:5060><sip:01382250029 at 192.168.36.92:5060>
Call-ID: 259bb5f7748fc7fe68eaf1c95a70f5ec at 192.168.36.92:5060<mailto:259bb5f7748fc7fe68eaf1c95a70f5ec at 192.168.36.92: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" <Ben.Newlin at inin.com<mailto:Ben.Newlin at inin.com>> 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: <users-bounces at lists.opensips.org<mailto:users-bounces at lists.opensips.org>> on behalf of Richard Robson <rrobson at greenlightcrm.com<mailto:rrobson at greenlightcrm.com>>
Organization: Greenlight Innovation
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org<mailto:users at lists.opensips.org>>
Date: Friday, October 7, 2016 at 12:46 PM
To: OpenSIPS users mailling list <users at lists.opensips.org<mailto:users at lists.opensips.org>>
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:441618501059 at gl-sip-03.greenlightcrm.com<mailto:441618501059 at gl-sip-03.greenlightcrm.com> 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:01382250029 at 194.145.191.131<mailto:01382250029 at 194.145.191.131>>;tag=0UUHS000003000
   17:42:38.535526   │ <────────────────────────── │
│1D01001u1J9XWPK0DDUY6X
         +0.128720   │         180 Ringing │         │To:
<sip:441618501059 at 109.239.96.133<mailto:441618501059 at 109.239.96.133>>
   17:42:38.664246   │ <<<──────────────────────── │         │Call-ID:
4515e0000ef5-57f7d085-4d7d4603-f256d18-48e7f14 at 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
support at greenlightcrm.com<mailto:support at greenlightcrm.com>

_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

--

Richard Robson

Greenlight Support

01382 843843

support at greenlightcrm.com<mailto:support at greenlightcrm.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20161010/41af6a85/attachment-0001.htm>