[asterisk-bugs] [JIRA] (ASTERISK-26609) chan_sip: Wrong handling of 488 Not Acceptable Here during reINVITE

[Rusty Newton (JIRA)]

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

Rusty Newton edited comment on ASTERISK-26609 at 11/22/16 4:00 PM:
-------------------------------------------------------------------

Thanks, can you additionally provide an Asterisk debug log captured during a reproduction of the issue?

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

Oh, please capture this with Asterisk 13 or greater, as 11 no longer receives bug fixes and there are many major differences between 11 and 13..

Thanks!




was (Author: rnewton):
Thanks, can you additionally provide an Asterisk debug log captured during a reproduction of the issue?

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



> chan_sip: Wrong handling of 488  Not Acceptable Here during reINVITE
> --------------------------------------------------------------------
>
>                 Key: ASTERISK-26609
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26609
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/CodecHandling
>    Affects Versions: 11.12.0
>            Reporter: Andrzej Marchlewski
>            Assignee: Andrzej Marchlewski
>         Attachments: fwd to vmail fail in lab.pcap
>
>
> When r option is used in Dial application asterisk always issues re-Invite after initial dialog setup. If UA responds with 488 Not Acceptable Here asterisk will hangup the call immediately. Due to rfc3261 this behavior is incorrect. In section 14.1 it stands:
>  If a UA receives a non-2xx final response to a re-INVITE, the session
>    parameters MUST remain unchanged, as if no re-INVITE had been issued.
> Also section 4 of mentioned rfc it says:
> If the other  party does not accept the change, he sends an error response such as 488 (Not Acceptable Here), which also receives an ACK.  However, the  failure of the re-INVITE does not cause the existing call to fail -   the session continues using the previously negotiated characteristics.
> 488 response is handled in handle_response_invite function in chan_sip.c
> and causes execution of ast_queue_hangup_with_cause function
> We tested this behavior in version 11.12 however I can see in chan_sip.c that this scenario is handled in the same way in trunk and also in v13 branch.



--
This message was sent by Atlassian JIRA
(v6.2#6252)