Subject: [MMUSIC] RTSP-SIP mismatch

From: Anders Kristensen <[email-masked]>
Date: Tue, 10 Jul 2007 20:39:27 -0700

I wonder if anyone has run into the following problem related to a 
mismatch between RTSP and SIP in a case where a 3rd party controller 
sets up a SIP dialog with a UA and wants to tell an RTSP server to send 
media to the UA. The call flow might look like the this:

   RTSP server         controller            SIP UA
        |                   |                   |
        |(1) RTSP DESCRIBE  |                   |
        |<------------------|                   |
        |(2) 200 (SDP)      |                   |
        |------------------>|                   |
        |                   |(3) INVITE (offer) |
        |                   |------------------>|
        |                   |(4) 200 (answer)   |
        |                   |<------------------|
        |                   |(5) ACK            |
        |                   |------------------>|
        |(6) RTSP SETUP     |                   |
        |<------------------|                   |
        |(7) 200            |                   |
        |------------------>|                   |
        |(8) RTSP PLAY      |                   |
        |<------------------|                   |
        |(9) 200            |                   |
        |------------------>|                   |
        |(10) RTP           |                   |
        |.......................................|
        |                   |                   |
        |                   |                   |

The specific problem is that the SIP UA says in the SDP answer carried 
in the 200 response that for some media stream it wants to receive RTP 
with payload type 96, say, but the RTSP server insists on sending RTP 
with payload type 126.

According to the SIP offer/answer model the SIP UA gets to say what it 
wants to receive but AFAIK RTSP doesn't let the client (the controller 
in this example) pass these instructions on to the RTSP server, at least 
not for the payload type.

Am I missing something in the RTP spec? I browsed through rfc2326bis 
without seeing it addressed but it seems like a valid scenario.

Thanks,
Anders

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Jul 2007 09:46:38 +0200

Hi Anders,

I think you are getting into places where specification hasn't gone. 
Interaction between SIP and RTSP are not really specified. RTSP has a 
model where media configuration is done by the server saying something 
and the client has the choice of taking it or leaving it. There is no 
negotiation of media parameters. The only thing that I know of that can 
affect the SDP is that the describe included a capability description of 
the client. That allows the server to tailor the session description to 
the clients capabilities. But that wouldn't solve the issue you have.

This is an collison in regards to the models used for media 
configuration that I don't think have an easy answer. The only way to 
resolve this would be to indicate to the client in the Invite SDP that 
these sendonly streams can't be changed in regards to media 
configuration so take it or leave it.

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 11 Jul 2007 12:22:37 -0700

Hi Magnus,

OK, that's what I thought was the case. I think this scenario needs to 
be supported, though. It seems like a very basic and reasonable thing to do.

I think it's fair to say that SIP is in wider use than RTSP at this 
point and I don't see much chance of the SIP offer/answer model being 
changed to accomodate this issue so I would actually suggest that it 
should be a requirement of rfc2326bis that it improve on the SIP-RTSP 
interop situation.

Thanks,
Anders

Magnus Westerlund wrote:
>> sets up a SIP dialog with a UA and wants to tell an RTSP server to 
>> send media to the UA. The call flow might look like the this:
>>
>> in this example) pass these instructions on to the RTSP server, at 
>> least not for the payload type.
>>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 Jul 2007 09:39:37 +0200

> should be a requirement of rfc2326bis that it improve on the SIP-RTSP 

I would actually challenge this statement, at least in regards to RTSP 
1.0. RTSP 1.0 is today deployed and in use by media player such as 
Quicktime, RealPlayer, and Windows Media Player. In addition there are 
some hundred million cell phones supporting streaming that uses RTSP. 
Meaning that bascially all PCs and a large percentage of mobile devices 
do have at least one RTSP implementation. I think that is a significant 
larger deployment than SIP currently has in the number of devices.

But having said that I think there is an interesting discussion. But 
from my point of view totally redesigning RTSP to support offer/answer 
compared to an indication in offer/answer that you better take things as 
they are, is on two very different levels of changes. I would also like 
to point out that RTSP looks like it does because for on-demand or 
shared live content most of the parameters are not negotiable at all 
becuase they are written into the file the server has or the source 
stream. I think this is a fact that one has to have in mind when 
discussing these things.

Cheers

Magnus Westerlund

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 12 Jul 2007 20:32:05 -0700

Magnus,

So if I understand you correctly you're saying that yes, there is a an 
issue that ought to be addressed but in your view it should be addressed 
in SIP, not RTSP?

I suggested RTSP because I thought, mistakenly perhaps, that it is less 
mature and therefore more amenable to change. In my head RFC 2326 is 
more or less on par with SIP as defined in RFC 2543 making rfc2326bis 
the equivalent of RFC 3261. If 2326 is as widely deployed as you say 
then that certainly makes the comparison less than perfect.

When you talk about shared live content you're thinking about a 
multicast scenario? There are RTSP features that have to do specifically 
with setting up point-to-point streams so AFAICT passing payload type 
from the client to the server is not particularly at odds with RTSP as 
such. It could be added to the Transport header field along with the 
client's IP and port. I guess it would either have to be considered a 
hint or else an extension token would have to be added.

OTOH, I would find it tempting to have RTSP adopt SIP's offer/answer 
model more wholesale, possibly in addition to a mode where the server 
just announces the session parameters in support of broadcast-type 
scenarios. Should be possible to do something like that in a backwards 
compatible manner although I can't say I've thought it through.

Thanks,
Anders

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 13 Jul 2007 10:22:09 +0200

> issue that ought to be addressed but in your view it should be addressed 

Yes, Yes, and not because of maturity, but because of what I see as the 
correct place to implement the solution. As I said, fixing this issue in 
RTSP seems to imply that RTSP suddenly are forced to have two way media 
negotiation.

> then that certainly makes the comparison less than perfect.

I don't want to make parallels here. From a specification point of view 
regarding majurity I think your view holds. But not from reality and 
deployed base. RTSP 2.0 will be hard to get deployed, and I think the 
main advantage will be faster setup and standardized NAT traversal may 
get it deployed as soon as we can finish it.

> hint or else an extension token would have to be added.

No, I am talking about unicast distribution using tree likes structures 
from a source where the setup and control of the flow from last tier 
servers to clients are done with RTSP. In this case the server may 
simply copy any incoming packets into multiple out-bound unicast flow 
and performs no per packet processing.

I don't think what you propose realy flies well. Of course you could 
make a hack that only works under certain circumstances by passing a PT 
remapping in the transport header. However, what I think needs to be 
considered here are the model.

> compatible manner although I can't say I've thought it through.

Well, that has been discussed but never taken anywhere. I think one 
needs to start in considering what the needs really are. And if one want 
to do real negotiation one should go for a three step negotiation model 
with. A->B: A's Capabilites, B->A: B's Capabilites + B's configuration, 
A->B: A's congfiguration + ACK. Because Offer/Answer is simply broken 
for any more advance cases, like assymetric configurations.

Cheers

Magnus Westerlund

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Wed, 18 Jul 2007 13:02:21 -0400

Magnus: Anders:

As I understand this we are talking about a level of SIP and RTSP to
interwork either via a gateway or otherwise.  At the San Diego meeting a
group of us had submitted a draft that talked about SIP RTSP
interworking except in that case we tried to wrap the RTSP that needed
to be transported inside a SIP message's sdp.  I know the approach was
different but the logical goal I believe was the same.  If we are ready
to revive the idea of SIP-RTSP interworking, we will be happy to revive
draft-marjou in a new incarnation in collboration will everybody to get
this going.

I will also be in chicago and be happy to chat about potential
mechanisms and how to ...

Sam

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Friday, July 13, 2007 4:22 AM
To: Anders Kristensen
Cc: mmusic (E-mail)
Subject: Re: [MMUSIC] RTSP-SIP mismatch

> issue that ought to be addressed but in your view it should be 
> addressed in SIP, not RTSP?

Cheers

Magnus Westerlund