[Home]

Summary:ASTERISK-21465: wrong routing of ACK request following a 200OK (Record-Route header not taken into account)
Reporter:sebastien prouvost (sebastien)Labels:
Date Opened:2013-04-17 03:25:48Date Closed:2013-05-30 14:33:14
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General General
Versions:1.8.8.2 1.8.15.1 Frequency of
Occurrence		Constant
Related
Issues:
Environment:OS : DEBIAN 6.0.5 DAHDI version 2.6.1 LIBPRI version 1.4.12Attachments:( 0) Copie_de_issue_ack
( 1) debug_issue_ack
( 2) sip.conf
( 3) sip_show_settings
Description:I have an Asterisk GW (PSTN to IP gateway) equiped with digium board.
I observe the following behaviors of my Asterisk GW when making a PSTN to IP call:
- The GW sends the INVITE request to @IP1 (obtained by DNS query) and receives a 200 OK with a record-route header containing @IP2.
- The ACK request sent by the GW contains a route header with @IP2 (according to the record-route header received in the 200 OK) which is correct according the RFC3261. However this ACK request is sent to @IP1 and not to @IP2 which is not correct according to RFC3261 (the asterisk GW must send the ACK request to the first entry of the route header).

Here is the extract of RFC3261 which says that a request (in my case the ACK) has to be sent to the first Route header field value in the request, or to the request's Request-URI if there is no Route header field present. In my case I have a route header, therefore the request shall be sent to this route header (and I observe that it is sent to the request-URI).

page 41 :
"
8.1.2 Sending the Request
The destination for the request is then computed. [...] the procedures are applied to the first Route header field value in the request (if one exists), or to the request's Request-URI if there is no Route header field present.
"

This problem is a major non-compatibility issue to the standard SIP protocol which may cause interoperability problems in certain configurations (IMS type for example where the inital INVITE request is routed toward a I-CSCF and the request within a dialog bypass this I-CSCF).

Regards, Sébastien Prouvost
Comments:By: Michael L. Young (elguero) 2013-04-17 11:47:25.362-0500

My first comment is that you are using an old version of Asterisk.  I would highly recommend getting all the bug/security fixes that have come out over roughly the past year and a half.  For some reason, in the back of my mind I think some bugs dealing around where acks, notifies, etc. are sent have been resolved.

If this is still an issue with the latest release of Asterisk 1.8, please attach a SIP debug to this issue to help with troubleshooting.

https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Thanks
By: David Woolley (davidw) 2013-04-18 12:02:44.582-0500

See http://forums.asterisk.org/viewtopic.php?f=1&t=86293 for some of the back history (and I did point out that he needed specific logging for a bug report).
By: Walter Doekes (wdoekes) 2013-04-22 08:04:16.061-0500

(1) RR is not uncommon,
(2) but it is uncommon that the IP mentioned in the Record-Route is different from the IP that you're talking to.

Could it be that you have nat=yes (or nat=force_rport) for this account?
By: Rusty Newton (rnewton) 2013-05-10 16:38:54.297-0500

@sebastien,  can you provide the debug and further information requested?
By: sebastien prouvost (sebastien) 2013-05-14 08:59:07.364-0500

Hello,

I upgraded my asterisk version to version 1.8.15.cert2 and I still have the problem. See attached debug. bellow the concerned extract of the debug : the ACK is sent to 172.25.10.1 although the route (corresponding to the record-route of the 200OK is to 172.25.10.3). :

[May 14 15:52:56] VERBOSE[15355] chan_sip.c: Transmitting (NAT) to 172.25.10.1:5060:
ACK sip:172.25.11.33;did=07e1.34875384 SIP/2.0
Via: SIP/2.0/UDP 172.20.153.230:5060;branch=z9hG4bK02508530;rport
Route: <sip:mt@172.25.10.3;lr=on;ftag=as3e6eaacd;did=07e.5ff0d221>
Max-Forwards: 70
From: "+33145295657" <sip:+33145295657@172.20.153.230>;tag=as3e6eaacd
To: <sip:+33296080293@ims.oasis-pftest.net>;tag=db719820
Contact: <sip:+33145295657@172.20.153.230:5060>
Call-ID: 3606127c55a5120f121920dd35b4a74c@172.20.153.230:5060
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.8.15-cert2
Content-Length: 0

Regards,
Sébastien Prouvost
By: sebastien prouvost (sebastien) 2013-05-14 09:05:20.732-0500

this is the debug file associated to the issue.
By: Rusty Newton (rnewton) 2013-05-17 16:47:56.384-0500

@sebastien, Thanks! Can you also answer Walter's question "Could it be that you have nat=yes (or nat=force_rport) for this account?" and provide your sip.conf file (sanitize passwords please)

Thanks!
By: Rusty Newton (rnewton) 2013-05-17 16:48:34.706-0500

Hit "Send back" when you have responded
By: sebastien prouvost (sebastien) 2013-05-21 02:59:22.906-0500

sip.conf file attached
By: sebastien prouvost (sebastien) 2013-05-21 03:07:08.065-0500

To answer Walter's question above : I use my Asterisk GW as the MGCF function of the IMS (as standardised by 3GPP). In IMS, an incoming initial INVITE is sent to I-CSCF function and subsequent requests sent as part of the dialog established by the initial INVITE (such as the ACK to a 200OK) are sent to the S-CSCF (the I-CSCF do not record route). So in IMS this situation is quite common. No NAT used as I am not at the client interface.  
By: Rusty Newton (rnewton) 2013-05-22 16:31:42.888-0500

Thanks for the info.

Is that your entire sip.conf?  If not, can you provide the rest?

Is the far end in this case configured as a peer/user? Can you provide the output of "sip show peer <peername>" and/or "sip show user <username>" for the entry involved?

{noformat}
[May 14 15:52:56] VERBOSE[15355] chan_sip.c: Transmitting (NAT) to 172.25.10.1:5060:
{noformat}

With (NAT) showing up I think Asterisk is sending to the received from address due to rport on the Via header in the 200OK. If there is an issue here it may be related to Asterisk's RFC3581|http://www.ietf.org/rfc/rfc3581.txt] implementation.

That or I'm very likely misunderstanding it! I'll check with some others to see what we would expect in this situation.

If you can provide the additional requested info that would be very helpful. Also a Packet Capture viewable in wireshark would be extra helpful. Thanks!
By: sebastien prouvost (sebastien) 2013-05-23 03:24:33.512-0500

thanks for your feedback.
Yes this is my whole sip.conf file. As you can see, tt is very simple as I am using Asterisk in a very simple way (GW to interwork between SIP and PLMN). To answer your point with regards to rport and rfc3581, this relates to the routing of answers to request (1xx, 2xx, 3xx, 4xx, 5xx, 6xx messages). So it does not correspond to my problem which is a wrong routing of an ACK which is a request and not a response. Bellow the extract of RFC3581:

"  This extension defines a new parameter for the Via header field,
  called "rport", that allows a client to request that the server send
  the response back to the source IP address and port where the request
  came from.  The "rport" parameter is analogous to the "received"
  parameter, except "rport" contains a port number, not the IP address.
"

The far end is not configure as a peer or user (I do not have any peer or user configured).
I attach the packet Capture viewable in wireshark .
By: sebastien prouvost (sebastien) 2013-05-23 03:34:05.233-0500

wireshark trace attached
By: Michael L. Young (elguero) 2013-05-23 09:13:09.113-0500

Can you provide the output of "sip show settings"?

Thanks
By: sebastien prouvost (sebastien) 2013-05-23 09:25:09.317-0500

sip show settings output attached
By: sebastien prouvost (sebastien) 2013-05-23 09:27:09.349-0500

sip show settings output attached.
By: Michael L. Young (elguero) 2013-05-23 09:30:20.808-0500

{noformat}
Default Settings:
-----------------
 Allowed transports:     UDP
 Outbound transport:     UDP
 Context:                ip2pstn
 Force rport:            Yes
{noformat}

There is no NAT involved but Force_rport is turned on.  Try adding "nat=no" to your sip.conf settings.  The default setting, when you do not set it, is "nat=force_rport".

Rusty and Walter are suspecting this might be the problem and I concur.  With force_rport on, we ignore the record-route and use the address we received the response from.
By: Michael L. Young (elguero) 2013-05-23 09:44:11.442-0500

One other thing I just thought of, you might need the patch on ASTERISK-21225 in order to turn NAT off properly.  I don't think that patch has made its way into certified 1.8 yet.
By: Walter Doekes (wdoekes) 2013-05-24 02:59:04.249-0500

You could still turn it off per account/device, just not easily globally. Right?
By: Walter Doekes (wdoekes) 2013-05-24 03:03:24.284-0500

> The far end is not configure as a peer or user [...]

Scratch my last comment. I didn't read this bit. nat=no should still work though.

{noformat}
ast_set_flag(&mask[0], SIP_NAT_FORCE_RPORT);
- ast_set_flag(&flags[0], SIP_NAT_FORCE_RPORT); /* Default to "force_rport" */
- if (!strcasecmp(v->value, "no")) {
- ast_clear_flag(&flags[0], SIP_NAT_FORCE_RPORT);
{noformat}
By: sebastien prouvost (sebastien) 2013-05-27 07:26:18.442-0500

hello,
I added "nat=no" to my sip.conf settings as you suggested Michael and this solves my problem. The ACK is now correctly routed. So thank you very much !
I however think that Asterisk is not correctly implementing the Rport extension which relates to the routing of answers to request (1xx, 2xx, 3xx, 4xx, 5xx, 6xx messages) and not to request (such as the ACK to 200OK).

Bellow the extract of RFC3581:

" This extension defines a new parameter for the Via header field,
called "rport", that allows a client to request that the server send
the response back to the source IP address and port where the request
came from. The "rport" parameter is analogous to the "received"
parameter, except "rport" contains a port number, not the IP address.
"

On my side this does not cause any problem, but it could be corrected in a next release maybe.

Thanks a lot,
Sébastien Prouvost
By: Walter Doekes (wdoekes) 2013-05-27 10:11:23.445-0500

Sébastien, good to hear that it works.

As for your comments:

- force_rport is not the rport extension, it *forces* the use of the remote IP/port *instead* of relying on said extension. It also discards other information (RR in this case). I agree with you that the name can be confusing. The documentation surrounding the setting could probably be improved.

- Newer releases don't have force_rport, but auto_force_rport as default. That should make more intelligent guesses of the requested setting. If you have the time to confirm that that new setting (in Asterisk 11 and higher) would work for you, that would be super!


By: Walter Doekes (wdoekes) 2013-05-29 07:28:26.679-0500

(This shouldn't be in "Waiting for feedback")
By: sebastien prouvost (sebastien) 2013-05-30 04:49:13.051-0500

hello,

to answer Walter comment above :
I understand that the parameter force_rport does not stricktly relates to rport rfc support. However the way this parameter is implemented is not compliant to RFC 3261. That was the meaning of my remark.
I will try to upgrade my asterisk, however I will not be able to do it very soon as my asterisk support live trafic.
regards,
Sébastien
By: Walter Doekes (wdoekes) 2013-05-30 05:08:50.440-0500

Sebastien, so you are saying that with nat=no, asterisk behaves wrongly?

I reread what you're saying, and I still come to the conclusion that you have problems with the force_rport behaviour, not with the nat=no behaviour.

Like I said, force_rport does more than just implement the ";rport" bit (without requiring it in the request). The fact that it doesn't need ";rport" in the request, is by itself is already a difference from RFC. So saying that it's not implementing RFC correctly is moot.
By: sebastien prouvost (sebastien) 2013-05-30 05:16:38.905-0500

with Nat=No Asterisk behave perfectly and I am very satified with this behavior.
What I am saying is that with force_rport, the way the ACK is routed is not compliant to SIP RFC3261. it is not a problem for me as i am not using it but it may cause some problems in the future for someone.
By: Michael L. Young (elguero) 2013-05-30 07:20:22.559-0500

Sebastien,

That is what Walter is trying to say.  _force__rport means that it forces Asterisk to handle everything as if rport was in the request, whether it was or not.  I was unable to find any mention of rport in RFC3261, btw.

RFC3581 - Abstract
{quote}
  This extension
  defines a new parameter for the Via header field, called "rport",
  that allows a client to request that the server send the response
  back to the source IP address and port from which the request
  originated.
{quote}
By: sebastien prouvost (sebastien) 2013-05-30 07:30:10.474-0500

Rport is not defined in RFC 3261 this is why there is no mention of it. It is defined in RFC3581. But RFC3261 defines the way requests such as an ACK have to be routed.
What I am saying is that the behavior of Asterisk when the parameter force_rport is present is not compliant to the routing defined in RFC3261 and neither to RFC3581 (which defines the way reponses should be routed but not the way a Request such as an ACK should be routed).
A request within a dialog must always be sent to the adress of the route header even if the initial request contained rport.

By: David Woolley (davidw) 2013-05-30 07:37:24.210-0500

I think a lot of this issue arises from the fact that using nat=yes in any NAT situation has become Asterisk folklore, when it really should not be needed in the common cases.  (In the same way that the folklore is now to use insecure=invite,port, because "very" has been removed, I expect the folklore for nat= to become to set all the options.)

As to nat= breaking RFCs.  nat= is all about applying hacks to work round real world problems, so it is very likely that it will result in non-compliant behaviour.
By: sebastien prouvost (sebastien) 2013-05-30 07:54:58.130-0500

ok thanks. then it may be nice do have by default the standard ie nat=no.
By: Michael L. Young (elguero) 2013-05-30 07:58:56.247-0500

Sorry to be dense.  I hear what you are saying. My point was that the extension defines new behavior.  But, Asterisk doesnt really implement it.  It takes a shortcut.  If force report is on, we send the response back to the original ip and port the request came in from just like what I quoted from the abstract of rfc 3581.

The good thing is we found a fix for you in the meantime.
By: Rusty Newton (rnewton) 2013-05-30 14:33:14.445-0500

For reference: ASTERISK-18862 is where we changed the default "nat=" value and includes links to the issues and mail list conversations that resulted in the change.

I don't think there is anything else to do here as I believe the configuration options used were behaving as expected. Any suggested improvements should be put into a patch and opened in a new issue.

Closing this out since it is a mis-configuration and not a bug. Thanks everyone!