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

sebastien prouvost (JIRA) noreply at issues.asterisk.org
Thu May 23 03:25:02 CDT 2013


    [ https://issues.asterisk.org/jira/browse/ASTERISK-21465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206733#comment-206733 ] 

sebastien prouvost commented on ASTERISK-21465:
-----------------------------------------------

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 .
                
> wrong routing of ACK request following a 200OK (Record-Route header not 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, 1.8.15.1
>         Environment: OS : DEBIAN 6.0.5
> DAHDI version 2.6.1 
> LIBPRI version 1.4.12
>            Reporter: sebastien prouvost
>            Assignee: sebastien prouvost
>         Attachments: debug_issue_ack, sip.conf
>
>
> 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



More information about the asterisk-bugs mailing list