Subject: Re: [MMUSIC] SIP-RTSP draft

From: Magnus Westerlund <[email-masked]>
Date: Sun, 05 Nov 2006 13:29:17 -0800

Hi,

After having taken a quick look I do have a few top level comments about 
the proposal.

1. It is not at all clear how a client can be the offerer towards the 
server. The client needs to have a description of the session it is 
going to produce a offer for. Thus you need to have a mechanism that 
performs equal to DESCRIBE. Sure using HTTP or similar to fetch the SDP 
for a resource would work.

2. I also think trying to define this for RTSP 1.0 is a bad idea. The 
reason is that what is actually is the used RTSP 1.0 is not documented. 
It is a substantial subset of RFC 2326 with some fixes and a lot of 
fixes towards individual implementations. Without interop events RTSP 
would not work. In addition if you are serious about this, we can at 
least look if this would be easier to realize by some minor changes to 
RTSP 2.0. However that would delay that document further unless you are 
willing to provide editing resources also here.

3. I am also a bit frightened by the attempt to simple include the RTSP 
headers into the offer answer exchange. This is after all an attempt to 
replace multiple requests with a single offer/answer exchange. Thus one 
needs to take a lot of care to determine how one maps the headers and 
there functions.

4. I also think there is important to look at what happens with the 
security issues when using SIP for setup. There is a big risk that one 
exposes the session ID much more. And the session ID is the major 
protection against hijacked session control. Also the DDos issue for 
this solution can possibly be a couple of magnitudes more dangerous than 
the voice hammer, due to that streaming content may be significantly 
more bits. Thus requirement on actually verifying the media path may be 
required in this case.

5. There is also the issue on how to handle different usage scenarios. I 
think for SIP setup control there are several interesting contexts 
related to multi-party sessions. Thus the ways of handling the control 
and how the media is distributed needs to be considered. As I see it 
there is need to consider what this proposal do result in terms of 
functionality and usage.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Xavier Marjou" <[email-masked]>
Date: Wed, 08 Nov 2006 22:01:50 -0800

Thanks for the comments.
See my response inline.

Xavier

> for a resource would work.

With one of the 2 following methods, the RTSP DESCRIBE is probably not 
needed:
- one agent (with rtsp client) send an SDP-offer that includes an rtsp 
stream and any media stream it can support, the peer agent answers with a 
SDP-answer that includes an rtsp stream and the media streams under "rtsp" 
its control.
- one agent (with rtsp client) can send a session initiation message 
without SDP in order to let the peer generate the SDP offer.

In case an alternative to RTSP-DESCRIBE is nevertheless needed, it may be 
that a SIP-OPTIONS is used to fecth SDP capabilities (cf section 9 of 
RFC3264). However, we have not investigated this option so far.

> would not work. 

I tend to agree here.

> needs to take a lot of care to determine how one maps the headers and

These rtsp headers carried within SDP result from the fact that the SETUP 
is not used. Not using the SETUP has the following advantages: it saves one 
roundtrip message and removes the conflict for media addresses/ports 
between the RTSP Transport header and the SDP offer/answer. The drawback is 
that there are possibly many headers that need to be carried within SDP. 
Maybe we went too far by removing the whole SETUP message.

> more bits. Thus requirement on actually verifying the media path may be

I see here some more arguments to keep the SETUP (or at least most of it). 

> there is need to consider what this proposal do result in terms of

Agreed, we need to include some more description about the different usage 
scenarios. We can provide some of them, and we will also be happy to 
include yours.

---

From: <[email-masked]>
Date: Mon, 13 Nov 2006 10:33:11 +0530

Comments inline.

Regards,
Ravi.

--
 
Ravishankar. G. Shiroor
Wipro Technologies, Bangalore.
 
[email-masked]
--

> -----Original Message-----
> From: Xavier Marjou [mailto:[email-masked]] 
> Sent: Thursday, November 09, 2006 11:32 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [MMUSIC] SIP-RTSP draft
> 
> Thanks for the comments.
> See my response inline.
> 
> Xavier
> 
> 
> > performs equal to DESCRIBE. Sure using HTTP or similar to fetch the 
> > SDP for a resource would work.
> 
> - one agent (with rtsp client) send an SDP-offer that 
> includes an rtsp stream and any media stream it can support, 
> the peer agent answers with a SDP-answer that includes an 
> rtsp stream and the media streams under "rtsp" 
> its control.
> - one agent (with rtsp client) can send a session initiation 
> message without SDP in order to let the peer generate the SDP offer.
> 
> In case an alternative to RTSP-DESCRIBE is nevertheless 
> needed, it may be that a SIP-OPTIONS is used to fecth SDP 
> capabilities (cf section 9 of RFC3264). However, we have not 
> investigated this option so far.
> 
> 
> > 3. I am also a bit frightened by the attempt to simple include the 
> > RTSP headers into the offer answer exchange. This is after all an 
> > attempt to replace multiple requests with a single offer/answer 
> > exchange. Thus one needs to take a lot of care to determine how one 
> > maps the headers and there functions.
> 
> These rtsp headers carried within SDP result from the fact 
> that the SETUP is not used. Not using the SETUP has the 
> following advantages: it saves one roundtrip message and 
> removes the conflict for media addresses/ports between the 
> RTSP Transport header and the SDP offer/answer. The drawback 
> is that there are possibly many headers that need to be 
> carried within SDP. 
> > this solution can possibly be a couple of magnitudes more dangerous 
> > than the voice hammer, due to that streaming content may be 
> > significantly more bits. Thus requirement on actually verifying the 
> > media path may be required in this case.
> 

Two comments on this concern:

1. If setup is being done by SIP and trick play control through RTSP,
there needs to be some kind of correlating id, which is what Session id
is being used for here. If session Id is not used, some other Id will be
used, which can also lead to session hijacking if exposed.

2. SIP security considerations should take care of not exposing the
session Id to those who are not supposed to know the session Id to
prevent the risk of session getting hijacked.

> 
> 
> > 5. There is also the issue on how to handle different usage 
> scenarios. 
> > I think for SIP setup control there are several interesting 
> contexts 
> Agreed, we need to include some more description about the 
> different usage scenarios. We can provide some of them, and 
> we will also be happy to include yours.
> 
> 
> 
> 
>