Subject: Re: [MMUSIC] RTSP: Transport negotiation

From: Geetha Srikantan <[email-masked]>
Date: Wed, 10 Sep 2003 16:58:07 -0700

hi Magnus,

Thanks for clarifying all the points earlier..here are a series of messages
responding to some of the items.
My notes on transport negotiation are at the end of this message:

Magnus Westerlund wrote:

> >
> > Page 10: Transport Negotiation
> > Can transport parameters of an existing session be changed, mid-stream?
> > For instance, is it possible to change the server's RTP/RTCP ports
> > mid-stream?
>
> Yes, If the server implements it and allows it. As seen by the
> application mobility discussion this functionality can be used for this.
>
> > If so, exactly how does the transition to using the new ports happen? Do some
> > mechanisms need to be specified to ensure synchronization etc after the cutover?
>
> Upon the successful response to a SETUP request to change the transport
> parameters the server will start using the new parameters. The client to
> avoid losing any packets should keep the old ports/transport open for a
> couple of seconds. The client should also have opened its ports for the
> new transport prior to sending the request. So I don't believe there are
> any synchronization problem.
>
> > If not, it would be good to specify the states in which transport negotiation
> > can be done.
>
> This is currently specified in the state machine. If supported is must
> be possible in READY state, and MAY be supported in PLAY state. This can
> probably be a clarified and simplified by tightening the requirements a
> bit. The text in section 11.3 can probably be improved to be more clear
> about what is allowed in this respect.

It would help to tighten the spec for the 'play' state, particularly.
Would the following be an accurate description of what happens?

Upon receiving a SETUP request to change transport parameters, while the
server is in 'play' state, the server determines the point at which to switch to
streaming
to the new transport and the server, at this point, stops streaming this track to the
previously specified
transport.

Question: Is there any need for an RTPInfo header in the SETUP response here?
I notice that the spec requires a RTPInfo header to the SETUP request, while in play
state, when
adding a new media stream, for example.

thanks
geetha

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

---

From: Geetha Srikantan <[email-masked]>
Date: Wed, 10 Sep 2003 17:05:49 -0700

Magnus Westerlund wrote:

> >
> > Page 15, 3rd paragraph, it might help to rephrase to say that FQDNs
> > are preferred, especially for IPv6, (maybe even 'required for IPv6 ?)
> > however IP addresses should also be supported (for backward
> > compatibility).
>
> I think we have a good level now. First of all the requirement to use
> FQDNs to handle IPv6 hosts only applies to RFC 2326 servers, not the
> ones in accordance with this specification. There are also reasons why
> one might use literal IP addresses. For example in destination fields, a
> FQDN name that resolve only to the targeted host may not exist. Also
> there are some performance issues if proxies needs to do DNS requests
> for all messages it is forwarding.
>
> >
> > Page 31, section 9.4, 1st paragraph, 4th sentence s/must/should/?
> > I.e. 'This requires that any RTSP URL pointing tat a IPv6 host should
> > use fully qualified domain name and not a IPv6 address.'
> >
> It is a informal must, not a normative one. This paragraph is only for
> information on how to make this work if the other party does not support
>   the updated specification. Are there any problem with this?

Thanks..this clarified it. My interpretation is that FQDNs are preferred, especially
for
IPv6 support in rfcs 2326 implementations. However IP addresses are acceptable for
various reasons, as you mentioned.

geetha

---

From: Geetha Srikantan <[email-masked]>
Date: Wed, 10 Sep 2003 17:07:48 -0700

Magnus Westerlund wrote:

> >
> > Page 38: liveness:
> > Should there be a mention of signs of liveness - no RTCP and no TCP
> > KeepAlive implies the session is gone?
>
> How do you interpret the second last paragraph and bullet list of
> section 11.3? There are also a reference to section 13.37 that discuss
> this further.
>
>  From the text of section 11.3:
>
> "Signs of liveness for a RTSP session are:
>
>       + Any RTSP request from a client which includes a Session header
>         with that session's ID.
>
>       + If RTP is used as a transport for the underlying media streams,
>         an RTCP sender or receiver report from the client for any of the
>         media streams in that RTSP session."

Looks good..

gs

---

From: Geetha Srikantan <[email-masked]>
Date: Wed, 10 Sep 2003 17:26:58 -0700

Magnus Westerlund wrote:

> >
> > Page 39, 4th paragraph, about the Range header. There is a mention
> > in section 3.5, 2nd paragraph, that 'now' should only be used for
> > live. This applies even in this section, right? I.e. the
> > recommendation to use npt=now- is for live?
>
> Yes. Is it not understandable that this sentence is in relation to the
> context of the previous sentence? Have you proposal for improvements of
> the text?

A suggested rewording for the 4th and 5th sentences of paragraph 4, page 39:
'For a session with live media streams the Range header MUST indicate a valid time
for this stream, either as "npt=now-" or an absolute time value for the corresponding
time as "clock=20030213T143205Z-"'

>
> >
> > Page 39, 5th paragraph - If there is no Range header in the request,
> > what should the response use as units for the Range header?
> > There was a suggestion that, if you do have the Range in npt, it can
> > be used, if not in the SETUP response there should be an indication of
> > the Range specifications that apply to the stream.
>
> Yes, this is a bit unclear. I propose it to clarify it in the following way:
>
> For a on-demand stream, the server {\MUST} reply with the actual
> range that will be played back.  This may differ from the
> requested range if alignment of the requested range to valid frame
> boundaries is required for the media source.  If no range is
> specified in the request, the start position {\SHALL} still be
> returned in the reply.  The unit of the range in the reply
> {\SHOULD} be the same as that in the request. If no range header
> was present in the request the server {\MAY} use any of the
> supported formats, however it is {\RECOMMENDED} that a format the
> client has shown support for is used. If the media part of an
> aggregate has different lengths the {\PLAY} request and any
> \header{Range} {\SHALL} be performed as long it is valid for the
> longest media. Media will be sent whenever it is available for the
> given play-out point.

This looks good.

>
> >
> > Also, it seems like the specification here is only for old
> > implementations, as newer implementations the Range header must be
> > sent in the request according to Page 41.
>
> No, it is for the updated specification. There is no requirement that a
> client includes a range header in a request. The range header MUST be
> present in responses. Please quote the section you have interpreted as
> requiring Range in PLAY requests.
>

Thanks for clarifying..I think it would help to add a note about the state in which
PLAY requests
are valid. In the current spec this is only in the Ready state.

>
> >
> >
> > Page 39, last paragraph - typo? Should it be
> > 'After playing the desired range, the presentation is NOT
> > automatically paused, media delivery simply stops. A PAUSE must be
> > issued before another PLAY request can be issued."
>
> Yes, type except that I would like to keep "request" in the last
> sentence after pause:
>
> "A PAUSE request must be issued before another PLAY request can be issued."
>

Sure..this is fine.

>
> >
> > Page 41, 2nd and 3rd paragraph: Here it says PLAY without range is not
> > ok - does this apply for stored content only? This seems to contradict
> > the text in the 3rd paragraph..
>
> My intention with the two following paragraphs:
>
>    "The queued play functionality described in RFC 2326 [21] is removed
>     and multiple ranges can be used to achieve a similar performance. If
>     a server receives a PLAY request while in the PLAY state, the server
>     SHALL respond using the error code 455 (Method Not Valid In This
>     State). This will signal the client that queued play are not sup-
>     ported.
>
>     The use of PLAY for keep-alive signaling, i.e. PLAY request without a
>     range header, has also been depreciated.  Instead a client can use,
>     PING, SET_PARAMETER or OPTIONS for keep alive. A server receiving a
>     PLAY keep alive SHALL respond with the 455 error code."
>
> Is that it is informs that while in PLAY state, a PLAY request is not
> allowed. This was in RFC 2326 used for two different purposes depending
> on if range was present or not (queued play, and keep alive). These two
> paragraphs try to explain what to do if one would receive a request that
> tries to perform such an operation. I will add a "in PLAY state" to the
> second paragraphs first sentence to be clearer.
>
> >
> > Page 43, 1st paragraph - is very confusing. Does this refer to the
> > case where the PAUSE request comes after the first occurence? Again it
> > seems like PLAY without a range header is ok...confusing.
>
> I guess it is not that confusing clearing out the previous confusion.

Thanks - yes the key item here is the state of the session when it receives the
PLAY request.
It migth help to add a couple of sentences that say something like:
"PLAY requests are valid when the session is in ready state; the use of PLAY requests
when the session
is in play state is deprecated."
Another possible clarification is to explicitly mention the cases:
PLAY request for stored media, with and without a Range header
PLAY request for live media, with or without a Range header.

A follow-up question on Range headers:

If an RTSP session has both live and stored media streams, how would this be
reflected in the Range header?

thanks
geetha

---

From: Geetha Srikantan <[email-masked]>
Date: Wed, 10 Sep 2003 17:30:53 -0700

Magnus Westerlund wrote:

> >
> > Page 44, section 11.6, 1st paragraph, suggested rewording of the last
> > few sentences:
> >
> > 'However the session and any other media not torn down yet, remains,
> > and any valid request, e.g. PLAY or SETUP, can be issued. As an
> > optional feature a server MAY keep a session even after the last media
> > on it has been torn down by use of TEARDOWN with a media URI for the
> > last media. In this cases, when the server continues to maintain a
> > valid session, after processing a TEARDOWN request on this session, the
> > server MUST return the session identifier in the TEARDOWN response.'
> >
> Yes, you where correct that the sentences need to be reworded. However I
> was not completely happy with your proposal either. So I propose the
> following:
>
> The {\TEARDOWN} request stops the stream delivery for the given
> URI, freeing the resources associated with it. If the URI is the
> aggregated control URI for this presentation, any RTSP session
> identifier associated with the session is no longer valid. The use
> of "*" as URI in {\TEARDOWN} will also result in that the session
> is removed independent of the number of media that was part of
> it. If the URI in the request was for a media within an aggregated
> session that media is removed from the aggregate. However the
> session and any other media not torn down yet, remains, and any
> valid request, e.g. PLAY or SETUP, can be issued. The server
> {\MAY} keep the session when the last media is torn down with a
> {\TEARDOWN} request specifying the media URI. The server {\SHALL}
> always include in a {\TEARDOWN} response the session header, if a
> valid session state exist after the processing of the request.
>

The wording looks good.

>
> However I have logged a bug suggesting that we remove the Ready-NM
> state. That way we can get rid of the "*" teardowns that I feel will not
> work satisfactory through proxies.
>
> > Page 44, section 11.6, last paragraph: It would help to move these
> > sentences to earlier in the section - to explain the motivation for
> > what's discussed in the sentences above.
>
> I don't think this provides any motivation. However it might be
> beneficial to change the the complete section into something that is
> more readable and more clearly explains things. One can also discuss the
> need for having TEARDOWN during PLAY state. Please provide input on this
> topic.

It would help to mention the state of the session, as the context for the sentences
in this
paragraph. Your reply helped to clarify this.

thanks
geetha

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 11 Sep 2003 09:15:10 +0200

Hi Geetha,

> Would the following be an accurate description of what happens?

I agree, being more clear about use of SETUP in PLAY state is needed.

> adding a new media stream, for example.
I don't think there is need for the Range + RTP-Info combination if the 
server ensures to keep the timestamp scale over the transport parameter 
switch.

The alternative is to include the Range and RTP-Info combination to 
indicate the new synchronization information. This would lower the 
requirements on maintaining the sync when doing transport parameter 
changes. Are there cases where this information is required?

I would like to have more input on this question. What is your opinion?

Best Regards

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]

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 11 Sep 2003 09:41:30 +0200

Hi,

Comments inline.

> time as "clock=20030213T143205Z-"'

The whole paragraph has been reworded into the following:

Server {\MUST} include a "Range" header in any PLAY response. The
response {\MUST} use the same format as the request's range header
contained. If no Range header was in the request, the NPT time
format {\SHOULD} be used unless the client showed support for an
other format. For a session with live media streams the Range
header {\MUST} indicate a valid time. It is {\RECOMMENDED} that
normal play time is used, either the now indicator "npt=now-", or
the time since session start "npt=96.23-". An absolute time value
(clock) for the corresponding time {\MAY} be given, i.e.
"clock=20030213T143205Z-". The UTC clock format {\SHOULD} only be
used if client has shown support for it.

> are valid. In the current spec this is only in the Ready state.

Yes, a PLAY is only valid to be issued from the Ready state. Do you want 
the note, for there are more states from which a PLAY is valid, or due 
to the fact that PLAY only can be used from Ready state.

> reflected in the Range header?

Depends on how the server indicates this session for the client. Either 
it looks like a stored on-demand session, and the live parts are hidden. 
  Which I think will be confusing if one tries to seek, etc.

If one signals this as a live session, I don't see a problem of pulling 
some of the media in an aggregate from a file. However as I see it this 
would normally be done by the content creator, like taped parts of TV news.

Do you see a special use for mixed session that we have problem fulfilling?

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 11 Sep 2003 09:43:10 +0200

Hi Geetha,

I have put a tracking bug on the TEARDOWN section for a complete rehaul. 
Anyone following this discussion is welcome to try.

cheers

Magnus

-- 

Magnus Westerlund

---

From: Geetha Srikantan <[email-masked]>
Date: Thu, 11 Sep 2003 15:45:53 -0700

hi Magnus,

A few more comments inline..

> I agree, being more clear about use of SETUP in PLAY state is needed.

Is this functionality intended to allow changing transport parameters for a session or for
specific tracks in the session?
If it is the former, then we are overloading the semantics of SETUP, somewhat.

In the second case,  a mechanism to associate the new SETUP request with an existing track
is needed.
The specification of the SETUP request  uses the session identifier and a *new* track url,
so it doesn't
cover this case. If just the session id is used, it doesn't uniquely identify an existing
track.
Some extra info is needed to make the association to an existing track...this could be an
additional header +  the existing track url.

Further, what aspects of the transport are allowed to be changed?
Looks like the client IP address can change. How about client ports?
Can the transport change from UDP to TCP (tunneled)  or vice versa?

I would urge that we only allow changing those transport parameters for which
there is a compelling usage scenario.  I would recommend that we consider specific
real-world
situations where this changing a specific transport parameter is expected to solve issues.

> I would like to have more input on this question. What is your opinion?

Well..let's see..where is this functionality going to be used?
Is it intended for cases where the client is mobile and hence gets a new IP address?
My concern is that there is no knowledge at the server about the exact point when the
switch from the client's old to new transport parameters occurs. Also, RTSP shouldn't have
to
know the specifics of the mobile network handoff mechanism..however RTSP needs to
provide for the case when this can happen.

So, let's assume the SETUP request from a client is received with an existing session id,
requesting change of client IP address to a new value.
Should the server assume that all subsequent packet transmissions for this track of the
session
are to be sent to the new IP address, from the same server side ports and to the same
client-side ports?
If this is not the case some additional information like the RTPInfo would be needed so
that
both the client and server know when the switch to new transport parameters occurs for
this stream.

Another case is when the client specifies new client-side ports via SETUP.
Does the client need to determine exactly when it has received all the packets on the old
port
and whether it can quit using the old port? If the client stops using the old ports too
soon, it might lose packets.
(Assuming as you had mentioned earlier that the client opens the new ports ahead of time,
so there is
no loss of packets at the new ports.)
If there are no strong requirements from the client-side, then it is probably ok
to let the server continue to use the same timescale and send packets to the
new client-side transport, starting after the reception of the SETUP request.

cheers,
geetha

---

From: Geetha Srikantan <[email-masked]>
Date: Thu, 11 Sep 2003 16:18:17 -0700

hi Magnus,

My comments inline..

> used if client has shown support for it.

This looks great.

> to the fact that PLAY only can be used from Ready state.

I'm a little confused - I realize that the client can choose to send a PLAY request at any
time,
regardless of what session state there is at the server. However, only PLAY requests
received in Ready state
can cause a change in state of the session and a transition to Play state.
Am I missing any other valid uses of the PLAY request?
Yes it would help to mention the cases where a PLAY request is valid, and causes any a
change in state.

..

> Do you see a special use for mixed session that we have problem fulfilling?

No, I didn't have a specific use in mind.

thanks
geetha

---

From: Tom Marshall <[email-masked]>
Date: Thu, 11 Sep 2003 16:20:01 -0700

> Is this functionality intended to allow changing transport parameters for
> a session or for specific tracks in the session? If it is the former, then
> we are overloading the semantics of SETUP, somewhat.
> 
> In the second case,  a mechanism to associate the new SETUP request with
> an existing track is needed. The specification of the SETUP request uses
> the session identifier and a *new* track url, so it doesn't cover this
> case. If just the session id is used, it doesn't uniquely identify an
> existing track. Some extra info is needed to make the association to an
> existing track...this could be an additional header + the existing track
> url.

If changing tracks means changing the stream url, I don't think this would
be an applicable use for exactly the reasons you state.

> Can the transport change from UDP to TCP (tunneled)  or vice versa?

My understanding is that any and all transport parameters are allowed to
change, including selecting a new transport type.

> I would urge that we only allow changing those transport parameters for
> which there is a compelling usage scenario.  I would recommend that we
> consider specific real-world situations where this changing a specific
> transport parameter is expected to solve issues.

One use case is to start in TCP mode, find that UDP is available, and switch
to UDP mode on the fly.

Another use case is to provide mobility for the client by changing IP
address.  In this case, the client could reconnect from its new address and
issue a new SETUP with the same transport and parameters.  Note the
destination parameter is not required here because the new RTSP socket
provides the new destination.

I don't know much about multicast -- is it possible that multicast/unicast
would be desirable to change?

> are to be sent to the new IP address, from the same server side ports and to the same

I think this depends on the usage.  If the client does not specify
client_port, it should default to the old value.  Should the server be
allowed to specify a new server_port value?  Perhaps it should if the client
specified a new client_port value and/or a new transport type?

> If this is not the case some additional information like the RTPInfo would
> be needed so that both the client and server know when the switch to new
> transport parameters occurs for this stream.

Perhaps, depending on the usage.  A new destination or a switch between TCP
and UDP would be pretty obvious.

> Does the client need to determine exactly when it has received all the
> packets on the old port and whether it can quit using the old port? If the
> client stops using the old ports too soon, it might lose packets.
> (Assuming as you had mentioned earlier that the client opens the new ports
> ahead of time, so there is no loss of packets at the new ports.) If there
> are no strong requirements from the client-side, then it is probably ok to
> let the server continue to use the same timescale and send packets to the

This is a really sticky issue and may be best left to the implementation.

The client can probably close its old ports when it begins receiving data on
the new ports.  This is not a foolproof technique, because the last packet
on the old port may be delayed longer than the first packet on the new port,
but it may be good enough.  There is also the possibility that the last
packet on the old port gets lost -- how long should the client wait for it
before giving up?

-- 
The nice thing about standards is that there are so many of them to choose
from.
        -- Andrew Tanenbaum

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 12 Sep 2003 09:32:31 +0200

Hi Geetha,

See inline

> Yes it would help to mention the cases where a PLAY request is valid, and causes any a

PLAY is used to start delivery of media. To my knowledge there are no 
other usage now that we removed Queued play and the keep alive based on 
play.

My question maybe not stated in the best way are: Do you see need to use
PLAY in other states than Ready? If yes, why.

If No, we will simply put in a sentence saying that PLAY shall only be 
used in READY state. There will also be need to put in some text about 
depreciated functionality and how to respond correctly in regards to that.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 12 Sep 2003 09:48:58 +0200

Hi,

Please read the other mail with subject "Re: [MMUSIC] RTSP: SETUP with 
new url in Play state" first. I will not answer question related to that 
mail in this.

> If it is the former, then we are overloading the semantics of SETUP, somewhat.

I was only talking about the changing transport parameter, see other 
mail about the other usage.

> Can the transport change from UDP to TCP (tunneled)  or vice versa?
Yes, all parameters could be changed. However some changes will not be 
possible to maintain synchronization over. Parameters that are in 
advisable to change are: media protocol, profile, usage type "PLAY" and 
"RECORD"

The following use cases has been identified for changing transport 
parameters.

- application layer mobility: Will require change of destination address 
and possibly also port. However the other parameters should be kept.

- Switch between TCP tunnelling and UDP delivery. Will change underlying 
protocol and setup or remove ports on both sides.

Any more use case that has been clear applicability? These use cases 
should be documented.

> situations where this changing a specific transport parameter is expected to solve issues.

I think one can start with considering what mechanism one desires or 
even like to have normative language regarding support. Then one can 
allow any parameter outside of that to be changed, however the server 
MAY only choose to support this.

> new client-side transport, starting after the reception of the SETUP request.

I don't think that providing Range or RTP-Info will improve the 
situation at all. The server will switch delivery up on accepting the 
parameter change. From the point it currently where it will delivery all 
data on the new transport. This can never be done in a way that allows 
the client to know when the last packet on the first transport is 
delivered when it is unreliable, and data on the new transport can 
arrive any time from that point the client sent the request.

This means that a client must enable reception on the new transport 
before sending the request. Upon reception of the 200 ok for the change 
of transport it should wait sufficiently for any straggling packets to 
clear the network. How long time this is depends on connections and use 
cases, therefore nothing specific can be said and will be an 
implementation matter.

My question remain, does anyone see a use cases where it would be 
required to include range and RTP-info to maintain synchronization.

Cheers

Magnus Westerlund

---

From: Aaron Colwell <[email-masked]>
Date: Fri, 12 Sep 2003 09:47:23 -0700 (PDT)

comment inline

> required to include range and RTP-info to maintain synchronization.

I think RTP-Info will be needed if the transport changes and the
new transport uses a different timestamp offset than the original 
transport. In this case you would need an RTP-Info with an rtptime field. 
You may also want to include a seq field so the client knows the
sequence number of the first packet with the  new offset. 

I also have a question about the RTP-Info fields in a SETUP response. Will 
the rtptime value map to the range header that was in the PLAY request or 
response, just like the RTP-Info in the PLAY response? Doing that makes 
the most sense to me and simplifies the implementation.

Aaron

---

From: Geetha Srikantan <[email-masked]>
Date: Fri, 12 Sep 2003 10:02:18 -0700

hi Tom,

Comments inline..

> change, including selecting a new transport type.

I see..

> would be desirable to change?

This needs clarification too.

> specified a new client_port value and/or a new transport type?

Good points.
So, it's possible for the client's transport parameter change request to cause a complete
change of
transport parameters for the stream.
It would be great to have all of these scenarios captured in the RTSP draft.

> and UDP would be pretty obvious.

Right.. however there is a short duration between when the client sent the
SETUP and the server responded to this request, there would be packets on the wire to the
old transport. Is it safe to assume that the client received it at the old IP, for example?
Will the client receive packets for the old and new IP when the cutover happens?

> packet on the old port gets lost -- how long should the client wait for it

I guess the client can always PAUSE and PLAY from a previous point if it's missing lots
of packets.

geetha

>   ------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature

---

From: Geetha Srikantan <[email-masked]>
Date: Fri, 12 Sep 2003 10:04:01 -0700

hi Magnus,

inline..

> PLAY in other states than Ready? If yes, why.

No, I certainly do not see a use for PLAY in other states.

> depreciated functionality and how to respond correctly in regards to that.

That sounds fine.

thanks
geetha

---

From: Geetha Srikantan <[email-masked]>
Date: Fri, 12 Sep 2003 10:14:57 -0700

hi Magnus,

Inline...

> advisable to change are: media protocol, profile, usage type "PLAY" and

It would be great to have a full enumeration of transport parameters and whether they can be
changed in the spec. This would help to avoid ambiguities and wrong interpretation.

> Any more use case that has been clear applicability? These use cases

Yes, it would be great to have these documented.

> MAY only choose to support this.

That seems reasonable.

> arrive any time from that point the client sent the request.

I agreee..with unreliable transport some unknowns like this can't be addressed.
As I mentioned in response to Tom's email, there could be a short interval of time between when

(a) the client has switched to a new IP, say, (b) sent SETUP to change transport, (c) server
receives the request.
This duration could be lengthened if there are intermediary nodes like proxies.
During this interval some of the packets on the wire are destined for the old IP, will they be
received at
the old IP by this client? If these packets are not received by the client, it could result in
a media glitch at the client. This is the problem I'm most concerned about. I'm not sure what
the best solution is..

geetha

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 15 Sep 2003 10:13:09 +0200

Hi,

comments inline:

> changed in the spec. This would help to avoid ambiguities and wrong interpretation.

This would need some consideration. I think one must consider what 
changes that have a given effect, there are a few different levels in 
there. It is nothing I can concentrate on currently. Please give it a 
shoot yourself.

> a media glitch at the client. This is the problem I'm most concerned about. I'm not sure what

This will always be a potential problem depending on how things happen. 
This is something the server can't do anything about. It is the client 
that will have to implement the detection and countermeasures as I see 
it. However the client is not without tools to correct such a situation.

1. The client when changing the setup parameters and not being able to 
receive media on the old IP from the point of moving form the old 
address to the new one, can use PAUSE and PLAY to go back to the last 
received point. This will probably result in a rebuffering or interrupt 
due to the delay to make the changes.

2. Use RTP retransmission to request the missing packets. Depending on 
the available capacity and amount of buffered media it might make it in 
time, or the client can perform a rebuffering action.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 15 Sep 2003 10:22:26 +0200

Hi Aaron,

> sequence number of the first packet with the  new offset. 

Yes, I agree that if one allows the TS to change, however is that 
necessary to allow. Unless one switches media protocol I don't see a 
reason of changing the timeline when one changes lower layer transport 
protocol or simply moves the delivery address. So are there any need for 
this?

I guess getting the sequence number will only help to determine when the 
last packet has arrived on the previous transport. However this will 
also be clear when the first packet on the new transport arrives.

I think that we can specify that Range and RTP-Info shall be included, 
however from my point of view that would simply be for completeness and 
future safety. I don't see that there are any real need for this as long 
as we require the server to keep the timeline over transport changes.

> the most sense to me and simplifies the implementation.

I would say that it shall map to the Range header in the SETUP response 
the same way it is for PLAY. However lets see if it is needed at all.

Cheers

Magnus Westerlund

---

From: Geetha Srikantan <[email-masked]>
Date: Fri, 19 Sep 2003 10:04:55 -0700

hi Magnus,

Comments inline..

> there. It is nothing I can concentrate on currently. Please give it a

Sure, I'll write up a note on this, summarizing all the discussion so far and also try to account
for
implications allowing changes to transport parameters. This might take a couple of weeks to get
done.

> time, or the client can perform a rebuffering action.

Certainly, these are some of the alternatives available to the client.
I'm wondering if there are other solutions to the problem, which will
involve fewer handshakes between client and server and which would make
the switch to new transport parameters more seamless.

geetha

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Sep 2003 11:12:31 +0200

Hi Geetha,

> implications allowing changes to transport parameters. This might take a couple of weeks to get

Great!

> the switch to new transport parameters more seamless.

It might exist, however I think that any such optimization will result 
in non interoperable solution. Therefore any such work would if deemed 
important need to be done as an extension. Also one should also consider 
how well mobile IP will work. In many cases this is probably a more 
desirable solution.

Cheers

Magnus Westerlund