Re: [MMUSIC] Quick written version of the taxonomy of alternatives I mentioned at the mic at the end of the SIP/RTSP discussion

[Jouni Mäenpää <jouni.maenpaa at ericsson.com>]

Hi David,

> Since it seems the WG didn't sow much support for gluing the existing
> SIP and RTCP protocols together as proposed in the sip-rtsp draft, I
> offered three alternatives that might represent a decent technical way
> forward and that meet the same (technical) goals as articulated in the
> draft. 

If I recall correctly, there was no indication during the MMUSIC meeting
that the WG wouldn't support "gluing" SIP and RTSP together. The
discussion focused entirely on whether the WG would be interested in
working on the topic of interaction between the session establishment
and content control protocols (using the terminology defined in the
draft) and not on the technical details. Therefore, I would consider the
use of SIP/SDP to establish a control channel for RTSP as one further
possible way forward along with the three alternatives you are
proposing. More comments below.

Regards,
Jouni

> They clearly don't meet the goal of trying to use SIP and RTSP
> "as-is".
> 
> 1. Do a "system reset" on the RTSPv2 specification in order to make it
> capable of being used in the same overall signaling architecture the
> proponents today use SIP for (e.g. IMS environments). This entails
> giving up on full backward compatibility with RTSP v1 (which we don't
> have in practice anyway, and we have no RTSPv2 deployment yet to worry
> much about). We would re-cast RTSPv2 to use SDP offer-answer and ICE
> exactly as they are used by SIP, instead of the hybrid media description
> used in the current RTSPv2 specification. We could also import the
> P-header extension set to get the same IMS features for RTSP as we have
> for SIP. This would preserve the existing RTSP addressing model, its
> media source selection model, and its failover model, none of which are
> straightforward with SIP.

I agree with the comments that Rémi Denis-Courmont sent earlier;
modifying RTSPv2 to use SDP offer/answer wouldn't probably be the best
way forward from the implementation point of view.

> 2. Design a new in-session control protocol for the media servers to
> give SIP sessions the same media control capabilities that exist in RTSP
> (e.g. play/pause/ff etc.). This would be negotiated with SDP offer
> answer just like the media itself and other in-session control schemes
> like floor control in conferences.

The risk with this alternative is that we would end up re-specifying
much of what has already been specified for RTSP in the new in-session
control protocol.

> 3. Adopt MRCPv2 as an in-session media control protocol. MRCPv2 arguably
> has EVERYTHING needed - play, pause, scale, skip, etc. and is already
> fully integrated with SIP and deployed enough to have confidence that it
> will glue together correctly. The disadvantage is the MRCPv2 is gross
> overkill for the simple media control problem. 

I tend to agree with you in that the use of MRCPv2 would probably be an
overkill.

> It might be possible to
> define a minimal subset or "profile" that would be light weight, but I
> haven't even begun to think through the details to see if this would be
> easy or hard.
> 
> As an designer/implementer of both media servers and embedded streaming
> media clients, I find any of these more attractive than trying to glue
> SIP and RTSP together using interworking, state machine tricks, etc.
> 
> Thanks for listening,
> 
> DaveO.
> 
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>