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

2016-11-02 Thread Richard Robson 

  
  
Hi,
  
  I had 
   if (!topology_hiding_match() )
  
  this used to exit the script, but  now handles the ack and relays
  it.
  
  there was a handler for the ack but the script had exited before
  it got there.
  
  it was then a case of handleing the ACK in the topology map check
  or in the script and so chose the former option.
  
  Its all working now.
  
  R
  
  On 18/10/2016 15:22, Newlin, Ben wrote:


  
  
  
  
  
  
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: 
<users-boun...@lists.opensips.org>
  on behalf of Richard Robson
  <rrob...@greenlightcrm.com>
  Organization: Greenlight Innovation
  Reply-To: OpenSIPS users mailling list
  <users@lists.opensips.org>
  Date: Wednesday, October 12, 2016 at 8:08 AM
  To: "users@lists.opensips.org"
  <users@lists.opensips.org>
      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:01382843843@192.168.36.68>;tag=as04ad0c35
  To: <sip:01382250630@192.168.36.141>;tag=as3154cbe9
  Call-ID: 7f643eb34e5355e54575f8ec391740d3@192.168.36.68: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:441382250630@141.170.9.156: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:01382843843@192.168.36.68>;tag=as04ad0c35
  To: <sip:01382250630@192.168.36.141>;tag=as3154cbe9
  Contact: <sip:01382843843@192.168.36.68:5060>
  Call-ID: 7f643eb34e5355e54575f8ec391740d3@192.168.36.68: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: 
<users-boun...@lists.opensips.org>
  on behalf of Richard Robson
  <rrob...@greenlightcrm.com>
  Organization: Greenlight Innovation
  Reply-To: OpenSIPS users mailling list 
<users@lists.opensips.org>
  Date: Monday, October 10, 2016 at 12:33 PM
  To: OpenSIPS users mailling list 
    <users@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:

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

2016-10-31 Thread Newlin, Ben 
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: <users-boun...@lists.opensips.org> on behalf of Richard Robson 
<rrob...@greenlightcrm.com>
Organization: Greenlight Innovation
Reply-To: OpenSIPS users mailling list <users@lists.opensips.org>
Date: Wednesday, October 12, 2016 at 8:08 AM
To: "users@lists.opensips.org" <users@lists.opensips.org>
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:01382843843@192.168.36.68><sip:01382843843@192.168.36.68>;tag=as04ad0c35
To: 
<sip:01382250630@192.168.36.141><sip:01382250630@192.168.36.141>;tag=as3154cbe9
Call-ID: 
7f643eb34e5355e54575f8ec391740d3@192.168.36.68:5060<mailto:7f643eb34e5355e54575f8ec391740d3@192.168.36.68: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:441382250630@141.170.9.156: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:01382843843@192.168.36.68><sip:01382843843@192.168.36.68>;tag=as04ad0c35
To: 
<sip:01382250630@192.168.36.141><sip:01382250630@192.168.36.141>;tag=as3154cbe9
Contact: 
<sip:01382843843@192.168.36.68:5060><sip:01382843843@192.168.36.68:5060>
Call-ID: 
7f643eb34e5355e54575f8ec391740d3@192.168.36.68:5060<mailto:7f643eb34e5355e54575f8ec391740d3@192.168.36.68: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: 
<users-boun...@lists.opensips.org><mailto:users-boun...@lists.opensips.org> on 
behalf of Richard Robson 
<rrob...@greenlightcrm.com><mailto:rrob...@greenlightcrm.com>
Organization: Greenlight Innovation
Reply-To: OpenSIPS users mailling list 
<users@lists.opensips.org><mailto:users@lists.opensips.org>
Date: Monday, October 10, 2016 at 12:33 PM
To: OpenSIPS users mailling list 
<users@lists.opensips.org><mailto:users@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@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@192.168.36.92><sip:01382250029@192.168.36.92>;tag=as27a256cc
To: 
<sip:01382250631@192.168.36.141><sip:01382250631@192.168.36.141>;tag=gK0ca8d98e
Contact: 
<sip:01382250029@192.168.36.92:5060><sip:01382250029@192.168.36.92:5060>
Call-ID: 
259bb5f7748fc7fe68eaf1c95a70f5ec@192.168.36.92:5060<mailto:259bb5f7748fc7fe68eaf1c95a70f5ec@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.new...@inin.com<mailto:ben.new...@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 [

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

2016-10-17 Thread Richard Robson 

  
  
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:01382843843@192.168.36.68>;tag=as04ad0c35
  To: <sip:01382250630@192.168.36.141>;tag=as3154cbe9
  Call-ID: 7f643eb34e5355e54575f8ec391740d3@192.168.36.68: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:441382250630@141.170.9.156: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:01382843843@192.168.36.68>;tag=as04ad0c35
  To: <sip:01382250630@192.168.36.141>;tag=as3154cbe9
  Contact: <sip:01382843843@192.168.36.68:5060>
  Call-ID: 7f643eb34e5355e54575f8ec391740d3@192.168.36.68: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: 
<users-boun...@lists.opensips.org>
  on behalf of Richard Robson
  <rrob...@greenlightcrm.com>
  Organization: Greenlight Innovation
  Reply-To: OpenSIPS users mailling list
  <users@lists.opensips.org>
  Date: Monday, October 10, 2016 at 12:33 PM
  To: OpenSIPS users mailling list
      <users@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@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@192.168.36.92>;tag=as27a256cc
To: <sip:01382250631@192.168.36.141>;tag=gK0ca8d98e
Contact: <sip:01382250029@192.168.36.92:5060>
Call-ID: 259bb5f7748fc7fe68eaf1c95a70f5ec@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.new...@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 re

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

2016-10-11 Thread Newlin, Ben 
Oh, sorry. I misread that. But the cause is probably the same. OpenSIPS is 
retransmitting the 4XX because it is not associating the ACK with the failed 
transaction. A SIP trace would still be very helpful in debugging the problem.


Ben Newlin

From: <users-boun...@lists.opensips.org> on behalf of Richard Robson 
<rrob...@greenlightcrm.com>
Reply-To: OpenSIPS users mailling list <users@lists.opensips.org>
Date: Friday, October 7, 2016 at 2:46 PM
To: OpenSIPS users mailling list <users@lists.opensips.org>
Subject: Re: [OpenSIPS-Users] multiple retransmissions on 4XX after ACK


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.new...@inin.com<mailto:ben.new...@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-boun...@lists.opensips.org<mailto:users-boun...@lists.opensips.org>> on 
behalf of Richard Robson 
<rrob...@greenlightcrm.com<mailto:rrob...@greenlightcrm.com>>
Organization: Greenlight Innovation
Reply-To: OpenSIPS users mailling list 
<users@lists.opensips.org<mailto:users@lists.opensips.org>>
Date: Friday, October 7, 2016 at 12:46 PM
To: OpenSIPS users mailling list 
<users@lists.opensips.org<mailto:users@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:441618501...@gl-sip-03.greenlightcrm.com<mailto:441618501...@gl-sip-03.greenlightcrm.com>
 SIP/2.
  PSTN CARRIER   OPENSIPS
│Record-Route: <sip:109.239.96.133;lr;ftag=0UUHS03E
   ──┬─
──┬─│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@194.145.191.131<mailto:01382250029@194.145.191.131>>;tag=0UUHS03000
   17:42:38.535526   │ <── │
│1D01001u1J9XWPK0DDUY6X
 +0.128720   │ 180 Ringing │ │To:
<sip:441618501059@109.239.96.133<mailto:441618501059@109.239.96.133>>
   17:42:38.664246   │ <<< │ │Call-ID:
4515eef5-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.

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

2016-10-11 Thread Newlin, Ben 
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-boun...@lists.opensips.org> on behalf of Richard Robson 
<rrob...@greenlightcrm.com>
Organization: Greenlight Innovation
Reply-To: OpenSIPS users mailling list <users@lists.opensips.org>
Date: Monday, October 10, 2016 at 12:33 PM
To: OpenSIPS users mailling list <users@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@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@192.168.36.92><sip:01382250029@192.168.36.92>;tag=as27a256cc
To: 
<sip:01382250631@192.168.36.141><sip:01382250631@192.168.36.141>;tag=gK0ca8d98e
Contact: 
<sip:01382250029@192.168.36.92:5060><sip:01382250029@192.168.36.92:5060>
Call-ID: 
259bb5f7748fc7fe68eaf1c95a70f5ec@192.168.36.92:5060<mailto:259bb5f7748fc7fe68eaf1c95a70f5ec@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.new...@inin.com<mailto:ben.new...@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-boun...@lists.opensips.org<mailto:users-boun...@lists.opensips.org>> on 
behalf of Richard Robson 
<rrob...@greenlightcrm.com<mailto:rrob...@greenlightcrm.com>>
Organization: Greenlight Innovation
Reply-To: OpenSIPS users mailling list 
<users@lists.opensips.org<mailto:users@lists.opensips.org>>
Date: Friday, October 7, 2016 at 12:46 PM
To: OpenSIPS users mailling list 
<users@lists.opensips.org<mailto:users@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:441618501...@gl-sip-03.greenlightcrm.com<mailto:441618501...@gl-sip-03.greenlightcrm.com>
 SIP/2.
  PSTN CARRIER   OPENSIPS
│Record-Route: <sip:109.239.96.133;lr;ftag=0UUHS03E
   ──┬─
──┬─│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

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

2016-10-10 Thread Richard Robson 

  
  
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@192.168.36.141 SIP/2.0
  Via: SIP/2.0/UDP 192.168.36.92:5060;branch=z9hG4bK665e6330;rport
  Max-Forwards: 70
  From: ;tag=as27a256cc
  To: ;tag=gK0ca8d98e
  Contact: 
  Call-ID: 259bb5f7748fc7fe68eaf1c95a70f5ec@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" 
  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: 

  on behalf of Richard Robson 
  Organization: Greenlight Innovation
  Reply-To: OpenSIPS users mailling list
  
  Date: Friday, October 7, 2016 at 12:46 PM
  To: OpenSIPS users mailling list 
  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.

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

2016-10-07 Thread Richard Robson 
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"  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: * on behalf of Richard Robson <
> rrob...@greenlightcrm.com>
> *Organization: *Greenlight Innovation
> *Reply-To: *OpenSIPS users mailling list 
> *Date: *Friday, October 7, 2016 at 12:46 PM
> *To: *OpenSIPS users mailling list 
> *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:441618501...@gl-sip-03.greenlightcrm.com SIP/2.
>
>   PSTN CARRIER   OPENSIPS
>
> │Record-Route: 
>──┬─
>
> ──┬─│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:
>
> ;tag=0UUHS03000
>
>17:42:38.535526   │ <── │
>
> │1D01001u1J9XWPK0DDUY6X
>
>  +0.128720   │ 180 Ringing │ │To:
>
> 
>
>17:42:38.664246   │ <<< │ │Call-ID:
>
> 4515eef5-57f7d085-4d7d4603-f256d18-48e7f14@12
>
> +10.118555   │ 408 Request Timeout │ │0.0.1
>
>17:42:48.782801   │ <── │ │CSeq:
>
> 33717 INVITE
>
>  +0.000610   │ ACK │ │Contact:
>
> 
>
>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
>
>

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

2016-10-07 Thread Newlin, Ben 
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:  on behalf of Richard Robson 

Organization: Greenlight Innovation
Reply-To: OpenSIPS users mailling list 
Date: Friday, October 7, 2016 at 12:46 PM
To: OpenSIPS users mailling list 
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:441618501...@gl-sip-03.greenlightcrm.com
 SIP/2.
  PSTN CARRIER   OPENSIPS
│Record-Route: 
 │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:
>;tag=0UUHS03000
   17:42:38.535526   │ <── │
│1D01001u1J9XWPK0DDUY6X
 +0.128720   │ 180 Ringing │ │To:
>
   17:42:38.664246   │ <<< │ │Call-ID:
4515eef5-57f7d085-4d7d4603-f256d18-48e7f14@12
+10.118555   │ 408 Request Timeout │ │0.0.1
   17:42:48.782801   │ <── │ │CSeq:
33717 INVITE
 +0.000610   │ ACK │ │Contact:

   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
supp...@greenlightcrm.com


___
Users mailing list