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

[Iñaki Baz Castillo (JIRA)]

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

Iñaki Baz Castillo commented on ASTERISK-25864:
-----------------------------------------------

> 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.

> 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)