[asterisk-bugs] [JIRA] (ASTERISK-25864) chan_sip: Error when trying to handle reINVITE from Asterisk in Chrome (DTLS-SRTP related)

[Joshua Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp updated ASTERISK-25864:
-----------------------------------

    Summary: chan_sip: Error when trying to handle reINVITE from Asterisk in Chrome (DTLS-SRTP related)  (was: Error when trying to handle reINVITE from Asterisk in Chrome (DTLS-SRTP related))

> chan_sip: Error when trying to handle reINVITE from Asterisk in Chrome (DTLS-SRTP related)
> ------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-25864
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25864
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/WebSocket, Resources/res_rtp_asterisk
>    Affects Versions: 13.7.2
>         Environment: Client: Ubuntu 15.10; Chrome 49; jsSIP 0.7.17
> Server: Debian 7; Asterisk 13.7.2; ARI
>            Reporter: Kirill Marchuk
>         Attachments: chrome49-ubuntu-jssip-reinvite-bug.log
>
>
> When a call is placed on a WebRTC peer, who is connected from a jsSIP-based web-page on Chrome 49 (although, the same happened with Chrome 47 and with sipML also), Asterisk sends an INVITE with a=setup:actpass attribute in SDP. 
> Peer answers 200 OK, it's channel is added to a bridge (via ARI), then another (caller's) channel is also added to a bridge and Asterisk performs "ast_indicate_data" function call with AST_CONTROL_CONNECTED_LINE, which to leads to re-INVITE being sent, which contains "a=setup:passive" line, which leads to a 
> rtcninja:ERROR:RTCPeerConnection setLocalDescription() | error: +2ms Failed to set local answer sdp: Failed to push down transport description: Offerer must use actpass value for setup attribute.
> This error occurs internally at Chrome. As Inaki Baz Castillo, lead maintainer of jsSIP, explained me, "This is bug in Asterisk, as offerer MUST provide "a=setup:actpass", and Asterisk is the offerer in this case, I suppose. 
> I've checked RFC 5763, and it says, indeed:
>       The endpoint that is the offerer MUST use the setup attribute
>       value of setup:actpass and be prepared to receive a client_hello
>       before it receives the answer.
> Seems like Chrome is (since some time) very "scrupulous" about that thing, because exactly same case is working all right with Firefox. However, as it's clearly stated in RFC, it would be hard to post a bug on Chrome bugtracker.
> I have not found anything specific in that RFC about re-INVITEs, but it has a section 6.6. titled "Session Modification" which might be related. 
> Can anyone have a look at that and let me know if it's really a problem with Asterisk or some other thing ? 



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