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

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Sun, 2 Aug 2009 22:03:39 +0300

Le jeudi 30 juillet 2009 11:39:59 David R Oran, vous avez écrit :
> 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.

Offer-answer would simplify the specification work at the expanse of the (much 
more costly) implementation works. VoIP stacks are _not_ usually the same as 
media playback stacks. Using the same protocol would unavoidably cause 
impedance mismatches (some will be discovered too late in the specification 
work flow) and troubles from user interface stand point. In other words, we 
would screw up RTSP *again*, and have to wait for another ~15 years until... 
RTSP/3.0 actually works.

Media playback and multi-party sessions have very different logic. RTSP fits 
the media player model and control rather well: play, pause, seek, stop... SIP 
does not, at all: invite uh? Also, those things are significantly different on 
the media path. In SIP, RTP must be optimized for low-latency. In RTSP (and 
SAP too), buffering latency is more tolerable.

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

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

Those two make more sense to me.

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

Might well be. I don't figure out what "gluing" means here.

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary

---

From: Jouni Mäenpää <[email-masked]>
Date: Mon, 24 Aug 2009 15:37:15 +0300

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

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>