Summary:	ASTERISK-25864: chan_sip: Error when trying to handle reINVITE from Asterisk in Chrome (DTLS-SRTP related)
Reporter:	Kirill Marchuk (62mkv)	Labels:
Date Opened:	2016-03-24 06:18:11	Date Closed:
Priority:	Major	Regression?
Status:	Open/New	Components:	Channels/chan_sip/WebSocket Resources/res_rtp_asterisk
Versions:	13.7.2	Frequency of Occurrence
Related Issues:
Environment:	Client: Ubuntu 15.10; Chrome 49; jsSIP 0.7.17 Server: Debian 7; Asterisk 13.7.2; ARI	Attachments:	( 0) chrome49-ubuntu-jssip-reinvite-bug.log
Description:	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 ?
Comments:	By: Asterisk Team (asteriskteam) 2016-03-24 06:18:12.553-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Kirill Marchuk (62mkv) 2016-03-24 06:27:58.434-0500 this is a dump of jsSIP console logs, where all the incoming and outgoing SIP messages are present; along with the error that occurs By: Iñaki Baz Castillo (ibc) 2016-03-24 08:18:47.059-0500 > I have not found anything specific in that RFC about re-INVITEs It does not matter whether it is an initial INVITE or reINVITE. This is about SDP Offer/Answer. An SDP in a initial INVITE or a reINVITE is a SDP **offer** so it MUST conform to the text in RFC 5763:    ----------------------    The offer and answer MUST conform to the following requirements.    The endpoint MUST use the setup attribute defined in [RFC4145].    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.    ----------------------- Note however that, in WebRTC, DTLS must not be re-connected upon a SDP re-negotiation if a=fingerprint remains the same. This is, when re-offering (reINVITE in SIP) the offerer MUST send "a=setup:actpass", and the offered must set the proper value ("a=setup:active" or "a=setup:passive") that keeps the already DTLS established connection.