Subject: [MMUSIC] Review of draft-marjou-mmusic-sdp-rtsp-01

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 4 Mar 2008 13:53:57 +0100

Hi all,

I did a review of draft-marjou-mmusic-sdp-rtsp-01, mainly for curiosity why this is needed.
I didn't find the answer in this draft yet. 

The draft proposes a coupling between SIP and RTSP. Whereas SIP is used for session control and RTSP for media streaming control. 

Here are some detailed comments:
- Section 1 Intro: It states that SIP is used as rendezvous point and for NAT traversal. However, there is no word at all about RTSP 2.0's NAT traversal support. Is this intentionally left out or did you just miss this?

- Section Problem Analysis: I actually do miss the content in here. The problems reported are more or less just supposed problems, but no stuffed with real meat. For instance, in the second para (the video surveillance thingy) it is not obvious at all why RTSP is not working... And it is not that clearly "RTSP only or another media control protocol is not sufficient".
However, the only reasoning that is obvious is written in the last paragraph (yes -- there are other standards bodies). This reason is also highlighted by Section 13. 

- Section 7, 1st para establishment of media control...: Why is actually required to negotiate SDP? You anyway write that the SDP description of the presentation is downloaded by some other means, such as HTTP. Negotiating SDP would be only required if the SDP offered by the server is not known in advance or by means of RTSP's DESCRIBE, http, etc.

- Section 7, general: I assume that the terminology got mixed up somehow or the different ideas are not presented properly, at least to my understanding. Or why should step one setup the media delivery channel? Isn't it first about negotiation what should happen in the media delivery channel? Setup would be done later by RTSP. Or do I miss the point here?

- Section 7, general: What is the error correlation between the SIP and RTSP part? Who is in charge for controlling the RTP streams (if used)?

I have read any further, as, at least IMHO, the technical base in the first seven sections is weak and hard to understand. 

  Martin

[email-masked]   <== NEW ADDRESS

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 10 Mar 2008 14:01:59 +0200

Le Tuesday 04 March 2008 14:53:57 ext Martin Stiemerling, vous avez écrit :
> I did a review of draft-marjou-mmusic-sdp-rtsp-01, mainly for curiosity why
> this is needed. I didn't find the answer in this draft yet.
>
> The draft proposes a coupling between SIP and RTSP. Whereas SIP is used for
> session control and RTSP for media streaming control.

Yep, I think I have same feeling as you and Jonathan seem to have.

I can understand a server/the network would want to "invite" a client to watch 
a media, but I don't see the need to define yet another streaming protocol 
for this - referring to an RTSP resources inside the SDP INVITE ought to be 
sufficient, would it not??

That can convey the RTSP URL and any extra parameter, such as the intended 
list of media or the Seek offset(s) also...

-- 
Rémi Denis-Courmont

---

From: "Xavier Marjou" <[email-masked]>
Date: Tue, 11 Mar 2008 14:11:13 -0400

Hi Remi,

>  list of media or the Seek offset(s) also...

With the "rtsp-as-a-media-control-stream" approach, the initiated
session later enables the streaming server to terminate the session
whenever it needs it. With the "rtsp-triggered-by-sip" approach this
can not be done ... unless an extension (like an RTSP BYE message) be
specified to extend the set of existing RTSP messages.

Cheers,
Xavier

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 11 Mar 2008 21:02:40 +0200

Le Tuesday 11 March 2008 20:11:13 Xavier Marjou, vous avez écrit :
> >  I can understand a server/the network would want to "invite" a client to
> > watch a media, but I don't see the need to define yet another streaming
> > protocol for this - referring to an RTSP resources inside the SDP INVITE
> > ought to be sufficient, would it not??
> >
> >  That can convey the RTSP URL and any extra parameter, such as the
> > intended list of media or the Seek offset(s) also...
>

I'd defer to Magnus and Martin - still as far as I understand, there are ways 
to do this with RTSP, and it's being improved in 2.0. And even then, the RTSP 
server can always stop if it wants to - any remotely resilient RTSP client 
will consider the stream as terminated if hasn't received anything for a 
while - but that's beyond the point.

Also, the server could send a SIP CANCEL or SIP BYE if you want to "wrap" the 
RTSP session within a SIP one.

A new media control protocol looks like a bulldozer to crush a mosquito to me.