[asterisk-bugs] [JIRA] (ASTERISK-21465) wrong routing of ACK request following a 200OK (route header no taken into account)

[sebastien prouvost (JIRA)]

sebastien prouvost created ASTERISK-21465:
---------------------------------------------

             Summary: wrong routing of ACK request following a 200OK (route header no taken into account)
                 Key: ASTERISK-21465
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21465
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Channels/chan_sip/General, General
    Affects Versions: 1.8.8.2
         Environment: OS : DEBIAN 6.0.5
DAHDI version 2.6.1 
LIBPRI version 1.4.12
            Reporter: sebastien prouvost


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

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira