Subject: RE: [MMUSIC] Persistent Connection

From: "Enrico Balatti" <[email-masked]>
Date: Mon, 8 Sep 2003 09:29:27 +0200

Hi Magnus,

>> 
>> 
>>>2a. Close TCP connection to server
>>>2b. perform move to address B.
>> 
>> 
>> In this case the effects of the handoff on the streaming will be
>> probably worse respect the previous case because the client stops 
>> the session when it is yet reachable from the previous connection.
>> However, in this case the server doesn't continue to send in vain
>> traffic on the previous connection until time-out.
>> Moreover, this solution works with the RTSP Server I've tested while the 
>> above solution doesn't work (I don't know with other Servers)

>No, the server does not stop sending media in 2a. The only thing it did 
>was to close the RTSP TCP signalling connection not effect the media 
>transport. So this is simply an improvement of the above where the 
>server is able to retrieve the TCP connection resources quicker. 

OK but then I think could be usefull an alternative solution (also
in this case if there is time):

2a'. STOP streaming
2b'. Close TCP connection to server
2c'. perform move to address B.

In this case we will haven't waste of bandwidth and also waste of RTSP server resources.

Obviously we will need also:

4a. Client does Re-setup of transport parameters to move media delivery 
to address B.
4b. Client re-start the session from the point it left in the old connection.

>> I think this consideration is in particular way true for live session
>> while in the case of streaming the client can resetup the session from
>> the last packet received from the old connection.

>I don't quite understand you here. Do you mean that the client should do 
>the resetup when it stops receiving media on address A? I think this is 
>inefficient and will result in unnecessary losses. In my opinion the 
>best case is to do the resetup if you have both addresses available. 
>That way any media to A can clear the network from the point where the 
>resetup is successful and the media delivery address has changed to B.

No, my sentence was intended to mitigate the effects of handoff on the quality of
the streaming in the case no soft-handoff is used. If the session is not a live session, the stream
could be re-setup and re-started from the exact point it was in the previous connection. 
If I'm watching a movie, I would like to see all the movie without loosing any frame.

Best Regards,
Enrico

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: lunedì 8 settembre 2003 8.34
To: Enrico Balatti
Cc: IETF MMUSIC WG
Subject: Re: [MMUSIC] Persistent Connection

Hi Enrico,

Some comments below.

Enrico Balatti wrote:

> Hi Magnus,
> 
> only one consideration (advantage and disadvantage) about the two alternatives:
> 
> 
>>1. TCP connection exist from Client on Address A to server.
>>2. The client moves to address B.
>>3. The client connects from Client-B to server
>>4. Client does Re-setup of transport parameters to move media delivery 
>>to address B.
>>5. TCP connection from A to server times out, due to lack of traffic.
> 
> 
> In this case I think the effects of the handoff on the session will
> be minimized (it will depend only of the handoff time plus the time to 
> setup the new connection).

I am not certain it will be minimized. There are probably cases where 
the effects are even less, for example if two address can be hand for 
some overlapping period.
> 
> 
>>2a. Close TCP connection to server
>>2b. perform move to address B.
> 
> 
> In this case the effects of the handoff on the streaming will be
> probably worse respect the previous case because the client stops 
> the session when it is yet reachable from the previous connection.
> However, in this case the server doesn't continue to send in vain
> traffic on the previous connection until time-out.
> Moreover, this solution works with the RTSP Server I've tested while the 
> above solution doesn't work (I don't know with other Servers)

No, the server does not stop sending media in 2a. The only thing it did 
was to close the RTSP TCP signalling connection not effect the media 
transport. So this is simply an improvement of the above where the 
server is able to retrieve the TCP connection resources quicker.

> 
> I think this consideration is in particular way true for live session
> while in the case of streaming the client can resetup the session from
> the last packet received from the old connection.

I don't quite understand you here. Do you mean that the client should do 
the resetup when it stops receiving media on address A? I think this is 
inefficient and will result in unnecessary losses. In my opinion the 
best case is to do the resetup if you have both addresses available. 
That way any media to A can clear the network from the point where the 
resetup is successful and the media delivery address has changed to B.

One more consideration is in the area of using destination for this. As 
I see it, the client will need to use destination parameter in the 
transport header. It seems that the destination address will be the same 
as for the TCP connection. However there might be considerations on how 
the foreign address blocking is handled in these cases. I think the 
there are some security considerations that needs to be addressed.

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