Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #52 - 10 msgs

From: [email-masked]
Date: Wed, 30 Oct 2002 03:59:02 -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-477428 ] Priorites between aggregated & non cntrl ([email-masked])
   2. [ rtspspec-Bugs-477429 ] Create a BNF appendix ([email-masked])
   3. [ rtspspec-Bugs-477432 ] RTP info and queued plays ([email-masked])
   4. [ rtspspec-Bugs-499573 ] Incorrect grammar on Server header ([email-masked])
   5. [ rtspspec-Bugs-477429 ] Create a BNF appendix ([email-masked])
   6. [ rtspspec-Bugs-501599 ] Collect BNF at end, convert to 2234 ([email-masked])
   7. [ rtspspec-Bugs-493054 ] IPv6 issues ([email-masked])
   8. [ rtspspec-Bugs-493054 ] IPv6 issues ([email-masked])
   9. [ rtspspec-Bugs-493270 ] PAUSE/Play on single media in aggregate ([email-masked])
  10. [ rtspspec-Bugs-494526 ] The use of message-body in methods ([email-masked])

--__--__--

Message: 1
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 01:59:12 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477428 ] Priorites between aggregated & non cntrl

Bugs item #477428, was opened at 2001-11-02 08:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477428&group_id=23194

Category: None
>Group: Fixed in CVS/Need WG Approval
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Priorites between aggregated & non cntrl

Initial Comment:
A single media stream is playing. Then an aggregated control which include this stream is issued a 
play. How should this be interpreted? I use that it is queue and waits until all single streams under 
that aggregated control finish their play.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 10:59

Message:
Logged In: YES 
user_id=302620

Aggregated control has been resolved so that it is
determined by the sessions state. If more than one stream is
set up in a RTSP session only aggregated control is allowed.
This has been incorperated into the draft. Changes in PLAY,
PAUSE and state machine to explain this. 

Further work on RECORD needs to incorperate this also. A
note is added to that chapter.

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-02-13 02:45

Message:
Logged In: YES 
user_id=437905

RESOLVED: Await resolution of queued play. Aggregate 
control issue needs larger discussion.

ACTION ITEM: Write up aggregate URL proposal.

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

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

--__--__--

Message: 2
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 02:00:37 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477429 ] Create a BNF appendix

Bugs item #477429, was opened at 2001-11-02 08:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477429&group_id=23194

Category: None
Group: Fix for DS - Large task
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Create a BNF appendix

Initial Comment:
A complete ABNF of the RTSP specification could be collected in a appendix. This would make it 
easier to find how things are defined when doing implementation of the specification.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 11:00

Message:
Logged In: YES 
user_id=302620

Work has started on expanding the already existing syntax
chapter to include all syntax elements of the protocol. 

More work required. 

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-14 05:03

Message:
Logged In: YES 
user_id=3796

I suppose we should do this

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

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

--__--__--

Message: 3
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 02:13:51 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477432 ] RTP info and queued plays

Bugs item #477432, was opened at 2001-11-02 09:02
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477432&group_id=23194

Category: None
Group: Fix for DS - Need WG Input
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: RTP info and queued plays

Initial Comment:
When queueing plays the server needs to respond with a RTP-info header directly, this header 
should contain sync information. This sync information can be difficult for the server to produce 
with any good quality. Therefore the introduction of a new message/method that can be used for 
sending sync information on the queued play when it starts. Maybe also a message for signaling 
end of stream could be good. 

These are both issues that has been discussed earlier without any resolution. We should resolve 
this during the draft update. 

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 11:13

Message:
Logged In: YES 
user_id=302620

By removing queued play this is solved. However this is
still a problem for timed play. See bug # 511233. 

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

Comment By: Anders Klemets (klemets)
Date: 2002-01-23 19:05

Message:
Logged In: YES 
user_id=290475

The server would have to send a command to the client to 
indicate when it starts executing the new PLAY command.  As 
Magnus suggests, this probably would require a new RTSP 
method.

Alternatively, we could just remove support for queued 
PLAYs from the RTSP spec.

See also the summary from the RTSP bakeoff:

-- Begin quote
From: [email-masked]
To: [email-masked]
Date: Tue 8/8/2000 5:39 PM
Subject: RTSP Bakeoff issues

...
3. Queued PLAY as described in the spec was not yet 
implemented by many of the participants in the bakeoff. 
While it seems like it could be a very useful feature, 
there were some serious complications in the current design 
that make it difficult to implement. In particular, it's 
currently very difficult to return a reasonable set of 
values in the "RTP-Info" header of the PLAY reply, as it 
would require knowing exactly what the sequence number and 
timestamp will be when the server is done playing all of 
the previously queued data, and this information may be 
difficult or impossible to compute without actually reading 
and parsing all of that data. It might be more reasonable 
to move this information from the PLAY reply to some other 
independent message sent from the server to the client 
right before a PLAY spurt starts at the server. For the 
first PLAY in any given session, this message would be sent 
immediately after the PLAY reply, but for queued segments 
it would be delayed until that segment was about to begin 
playing. There was also an independent request for 
a "stream done" indication when playback finished, and it 
seems like this same message could serve that purpose, 
providing the sequence number and timestamp just past the 
end of the packets which were transmitted when playback 
finishes.
-- End quote

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-14 05:11

Message:
Logged In: YES 
user_id=3796

Need to discuss

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

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

--__--__--

Message: 4
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 02:16:53 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-499573 ] Incorrect grammar on Server header

Bugs item #499573, was opened at 2002-01-04 21:54
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=499573&group_id=23194

Category: General
Group: Fix for DS - Typo/Thinko
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Rob Lanphier (robla)
Assigned to: Magnus Westerlund (magwes)
Summary: Incorrect grammar on Server header

Initial Comment:
Date: Thu, 03 Jan 2002 01:13:58 +0530
From: Rakesh Jain <[email-masked]>
To: "[email-masked]"
<[email-masked]>,
     "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: RTSP issue...
Parts/Attachments:
   1 Shown    15 lines  Text
   2   OK     19 lines  Text
----------------------------------------

Hi all,
        I have some doubts regarding User-Agent &
Server header fields
        ( in cotext of RTSP RFC ). Please clear the same.

        Grammer rule for User-Agent & Server is
                        1*( product | comment )
        According the grammer there is no delimiter
among them,
        So how to differentiate multiple product
fields, in these
headers?

Thanks & Regards
        Rakesh

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 11:16

Message:
Logged In: YES 
user_id=302620

The changes below is checked in. Closing this type problem.

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-09-27 14:40

Message:
Logged In: YES 
user_id=302620

product is a token or optionaly "token/version" and comment
is text between "(" and ")". These shall be separated by a
space according to the examples. But the BNF does not
clarify this. One could fix this by specifying them as 

(product | comment) 0*(SP (product | comment))

But we should be satisfied by a simple fix of the BNF and
still rely on the text in RFC 2616. 

Change is commited to CVS. 

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

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

--__--__--

Message: 5
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 02:21:22 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477429 ] Create a BNF appendix

Bugs item #477429, was opened at 2001-11-02 08:51
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=477429&group_id=23194

Category: None
Group: Fix for DS - Large task
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Create a BNF appendix

Initial Comment:
A complete ABNF of the RTSP specification could be collected in a appendix. This would make it 
easier to find how things are defined when doing implementation of the specification.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 11:21

Message:
Logged In: YES 
user_id=302620

Closing this in favor of bug 501599 that also contains the
meantion of converting syntax to RFC 2234.

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

Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 11:00

Message:
Logged In: YES 
user_id=302620

Work has started on expanding the already existing syntax
chapter to include all syntax elements of the protocol. 

More work required. 

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-14 05:03

Message:
Logged In: YES 
user_id=3796

I suppose we should do this

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

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

--__--__--

Message: 6
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 02:22:53 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-501599 ] Collect BNF at end, convert to 2234

Bugs item #501599, was opened at 2002-01-10 03:43
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=501599&group_id=23194

Category: General
>Group: Fix for DS - Large task
Status: Open
Resolution: None
Priority: 5
Submitted By: Henning Schulzrinne (hgschulz)
>Assigned to: Magnus Westerlund (magwes)
Summary: Collect BNF at end, convert to 2234

Initial Comment:
For the SIP spec revision, we collected all BNF in one
place. This makes the spec somewhat shorter and easier
to read. Also, we need to convert BNF to 2234 format to 
pass IESG.

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

>Comment By: Magnus Westerlund (magwes)
Date: 2002-10-30 11:22

Message:
Logged In: YES 
user_id=302620

This is being done, closing bug 477429 and use this instead
until work is completed. 

The BNF is mostly converted. Comments please if non changed
syntax is found. 

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

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

--__--__--

Message: 7
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 03:31:57 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-493054 ] IPv6 issues

Bugs item #493054, was opened at 2001-12-13 23:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=493054&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Rob Lanphier (robla)
Summary: IPv6 issues

Initial Comment:
Need a second audit of IPv6 stuff.

Here's an initial survey of IPv6 readiness by Philip J. Nesser II ([email-masked])
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv4survey-01.txt

Section 3.2 RTSP URL defines:

   The "rtsp" and "rtspu" schemes are used to refer to network resources
   via the RTSP protocol. This section defines the scheme-specific
   syntax and semantics for RTSP URLs.

   rtsp_URL  =   ( "rtsp:" | "rtspu:" )
                 "//" host [ ":" port ] [ abs_path ]
   host      =   <A legal Internet host domain name of IP address
                 (in dotted decimal form), as defined by Section 2.1
                 of RFC 1123 \cite{rfc1123}>
   port      =   *DIGIT

Althought later in that section the following text is added:

   The use of IP addresses in URLs SHOULD be avoided whenever possible
   (see RFC 1924 [19]).

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

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

Message:
Logged In: YES 
user_id=302620

The specification has been updated so that URL's can handle
IPv6 in them. A note of caution that this will cause
interoperability problems has also been added. 

Propose that a chapter is written on IPv4/IPv6
Interoperability to better explain the issues. Demand that
implementers of option-tag "play.basic" supports IPv6 so
that this can be checked before trying.

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

Comment By: Jonathan Sergent (sergent)
Date: 2002-01-15 18:27

Message:
Logged In: YES 
user_id=79184

We have implemented IPv6 in our RTSP server.  The above
issue--strings in URLs--is not particularly relevant to us
since we do not attempt to parse the host and port
information in our server (we just treat it as a string),
and we do not have an RTSP client.

The issue that is not mentioned above that is much more
significant is the Transport header's handling of
addresses.  The grammar does not allow IPv6 addresses.

We will deliver RTP over IPv6 if it can be negotiated
without passing addresses through the Transport header (i.e.
no multicast, and source and destination are the same as the
RTSP endpoints).  If we can decide on the format for this,
we will be able to implement it and try it out.

I think that some rules need to be set out w.r.t. the use of
mapped addresses and such in the header.  And should IPv6
potentially be negotiated as a different protocol in the
header?  (i.e. Transport:
RTP/AVP/UDP6;unicast;foo,RTP/AVP/UDP;unicast;bar to indicate
a preference for V6 over V4)

Also, it should probably be clarified that c=IN IP4 0.0.0.0
in SDP is just a flag value and does not indicate the
preference or the availability of V4, only that the
parameters will be negotiated at SETUP time.

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

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

--__--__--

Message: 8
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 03:50:00 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-493054 ] IPv6 issues

Bugs item #493054, was opened at 2001-12-13 23:49
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=493054&group_id=23194

Category: General
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Rob Lanphier (robla)
Summary: IPv6 issues

Initial Comment:
Need a second audit of IPv6 stuff.

Here's an initial survey of IPv6 readiness by Philip J. Nesser II ([email-masked])
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv4survey-01.txt

Section 3.2 RTSP URL defines:

   The "rtsp" and "rtspu" schemes are used to refer to network resources
   via the RTSP protocol. This section defines the scheme-specific
   syntax and semantics for RTSP URLs.

   rtsp_URL  =   ( "rtsp:" | "rtspu:" )
                 "//" host [ ":" port ] [ abs_path ]
   host      =   <A legal Internet host domain name of IP address
                 (in dotted decimal form), as defined by Section 2.1
                 of RFC 1123 \cite{rfc1123}>
   port      =   *DIGIT

Althought later in that section the following text is added:

   The use of IP addresses in URLs SHOULD be avoided whenever possible
   (see RFC 1924 [19]).

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

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

Message:
Logged In: YES 
user_id=302620

An IPv6 explanation chapter started in the connetion
chapter. May need more text. 

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

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

Message:
Logged In: YES 
user_id=302620

The specification has been updated so that URL's can handle
IPv6 in them. A note of caution that this will cause
interoperability problems has also been added. 

Propose that a chapter is written on IPv4/IPv6
Interoperability to better explain the issues. Demand that
implementers of option-tag "play.basic" supports IPv6 so
that this can be checked before trying.

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

Comment By: Jonathan Sergent (sergent)
Date: 2002-01-15 18:27

Message:
Logged In: YES 
user_id=79184

We have implemented IPv6 in our RTSP server.  The above
issue--strings in URLs--is not particularly relevant to us
since we do not attempt to parse the host and port
information in our server (we just treat it as a string),
and we do not have an RTSP client.

The issue that is not mentioned above that is much more
significant is the Transport header's handling of
addresses.  The grammar does not allow IPv6 addresses.

We will deliver RTP over IPv6 if it can be negotiated
without passing addresses through the Transport header (i.e.
no multicast, and source and destination are the same as the
RTSP endpoints).  If we can decide on the format for this,
we will be able to implement it and try it out.

I think that some rules need to be set out w.r.t. the use of
mapped addresses and such in the header.  And should IPv6
potentially be negotiated as a different protocol in the
header?  (i.e. Transport:
RTP/AVP/UDP6;unicast;foo,RTP/AVP/UDP;unicast;bar to indicate
a preference for V6 over V4)

Also, it should probably be clarified that c=IN IP4 0.0.0.0
in SDP is just a flag value and does not indicate the
preference or the availability of V4, only that the
parameters will be negotiated at SETUP time.

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

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

--__--__--

Message: 9
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 03:55:08 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-493270 ] PAUSE/Play on single media in aggregate

Bugs item #493270, was opened at 2001-12-14 13:13
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=377744&aid=493270&group_id=23194

Category: None
Group: Fix for DS - Need WG Input
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: PAUSE/Play on single media in aggregate

Initial Comment:
There is a aggregated session with two medias, video and audio. The client has made a PLAY on 
the aggregated control. 

At time A the client request PAUSE on the audio. At time B the client sends a PLAY on the audio 
stream. What behaviour should the client have?

The RFC says in section 10.6, first paragraph:
  "The PAUSE request causes the stream delivery to be interrupted
   (halted) temporarily. If the request URL names a stream, only
   playback and recording of that stream is halted. For example, for
   audio, this is equivalent to muting. If the request URL names a
   presentation or group of streams, delivery of all currently active
   streams within the presentation or group is halted. After resuming
   playback or recording, synchronization of the tracks MUST be
   maintained. Any server resources are kept, though servers MAY close
   the session and free resources after being paused for the duration
   specified with the timeout parameter of the Session header in the
   SETUP message."

The question is what type of synchronization should the server maintain?

1. Resynchronize: The audio with the video, i.e the audio starts playing at time B at the same 
   position the video are in. 
2. Keep delay: When starting to send media at time B it corresponds to directly after time A. 

Point 1, seems to be supported by the example made.

Point 2, correspondes to the behaviour seen on aggregated control or a single media. 

The interaction of aggregated and non-aggregated control create special cases and unclarities. 
This should probably be revied in a broader scope also considering different use cases. 

See also bug report #477428

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

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

Message:
Logged In: YES 
user_id=302620

The is resolved by not allowing single media control in an
aggregate control.  For muting see seperate extension proposal. 

The PAUSE and PLAY method description is updated and
explicitely says that aggregated control must be used for
aggregated sessions. 

Closing this issue.

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-17 21:35

Message:
Logged In: YES 
user_id=3796

Ugh...agreed, this is a mess.  Ideally, we should probably have a MUTE method with different semantics 
from PAUSE, and either deprecate or remove this usage.

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

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

--__--__--

Message: 10
To: [email-masked]
From: [email-masked]
Date: Wed, 30 Oct 2002 03:58:16 -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
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: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Rob Lanphier (robla)
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: 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

End of Rtspspec-bugs Digest

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