Hello,
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).
Was this wrong behavior already supported ? Is there a solution for this problem ? Patch ? Other?
Thanks,
Sébastien Prouvost
If you have bought Digium equipment, you are entitled to their commercial support. So I think it’s best to contact them directly.
That’s true if he bought it as an appliance. If he has just integrated the Digium card with open source Asterisk, the issue relates to the SIP side, and the Digium card is irrelevant.
It would probably help if he were to quote the relevant parts of the RFC, and also confirm that he is using a current subversion of Asterisk 1.8 or 11 (bugs in 1.6 or 10 won’t get fixed, and older sub-versions may contain bugs that are now fixed).
I, personally, don’t have sufficient interest to search the RFC myself.
hello,
here is the requested information :
my asterisk version is 1.8.7.1.
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.
"
Regards, Sébastien Prouvost
You also need to factor in the following, which may lead to a rather different interpretation of the problem. I haven’t got time to fully digest this all at the moment:
13.2.2.4 2xx Responses
[quote] Once the ACK has been constructed, the procedures of [4] are used to
determine the destination address, port and transport. However, the
request is passed to the transport layer directly for transmission,
rather than a client transaction. This is because the UAC core
handles retransmissions of the ACK, not the transaction layer. The
ACK MUST be passed to the client transport every time a
retransmission of the 2xx final response that triggered the ACK
arrives.[/quote]
17.1.1.3 Construction of the ACK Request
[quote] If the INVITE request whose response is being acknowledged had Route
header fields, those header fields MUST appear in the ACK. This is
to ensure that the ACK can be routed properly through any downstream
stateless proxies.[/quote]
RFC 3263 section 4:
[quote] The procedures here MUST be done exactly once per transaction, where
transaction is as defined in [1]. That is, once a SIP server has
successfully been contacted (success is defined below), all
retransmissions of the SIP request and the ACK for non-2xx SIP
responses to INVITE MUST be sent to the same host. Furthermore, a
CANCEL for a particular SIP request MUST be sent to the same SIP
server that the SIP request was delivered to.
Because the ACK request for 2xx responses to INVITE constitutes a
different transaction, there is no requirement that it be delivered
to the same server that received the original request (indeed, if
that server did not record-route, it will not get the ACK).[/quote]
The extracts of RFC3261 you quote confirm what I am saying. An ACK request to a 200OK is a new request sent within a dialog. It must contain a Route header if the initial INVITE / 200 OK exchange contained a Record-Route header (and on this point Asterisk is compliant to the standard). This ACK request must be routed towards the URI contained in the route header (if it exist which is the case).
In the last section you quote there is a special treatment for ACK requests following a non-200 OK response but this does not correspond to the case I mention.
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
Ultimately, you need to raise this on issues.asterisk.org, if you want it treated as a bug.
17.1.1.3 was the bit of the RFC I found difficult to interpret.
I don’t think you can validly class this as a major bug on the issue tracker, as it doesn’t affect a large number of users (most users are not in record route situations).
To raise a bug report, you will need to run with at least:
core set verbose 5
core set debug 5
sip set debug on
and with logger.conf set to capture all the logging categories.
This appears to have been raised as issues.asterisk.org/jira/browse/ASTERISK-21465, although without the logging or a reference to here.