[asterisk-bugs] [JIRA] (ASTERISK-29222) chan_sip: Hold/Resume an sRTP call on a video enabled user-agent.

[Asterisk Team (JIRA)]

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

Asterisk Team updated ASTERISK-29222:
-------------------------------------

    Target Release Version/s: 16.16.0

> chan_sip: Hold/Resume an sRTP call on a video enabled user-agent.
> -----------------------------------------------------------------
>
>                 Key: ASTERISK-29222
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29222
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/SRTP
>    Affects Versions: 16.15.0, 18.1.0
>            Reporter: Alexander Traud
>            Assignee: Alexander Traud
>              Labels: patch
>      Target Release: 16.16.0
>
>         Attachments: sipura_video_hold_resume.patch
>
>
> On resume, the call ends. This happens likely when
> # the resuming callee has more media streams (like audio and video) than the caller (like audio-only) and
> # SDES-sRTP was negotiated between Asterisk and the callee.
> *Steps to Reproduce*
> are based on the Call Hold example from [RFC 5393 section 2.1|http://tools.ietf.org/html/rfc5359#section-2.1] with three additional constrains: Alice, (1) with her audio-only phone, calls Bob, with his (2) audio/video-enabled phone. Actually, Bob uses a Cisco IP Phone 8865 with Multiplatform Firmware (MPP, former Sipura). Asterisk is configured (3) with {code}directmedia=false
> videosupport=yes{code}in the configuration file {{sip.conf}}. In this call example, the problem originates after F16.
> *Expected Result*
> The call resumes with F19 from Asterisk: SIP status OK.
> *Actual Results*
> Asterisk ends the call with SIP status 488. Asterisk prints the warning ‘Rejecting secure video stream without encryption details’. With debug level 3, Asterisk prints ‘Received offer with crypto line for media stream that is not enabled’.
> *Fix*
> Although the call was established without video, because Alice did not offer video, Bob’s Cisco offers video while resuming. This is allowed and even the expected behavior as of [RFC 6337 section 5.3|https://tools.ietf.org/html/rfc6337#section-5.3]. However, within Asterisk, video was disabled for this session. Consequently, {{process_crypto(.)}} returns early because {{rtp}} is null. However, the following checks do not check whether {{p->vrtp}} is null.
> The attached patch adds that check. However, the call scenario showed that the very same check is missing some code lines as well. Now, after checking {{p->vsrtp}} twice, the call continues (with SDES-sSRTP, with audio, but without video). For symmetry reasons, I added the same two checks for sessions without audio.
> *Notes*
> - This is about SDES-sRTP. I did not check DTLS-sRTP and whether this is affected and/or fixed, too.
> - As per RFC, Asterisk has to offer the newly added video to Alice. However, this does not happen because chan_sip cannot add a new media stream mid-call, see ASTERISK-26637. Consequently, the video stays disabled even after resuming the call.



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