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

From: David R Oran <[email-masked]>
Date: Thu, 30 Jul 2009 10:39:59 +0200

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

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.

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.

---

From: "Jan Lindquist" <[email-masked]>
Date: Thu, 30 Jul 2009 12:56:06 +0200

Hello David,

At this stage I am not going to suggest that in ietf we try to glue SIP
with RTSP. What has been done by other SDO's is reflection of a need in
the area and it reflects in my view a need to perform an evaluation. The
simplest as you have suggest would simply to adopt MRCP but as you have
reflected I have to agree it is an overkill.

One of objectives by the authors of the draft is not to create yet
another protocol for trick play. We want to reuse as much as possible.
As a developer it allows for maximum reuseability if based on the
framework provided by RTSP. 

Again I do not want to conclude the direction that is taken but I think
it is important that ietf takes an active role in the area or further
work will be done outside the influence of ietf.

Regards,
JanL

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David R Oran
> Sent: den 30 juli 2009 10:40
> To: [email-masked]
> Subject: [MMUSIC] Quick written version of the taxonomy of 
> alternatives Imentioned at the mic at the end of the SIP/RTSP 
> discussion
> 
> 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. 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.
> 
> 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 
> 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
>