Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #120 - 7 msgs

From: [email-masked]
Date: Sun, 29 Feb 2004 13:54:05 -0800

This is an automatic digest of bugs submitted and changed on the RTSP bug tracker.  To see a list of bugs, visit:

http://sf.net/projects/rtspspec

When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest"

Today's Topics:

   1. [ rtspspec-Bugs-494526 ] The use of message-body in methods (SourceForge.net)
   2. [ rtspspec-Bugs-494526 ] The use of message-body in methods (SourceForge.net)
   3. [ rtspspec-Bugs-494526 ] The use of message-body in methods (SourceForge.net)
   4. [ rtspspec-Bugs-506684 ] Allow Rtp-Info header in more contexts (SourceForge.net)
   5. [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause (SourceForge.net)
   6. [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause (SourceForge.net)
   7. [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Sun, 29 Feb 2004 13:26:46 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-494526 ] The use of message-body in methods

Bugs item #494526, was opened at 2001-12-18 10:43
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494526&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
>Assigned to: Magnus Westerlund (magwes)
Summary: The use of message-body in methods

Initial Comment:
The current specification does only allow use of message-body in methods DESCRIBE and 
GET_PARAMETER according to text below.

Chapter 12 secodn paragraph:
   "                      ...   The last column lists the method for which
   this header field is meaningful; the designation "entity" refers to
   all methods that return a message body. Within this specification,
   DESCRIBE and GET_PARAMETER fall into this class."

This seems to be a typo as also SET_PARAMETER examples has message-body. Also a table 
clarifying which headers that are allowed to have message-body would be good. 

What is needed to be discussed in the WG is a possiblilty to allow message-body also for the 
SETUP method. Allowing this would make it possible to do media and encoding selection with RTSP. 
Today there exist no way for a server to express different alternatives in a SDP for a media, 
primarily regarding media encoding. A selection of media variants may perhaps already be possible 
through the use of different URLs.  

A walk-through example would look like this: Client does describe and receives a SDP. This SDP 
tells the client that the audio media is available AMR and can be packetized both with or without 
interleaving. Client selects the interleaving case and removes the payload type without interleaving 
 from the SDP. This modified SDP is then sent in the SETUP request to the server. The server looks 
at the received SDP and uses the media information concerning the URL in the setup and use it to 
configure the payload packetizer. 

In the above example a number of alternatives could also be given in the SDP. The ones 
not supported by the client is removed. They can also be prioritized. Then the server is allowed to 
select and also to switch encoding during the session. This makes it for example possible to adapt 
to network conditions.  

This will of course require a more complete overview what the consequences will be of such a 
change. 

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:26

Message:
Logged In: YES 
user_id=302620

The bugs part has been resolved. There is a table 8 that 
shows what methods that can have body and in what 
directions. Also the status codes 4xx and 5xx and a few more 
specifying this explicitly can have them. 

The request for a feature extension for offer answer has been 
logged seperatly in a feature reuqest: 513787

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 12:58

Message:
Logged In: YES 
user_id=302620

The method table in the beginning of the header chapter now
contains a column which tells how body can be used. Also all
error messages may include a body. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494526&group_id=23194

--__--__--

Message: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Sun, 29 Feb 2004 13:29:08 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-494526 ] The use of message-body in methods

Bugs item #494526, was opened at 2001-12-18 10:43
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494526&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: The use of message-body in methods

Initial Comment:
The current specification does only allow use of message-body in methods DESCRIBE and 
GET_PARAMETER according to text below.

Chapter 12 secodn paragraph:
   "                      ...   The last column lists the method for which
   this header field is meaningful; the designation "entity" refers to
   all methods that return a message body. Within this specification,
   DESCRIBE and GET_PARAMETER fall into this class."

This seems to be a typo as also SET_PARAMETER examples has message-body. Also a table 
clarifying which headers that are allowed to have message-body would be good. 

What is needed to be discussed in the WG is a possiblilty to allow message-body also for the 
SETUP method. Allowing this would make it possible to do media and encoding selection with RTSP. 
Today there exist no way for a server to express different alternatives in a SDP for a media, 
primarily regarding media encoding. A selection of media variants may perhaps already be possible 
through the use of different URLs.  

A walk-through example would look like this: Client does describe and receives a SDP. This SDP 
tells the client that the audio media is available AMR and can be packetized both with or without 
interleaving. Client selects the interleaving case and removes the payload type without interleaving 
 from the SDP. This modified SDP is then sent in the SETUP request to the server. The server looks 
at the received SDP and uses the media information concerning the URL in the setup and use it to 
configure the payload packetizer. 

In the above example a number of alternatives could also be given in the SDP. The ones 
not supported by the client is removed. They can also be prioritized. Then the server is allowed to 
select and also to switch encoding during the session. This makes it for example possible to adapt 
to network conditions.  

This will of course require a more complete overview what the consequences will be of such a 
change. 

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:29

Message:
Logged In: YES 
user_id=302620

The bugs part has been resolved. There is a table 8 that 
shows what methods that can have body and in what 
directions. Also the status codes 4xx and 5xx and a few more 
specifying this explicitly can have them. 

The request for a feature extension for offer answer has been 
logged seperatly in a feature reuqest: 513787

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:26

Message:
Logged In: YES 
user_id=302620

The bugs part has been resolved. There is a table 8 that 
shows what methods that can have body and in what 
directions. Also the status codes 4xx and 5xx and a few more 
specifying this explicitly can have them. 

The request for a feature extension for offer answer has been 
logged seperatly in a feature reuqest: 513787

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 12:58

Message:
Logged In: YES 
user_id=302620

The method table in the beginning of the header chapter now
contains a column which tells how body can be used. Also all
error messages may include a body. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494526&group_id=23194

--__--__--

Message: 3
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Sun, 29 Feb 2004 13:30:47 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-494526 ] The use of message-body in methods

Bugs item #494526, was opened at 2001-12-18 10:43
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494526&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Magnus Westerlund (magwes)
Summary: The use of message-body in methods

Initial Comment:
The current specification does only allow use of message-body in methods DESCRIBE and 
GET_PARAMETER according to text below.

Chapter 12 secodn paragraph:
   "                      ...   The last column lists the method for which
   this header field is meaningful; the designation "entity" refers to
   all methods that return a message body. Within this specification,
   DESCRIBE and GET_PARAMETER fall into this class."

This seems to be a typo as also SET_PARAMETER examples has message-body. Also a table 
clarifying which headers that are allowed to have message-body would be good. 

What is needed to be discussed in the WG is a possiblilty to allow message-body also for the 
SETUP method. Allowing this would make it possible to do media and encoding selection with RTSP. 
Today there exist no way for a server to express different alternatives in a SDP for a media, 
primarily regarding media encoding. A selection of media variants may perhaps already be possible 
through the use of different URLs.  

A walk-through example would look like this: Client does describe and receives a SDP. This SDP 
tells the client that the audio media is available AMR and can be packetized both with or without 
interleaving. Client selects the interleaving case and removes the payload type without interleaving 
 from the SDP. This modified SDP is then sent in the SETUP request to the server. The server looks 
at the received SDP and uses the media information concerning the URL in the setup and use it to 
configure the payload packetizer. 

In the above example a number of alternatives could also be given in the SDP. The ones 
not supported by the client is removed. They can also be prioritized. Then the server is allowed to 
select and also to switch encoding during the session. This makes it for example possible to adapt 
to network conditions.  

This will of course require a more complete overview what the consequences will be of such a 
change. 

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:30

Message:
Logged In: YES 
user_id=302620

The bugs part has been resolved. There is a table 8 that 
shows what methods that can have body and in what 
directions. Also the status codes 4xx and 5xx and a few more 
specifying this explicitly can have them. 

The request for a feature extension for offer answer has been 
logged seperatly in a feature reuqest: 513787

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:29

Message:
Logged In: YES 
user_id=302620

The bugs part has been resolved. There is a table 8 that 
shows what methods that can have body and in what 
directions. Also the status codes 4xx and 5xx and a few more 
specifying this explicitly can have them. 

The request for a feature extension for offer answer has been 
logged seperatly in a feature reuqest: 513787

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:26

Message:
Logged In: YES 
user_id=302620

The bugs part has been resolved. There is a table 8 that 
shows what methods that can have body and in what 
directions. Also the status codes 4xx and 5xx and a few more 
specifying this explicitly can have them. 

The request for a feature extension for offer answer has been 
logged seperatly in a feature reuqest: 513787

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 12:58

Message:
Logged In: YES 
user_id=302620

The method table in the beginning of the header chapter now
contains a column which tells how body can be used. Also all
error messages may include a body. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494526&group_id=23194

--__--__--

Message: 4
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Sun, 29 Feb 2004 13:35:28 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-506684 ] Allow Rtp-Info header in more contexts

Bugs item #506684, was opened at 2002-01-21 23:46
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=506684&group_id=23194

Category: None
>Group: Resolved - Need write up
Status: Open
Resolution: None
Priority: 5
Submitted By: Anders Klemets (klemets)
Assigned to: Magnus Westerlund (magwes)
Summary: Allow Rtp-Info header in more contexts

Initial Comment:
Currently, the RFC states that the Rtp-Info header is 
required in the PLAY response.  But it is not clear 
whether or not the Rtp-Info is allowed in other 
contexts.

I think of three other cases where it might be useful:

1. In the RECORD request. If a client is sending data 
to the server, the client SHOULD send the Rtp-Info 
header to the server, so that the server can know the 
initial RTP sequence number and RTP timestamp.

2. In the SETUP response. If the server is already 
playing, and the client sends a SETUP command to 
select a stream that previously was not selected, I 
believe the server will start sending data for this 
stream immediately.  

(Check the RFC, I am not sure it clearly states 
whether the newly selected stream will be streamed 
immediately or not.)

In this case, it would be useful for the client to be 
able to recieve an Rtp-Info header as a part of the 
SETUP response.  But this has to be seen as an 
optional optimization -- the client can always send a 
second PLAY command, and the Rtp-Info header will then 
be available in the PLAY response.

3. In the ANNOUNCE command.  If the server is already 
playing, and something related to the SDP description 
suddenly changes, the server can send a new SDP to the 
client using the ANNOUNCE command.  It might be 
necessary to include a new Rtp-Info header in this 
case.

A similar situation happens when the server is 
reconding something, and the client sends an ANNOUNCE 
command to the server.

Again, this is probably just an optional optimization, 
because the client can always send a new PLAY command 
and obtain the Rtp-Info header again.

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:35

Message:
Logged In: YES 
user_id=302620

The header tables are missing RTP-Info. Needs to be added.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-03 14:05

Message:
Logged In: YES 
user_id=302620

The usage of RTP-Info is now furhter clarified in relation
to PLAY and SETUP. 

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-25 13:44

Message:
Logged In: YES 
user_id=302620

As Record and Announce has been removed from the
specification these questions are not longer relevant to the
core specification. However any future definition needs to
consider them.

RTP-Info for SETUP is currently used in two cases:
1. When in play state adding a stream to the session
2. When in play state changing the transport parameters

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 17:35

Message:
Logged In: YES 
user_id=302620

I agree that RTP-Info i SETUP while be necessary for the
optional functionality of SETUP and TEARDOWN while playing. 

For RECORD this should be part of the work in defining how
it should really work. 

For ANNOUNCE we need to further discuss this. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=506684&group_id=23194

--__--__--

Message: 5
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Sun, 29 Feb 2004 13:37:55 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause

Bugs item #507882, was opened at 2002-01-24 09:30
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194

Category: General
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Aravind Narasimhan (arvy_n)
Summary: RTP timestamps when playing after pause

Initial Comment:
What happends to the RTP timestamp when you issue a play after being paused for some time?

The following was my interpretation of the proposal for a solution. The
RTP timestamp is equal to display time. So it you do pause, wait five
seconds and then press play the timestamp will be 5 seconds later for
the first packet when resuming.

This behavior works fine when the play contains a range, for queued play
following after each other, but not for resuming play. The reason is the
delay between a user on the client side pressing pause and until the
client stops receiving data packets. If the client then does resume
play, i.e. play without range, the server will continue after the last
packet sent. In this case the client needs to show first the packet
arriving directly after pressing pause (which according to the used
model is past time), and then correctly synchronize the new packet which
has a significant offset in timestamp corresponding to the period of
pause the server has seen. The solution to this is to not use resume
play and instead say play from the point where user pressed pause.

On the other side I don&#039;t believe any other model will not have worse
problems.

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:37

Message:
Logged In: YES 
user_id=302620

There has been a major update of the text in the RTP 
integration appendix. This now has clear text and examples.

Needs review if satifsfactory.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-23 15:12

Message:
Logged In: YES 
user_id=302620

Aravind has agreed to write up the example and necessary
text. Transfering bug to him.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-22 10:48

Message:
Logged In: YES 
user_id=302620

A Clear example of RTP Timestamp and synchronization will be
added in appendix B - RTP transport.

The discussion in MMUSIC has made it clear that a continous
time model is needed to make RTCP work correctly. It has to
be accpeted that for on-demand media this will result in
slightly more code for the clients and servers. However all
pices to makes things work is already present. 

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-05-23 16:05

Message:
Logged In: YES 
user_id=302620

This has been further discussed in the MMUSIC mailing list. 

A important point is that RTP and RTCP to function as
intended in this environment must have a timestamp space
that increase continously with real time. 

A client handling the RTSP range header and RTP-Info can
always synchronize the data correctly independtly of which
case the server sent out. 

Using a continous RTP Timestamp space allows the same
timestamp model for both on-demand and live media.

The proposed resolution is to clrafiy in the RTP appendix of
the specification that a RTP timestamp space continous in
regards to real-time SHALL be used. Further write a warning
that this has been missunderstood and clients is RECOMMENDED
to handle both cases. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194

--__--__--

Message: 6
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Sun, 29 Feb 2004 13:40:28 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause

Bugs item #507882, was opened at 2002-01-24 09:30
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Aravind Narasimhan (arvy_n)
Summary: RTP timestamps when playing after pause

Initial Comment:
What happends to the RTP timestamp when you issue a play after being paused for some time?

The following was my interpretation of the proposal for a solution. The
RTP timestamp is equal to display time. So it you do pause, wait five
seconds and then press play the timestamp will be 5 seconds later for
the first packet when resuming.

This behavior works fine when the play contains a range, for queued play
following after each other, but not for resuming play. The reason is the
delay between a user on the client side pressing pause and until the
client stops receiving data packets. If the client then does resume
play, i.e. play without range, the server will continue after the last
packet sent. In this case the client needs to show first the packet
arriving directly after pressing pause (which according to the used
model is past time), and then correctly synchronize the new packet which
has a significant offset in timestamp corresponding to the period of
pause the server has seen. The solution to this is to not use resume
play and instead say play from the point where user pressed pause.

On the other side I don&#039;t believe any other model will not have worse
problems.

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:40

Message:
Logged In: YES 
user_id=302620

There has been a major update of the text in the RTP 
integration appendix. This now has clear text and examples.

Needs review if satifsfactory.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:37

Message:
Logged In: YES 
user_id=302620

There has been a major update of the text in the RTP 
integration appendix. This now has clear text and examples.

Needs review if satifsfactory.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-23 15:12

Message:
Logged In: YES 
user_id=302620

Aravind has agreed to write up the example and necessary
text. Transfering bug to him.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-22 10:48

Message:
Logged In: YES 
user_id=302620

A Clear example of RTP Timestamp and synchronization will be
added in appendix B - RTP transport.

The discussion in MMUSIC has made it clear that a continous
time model is needed to make RTCP work correctly. It has to
be accpeted that for on-demand media this will result in
slightly more code for the clients and servers. However all
pices to makes things work is already present. 

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-05-23 16:05

Message:
Logged In: YES 
user_id=302620

This has been further discussed in the MMUSIC mailing list. 

A important point is that RTP and RTCP to function as
intended in this environment must have a timestamp space
that increase continously with real time. 

A client handling the RTSP range header and RTP-Info can
always synchronize the data correctly independtly of which
case the server sent out. 

Using a continous RTP Timestamp space allows the same
timestamp model for both on-demand and live media.

The proposed resolution is to clrafiy in the RTP appendix of
the specification that a RTP timestamp space continous in
regards to real-time SHALL be used. Further write a warning
that this has been missunderstood and clients is RECOMMENDED
to handle both cases. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194

--__--__--

Message: 7
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Sun, 29 Feb 2004 13:41:59 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause

Bugs item #507882, was opened at 2002-01-24 09:30
Message generated for change (Comment added) made by magwes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194

Category: General
Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Aravind Narasimhan (arvy_n)
Summary: RTP timestamps when playing after pause

Initial Comment:
What happends to the RTP timestamp when you issue a play after being paused for some time?

The following was my interpretation of the proposal for a solution. The
RTP timestamp is equal to display time. So it you do pause, wait five
seconds and then press play the timestamp will be 5 seconds later for
the first packet when resuming.

This behavior works fine when the play contains a range, for queued play
following after each other, but not for resuming play. The reason is the
delay between a user on the client side pressing pause and until the
client stops receiving data packets. If the client then does resume
play, i.e. play without range, the server will continue after the last
packet sent. In this case the client needs to show first the packet
arriving directly after pressing pause (which according to the used
model is past time), and then correctly synchronize the new packet which
has a significant offset in timestamp corresponding to the period of
pause the server has seen. The solution to this is to not use resume
play and instead say play from the point where user pressed pause.

On the other side I don&#039;t believe any other model will not have worse
problems.

----------------------------------------------------------------------

>Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:41

Message:
Logged In: YES 
user_id=302620

There has been a major update of the text in the RTP 
integration appendix. This now has clear text and examples.

Needs review if satifsfactory.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:40

Message:
Logged In: YES 
user_id=302620

There has been a major update of the text in the RTP 
integration appendix. This now has clear text and examples.

Needs review if satifsfactory.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2004-02-29 22:37

Message:
Logged In: YES 
user_id=302620

There has been a major update of the text in the RTP 
integration appendix. This now has clear text and examples.

Needs review if satifsfactory.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-10-23 15:12

Message:
Logged In: YES 
user_id=302620

Aravind has agreed to write up the example and necessary
text. Transfering bug to him.

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-09-22 10:48

Message:
Logged In: YES 
user_id=302620

A Clear example of RTP Timestamp and synchronization will be
added in appendix B - RTP transport.

The discussion in MMUSIC has made it clear that a continous
time model is needed to make RTCP work correctly. It has to
be accpeted that for on-demand media this will result in
slightly more code for the clients and servers. However all
pices to makes things work is already present. 

----------------------------------------------------------------------

Comment By: Magnus Westerlund (magwes)
Date: 2003-05-23 16:05

Message:
Logged In: YES 
user_id=302620

This has been further discussed in the MMUSIC mailing list. 

A important point is that RTP and RTCP to function as
intended in this environment must have a timestamp space
that increase continously with real time. 

A client handling the RTSP range header and RTP-Info can
always synchronize the data correctly independtly of which
case the server sent out. 

Using a continous RTP Timestamp space allows the same
timestamp model for both on-demand and live media.

The proposed resolution is to clrafiy in the RTP appendix of
the specification that a RTP timestamp space continous in
regards to real-time SHALL be used. Further write a warning
that this has been missunderstood and clients is RECOMMENDED
to handle both cases. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194

End of Rtspspec-bugs Digest

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