Patrick Wakano
2018-Aug-02 04:40 UTC
[asterisk-users] 400 reply to INVITE not properly treated
Hello list, Hope you all doing fine!! I am using chan_sip of Asterisk 13.6.0 and eventually I have a carrier which replies with 400 to some INVITES which happen to timeout.... I know the SIP reply code is not correct, but anyway I want to understand what is happening, because I think it is a bug.... In this situation, Asterisk is not failing the Dial, but sends back an ACK. Given the carrier has previously sent a 180, Asterisk just lets the user ringing forever.... Because the Dial() doesn't fail in this case, the user must hangup to terminate the call.... So question is, is this a known behaviour? I could not find anything related.... In my opinion, Asterisk should at fail the Dial and proceed with whatever was configured in the dialplan.... I tried some other 4XX SIP codes, but the only one I found not behaving properly is the 400 one.... Thanks, Kind regards, Patrick Wakano -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20180802/c282efeb/attachment.html>
Daniel Tryba
2018-Aug-02 15:42 UTC
[asterisk-users] 400 reply to INVITE not properly treated
On Thu, Aug 02, 2018 at 02:40:48PM +1000, Patrick Wakano wrote:> In my opinion, Asterisk should at fail the Dial and proceed with whatever > was configured in the dialplan.... I tried some other 4XX SIP codes, but > the only one I found not behaving properly is the 400 one....I think you are right, any 4xx is a final response. The call has failed at this moment (unless there are other branches). You should file a bug report IMHO. https://tools.ietf.org/html/rfc3261#section-13.2.2.3 A single non-2xx final response may be received for the INVITE. 4xx, 5xx and 6xx responses may contain a Contact header field value indicating the location where additional information about the error can be found. Subsequent final responses (which would only arrive under error conditions) MUST be ignored. All early dialogs are considered terminated upon reception of the non-2xx final response. After having received the non-2xx final response the UAC core considers the INVITE transaction completed. The INVITE client transaction handles the generation of ACKs for the response (see Section 17). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20180802/561e9537/attachment.sig>