Subject: RE: [MMUSIC] RTSP transport negotiation

From: "Enrico Balatti" <[email-masked]>
Date: Wed, 5 Nov 2003 09:58:15 +0100

Hi,

comments inline:

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

In my opinion the notification can be done in two different ways:

1) you have have a mobile client application(like MobileIP, CellularIP etc..) 
   running on you mobile host. In this case this application can inform you when
   the handoff happens (before or after the switching to a new AccessPoint).
   and if you have changed your IP address or you are reachable from outside the new domain
   via a new Public IP address.
 
2) you have not a mobile client application. You get a new IP address via DHCP.
   In this case I think the dhcp client should sends you a trigger to inform of the change.

While the 1) can be a very quickly method, I think that 2) is very slowly due to the dhcp protocol.

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

I think that your assumption that "the SETUP during play state happens after
the client has switched to the new handoff" is right. 
Its is very common that when a mobile host enters in a new IP domain, it gets
a private IP address or if it use a mobile protocols application, this protocol allows
it to maintain its "home address". In both these case the mobile host will be reachable
from the "internet" via a Public IP address (NAT). So, in the case of rtsp, the mobile client
in a play state has to know the new Public IP address an rtp ports (for example using the stun protocol), 
create the binding on the NAT, and then send the SETUP with the new "client_ip".

Best Regards,

------------------------------------------------------------------
Ing Enrico M. Balatti
CEFRIEL - Politecnico di Milano
ICT Center of Excellence For Research, Innovation,
Education & industrial Labs partnership
via Fucini 2, 20133 Milano (ITALY)
voice: +39 0223954327 fax: +39 0223954527
e-mail: [email-masked] <mailto:[email-masked]>   www.cefriel.it <http://www.cefriel.it> 
------------------------------------------------------------------

-----Original Message-----
From: Geetha Srikantan [mailto:[email-masked]]
Sent: martedì 4 novembre 2003 19.05
To: Magnus Westerlund
Cc: Enrico Balatti; [email-masked]
Subject: Re: [MMUSIC] RTSP transport negotiation

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  

On Mon, 2003-11-03 at 02:30, Magnus Westerlund wrote:
> 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
-- 
Geetha Srikantan <[email-masked]>

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

---

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

Enrico,

Thanks for the background..this helps to understand the scenario better.

geetha