Subject: Re: [MMUSIC] RTSP transport negotiation

From: Magnus Westerlund <[email-masked]>
Date: Mon, 03 Nov 2003 11:30:49 +0100

Hi,

In this matter, are there really a need to included a Range header to 
indicate when the SETUP request is to change parameters? What is the use 
case for this. You can't send the SETUP to move to the new transport 
prior to that the new transport interface exist. Therefore I don't see a 
problem with having it change parameters as soon as the request is 
received. Unless you have transport interfaces that remain available 
during some overlapping time you will of course have a result of losing 
packets during the switch.

Regarding the use of Range header in the SETUP. If appropriately 
motivated it can of course be changed. However the potential backwards 
compatibility problems needs to be considered. If this work becomes 
large in impact, we might have to consider splitting it into a separate 
document. However so far I don't think there are sufficient need.

I am sorry that I haven't had time to properly review your proposal.

Cheers

Magnus

-- 

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: Geetha Srikantan <[email-masked]>
Date: Tue, 04 Nov 2003 10:05:04 -0800

hi Magnus,

My assumption was that SETUP during play happens *after* the client has
switched to the new transport..synchronization is an issue in this case.
I agree that if we can assume that the client requests new transport
before switching to the new transport, there is probably no
synchronization issue. I have two follow-up questions on this:

a) How does a mobile client get notified about new transports - such as 
   a new IP address?  How far ahead of time does the client get
   notified?

b) What is the range of time over which the transport switch happens?
   Consider a scenario where the client requests an IP address change
   for example, via SETUP with no Range, and the server starts sending
   packets to the new IP. Is there a chance that the buffers at the new
   IP get overrun, before the client switches to the new IP?
   It would help if the network guarantees that the transport switch
   will not lose any packets due to buffer overflows,
   
thanks
geetha  

-- 
Geetha Srikantan <[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 05 Nov 2003 12:23:32 +0100

Hi Geetha,

Thanks for your views. Comments inline

> synchronization issue. I have two follow-up questions on this:

Yes, I would also think that in most cases the application will not know 
about the change of transport until it actually happens. This will 
probably result in the loss of some media packets. This loss can be 
dealt with in a few different way depending on the what the application 
can use: media level retransmission, RTSP go back through PAUSE and PLAY.

However in regards the question about what your assumption are and why 
you need Range in the request I think your answer clearly points out 
that there are no need for Range in the Request. There seem to be 
reasons for it to be allowed in the Response, to indicate the correct 
new synchronization after the change of address.

So are you still seeing any need for Range in the SETUP request? If that 
can be motivated I definitely think there will be possibility to change 
the specification to allow for this. However this would need further 
investigation.

>    a new IP address?  How far ahead of time does the client get

I would say that this is not a question we can answer. I think we simply 
need to ensure that the solution works with both sufficient notification 
and without. However without overlap in transport availability, there 
will be losses of media packets.

>    will not lose any packets due to buffer overflows,

As I have stated prior I think we must require the client to have access 
to an interface it sends traffic to. If there is overlap I would assume 
that it can receive data on both during this period. I don't find it 
reasonable to get any guarantees from the networks. I would assume that 
any switch of network depends on the change of access technology, for 
example by switching from cable to WLAN or to 3G mobile network. The 
probability that there will exist any mobility functionality between 
these networks seems very small.

I think that we should design our solution to allow the mobility, only 
note that it may loss some packets

Cheers

Magnus Westerlund

---

From: Geetha Srikantan <[email-masked]>
Date: Wed, 05 Nov 2003 10:54:51 -0800

hi Magnus,

Yes, it looks like we can drop the Range header from SETUP request.
We probably want the Range header + RTP-Info in the SETUP response
for VOD streams...with the caveat that packets can be lost during the
switch. 

I don't believe all components of the RTP-Info header are relevant for
live streams that are 'reflected' by the server - here the server acts
as a translator. The RTP stream url is known, however the exact sequence
number and timestamp for RTP packets is determined by the source of the
live stream, not the server reflecting the stream. Hence, I recommend
that the RTP-Info carry no sequence number or rtptime for live streams.

Also, I noticed that the RTP spec requires change of SSRC when the
transport changes. This needs to be added to the transport negotiation 
notes.

I will update the notes and send it to the alias.

geetha