Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #19 - 12 msgs

From: [email-masked]
Date: Tue, 29 Jan 2002 18:11: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-477420 ] Missing definition of 1\# ([email-masked])
   2. [ rtspspec-Bugs-477407 ] Transport BNF, ; and unclearities ([email-masked])
   3. [ rtspspec-Bugs-477416 ] BNF error section 3.6 NPT ([email-masked])
   4. [ rtspspec-Bugs-496932 ] Require: option-tag BNF allows comma ([email-masked])
   5. [ rtspspec-Bugs-449074 ] RTP Seqnum offset in Pause Play response ([email-masked])
   6. [ rtspspec-Bugs-449074 ] RTP Seqnum offset in Pause Play response ([email-masked])
   7. [ rtspspec-Bugs-500868 ] Require: option-tag values unclear ([email-masked])
   8. [ rtspspec-Bugs-461083 ] Body w/o Content-Length clarification ([email-masked])
   9. [ rtspspec-Bugs-477407 ] Transport BNF, ; and unclearities ([email-masked])
  10. [ rtspspec-Bugs-477413 ] Transport BNF: mode ([email-masked])
  11. [ rtspspec-Bugs-477413 ] Transport BNF: mode ([email-masked])
  12. [ rtspspec-Bugs-477416 ] BNF error section 3.6 NPT ([email-masked])

--__--__--

Message: 1
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 16:40:20 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477420 ] Missing definition of 1\#

Bugs item #477420, was opened at 2001-11-01 23:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477420&group_id=23194

Category: None
Group: Fix for DS - Typo/Thinko
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Missing definition of 1\#

Initial Comment:
What is the definition of 1\# in the BNF? I can't find it in either RFC 2068, 2234, 2326, or 2616.

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

>Comment By: Rob Lanphier (robla)
Date: 2002-01-28 16:40

Message:
Logged In: YES 
user_id=3796

This was a processing error due to the spec production method we used last time.  We probably won't use 
the same technique this time around.

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 19:57

Message:
Logged In: YES 
user_id=3796

Typo that needs to be fixed.  It's "1#", as defined in section 2 of RFC 2326 (comma separated list)

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

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

--__--__--

Message: 2
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 16:46:44 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477407 ] Transport BNF, ; and unclearities

Bugs item #477407, was opened at 2001-11-01 23:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477407&group_id=23194

Category: None
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transport BNF, ; and unclearities

Initial Comment:
Page 61, Transport BNF: Should not multicast/unicast be proceeded by a ";"? Is multiple entries of 
the same type allowed? Are there any requirement on having multicast/unicast first?

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-28 16:46

Message:
Logged In: YES 
user_id=437905

RESOLUTION:

BNF will require semicolon, no mandated ordering, and 
example will be added.

Question was raised if multiple entries of the same type 
should be allowed?  This question was referred to a new 
issue.

Question was raied if interleave parameters should require 
paramters?  This question was referred to a new issue.

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

Comment By: Henning Schulzrinne (hgschulz)
Date: 2002-01-09 09:59

Message:
Logged In: YES 
user_id=115926

BNF will be fixed to have semicolon. Ordering doesn't
matter. Say before header section that parameter order
doesn't matter. Also state that parameters can't be
replicated (;port=1;port=2) within the same header instance.

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 19:34

Message:
Logged In: YES 
user_id=3796

Agreed it needs fix.  We'll need to sort out the right BNF for this, in such a way that it doesn't break
backwards compatibility

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

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

--__--__--

Message: 3
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 16:49:34 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477416 ] BNF error section 3.6 NPT

Bugs item #477416, was opened at 2001-11-01 23:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477416&group_id=23194

Category: None
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: BNF error section 3.6 NPT

Initial Comment:
BNF definition:npt-range, sec 3.6 lacks "npt=" in the begining of the definition. Compare with 
smpte-range or utc-range. 

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-28 16:49

Message:
Logged In: YES 
user_id=437905

RESOLUTION:

Require npt=, but have backwards-compatibility note in 
specificaton.

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 19:53

Message:
Logged In: YES 
user_id=3796

Hmmm...do implementors predominantly implement from the BNF, or from the numerous examples?

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

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

--__--__--

Message: 4
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 17:11:57 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-496932 ] Require: option-tag BNF allows comma

Bugs item #496932, was opened at 2001-12-26 16:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=496932&group_id=23194

Category: General
Group: Fix for DS - Typo/Thinko
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Rob Lanphier (robla)
Assigned to: Rob Lanphier (robla)
Summary: Require: option-tag BNF allows comma

Initial Comment:
Emailed from Raj Rajan on 12/26
>         In rfc-2326 of RTSP in section 12.32, Require
=   "Require" ":"
> 1#option-tag
> Issue here is that option-tag should be seperated by
"," and as per
> option-tag defination it may contaion ",".
> option-tag   =   1*xchar
> xchar = unreserved | reserved | escape
> unreserved = alpha | digit | safe | extra
> extra = "!" | "*" | "$'$" | "(" | ")" | ","
>  So, if "," is present in option-tag, how to
differentiate which one is
> delimiter in require header.

---

Option-tag should be token (or whatever the SIP
definition is); this
needs to be fixed.

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

>Comment By: Rob Lanphier (robla)
Date: 2002-01-28 17:11

Message:
Logged In: YES 
user_id=3796

Aligned with SIP (which indeed uses a [mostly] identically defined "token").  The only difference is that RTSP 
defines the set of illegal characters as "tspecials", while SIP defines them as "separators".

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

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

--__--__--

Message: 5
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 17:48:04 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-449074 ] RTP Seqnum offset in Pause Play response

Bugs item #449074, was opened at 2001-08-08 03:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=449074&group_id=23194

Category: General
Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Rob Lanphier (robla)
Summary: RTP Seqnum offset in Pause Play response

Initial Comment:
While implementing RTSP and RTP, there is a concernt
that after Pause, if Play request selects same stream 
but another random seqnum offset, RTP receiver may 
incrrectly report packet losses.

It is desirable to add a statement in future RTSP spec 
to require that the Play response use previous seqnum 
+ 1 as seqnum offset if the Play is to resume a paused 
stream.

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

>Comment By: Rob Lanphier (robla)
Date: 2002-01-28 17:48

Message:
Logged In: YES 
user_id=3796

This is pretty clear from Appendix B of the current specification.

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-28 14:25

Message:
Logged In: YES 
user_id=437905

RESOLUTION: (Jan 9, 2002 telecon)
Sequence numbers increase per suggestion. Resolution is a 
clarification of RFC 1889 and not a new requirement.

A new issue was raised to clarify concerns 
regarding  "timestamp monotmnically increasing". (See 
appendix "B" of specification (RTP usage).

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

Comment By: Rob Lanphier (robla)
Date: 2002-01-24 13:25

Message:
Logged In: YES 
user_id=3796

Discussed on Jan 9 telecon: 
http://rtsp.org/2002/telecon/jan09.html

RESOLVED: sequence numbers increase per suggestion in 
report. This is a clarification of RFC 1889, not new 
requirement

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 08:00

Message:
Logged In: YES 
user_id=3796

We believe that we can only recommend this solution, but not require it.  We'll update the draft to reflect 
this.

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

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

--__--__--

Message: 6
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 17:48:51 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-449074 ] RTP Seqnum offset in Pause Play response

Bugs item #449074, was opened at 2001-08-08 03:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=449074&group_id=23194

Category: General
Group: Fix - Discussed/Resolved
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Rob Lanphier (robla)
Summary: RTP Seqnum offset in Pause Play response

Initial Comment:
While implementing RTSP and RTP, there is a concernt
that after Pause, if Play request selects same stream 
but another random seqnum offset, RTP receiver may 
incrrectly report packet losses.

It is desirable to add a statement in future RTSP spec 
to require that the Play response use previous seqnum 
+ 1 as seqnum offset if the Play is to resume a paused 
stream.

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

Comment By: Rob Lanphier (robla)
Date: 2002-01-28 17:48

Message:
Logged In: YES 
user_id=3796

This is pretty clear from Appendix B of the current specification.

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-28 14:25

Message:
Logged In: YES 
user_id=437905

RESOLUTION: (Jan 9, 2002 telecon)
Sequence numbers increase per suggestion. Resolution is a 
clarification of RFC 1889 and not a new requirement.

A new issue was raised to clarify concerns 
regarding  "timestamp monotmnically increasing". (See 
appendix "B" of specification (RTP usage).

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

Comment By: Rob Lanphier (robla)
Date: 2002-01-24 13:25

Message:
Logged In: YES 
user_id=3796

Discussed on Jan 9 telecon: 
http://rtsp.org/2002/telecon/jan09.html

RESOLVED: sequence numbers increase per suggestion in 
report. This is a clarification of RFC 1889, not new 
requirement

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 08:00

Message:
Logged In: YES 
user_id=3796

We believe that we can only recommend this solution, but not require it.  We'll update the draft to reflect 
this.

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

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

--__--__--

Message: 7
To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jan 2002 19:26:09 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-500868 ] Require: option-tag values unclear

Bugs item #500868, was opened at 2002-01-08 08:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=500868&group_id=23194

Category: None
>Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Sean Sheedy (seansh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Require: option-tag values unclear

Initial Comment:
The proper option-tag values to use in the Require:
header when checking for optional features are not
always clear.  Some are more easily guessed then
others.

For example, to ask whether a server supports the
Scale: header, I would guess that the proper option-tag
would be "scale".  However, how does a client ask
whether the server supports the smpte time format in
the Range: header?

The document should include a table of optional
features and their corresponding option-tag values.

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

>Comment By: Rob Lanphier (robla)
Date: 2002-01-28 19:26

Message:
Logged In: YES 
user_id=3796

This should probably be a separately defined document.  The Require header was intended as a way of 
querying for features outside of the scope of RTSP, rather than for features in RTSP.

It is too late to require that existing implementations support new feature tags, but I agree it would be 
useful thing to have around.  A candidate list may fall out of the list of features in RTSP.  Sean, would you 
mind taking a first crack at creating the list of features tags you'd like to see?

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

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

--__--__--

Message: 8
To: [email-masked]
From: [email-masked]
Date: Tue, 29 Jan 2002 17:56:38 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-461083 ] Body w/o Content-Length clarification

Bugs item #461083, was opened at 2001-09-12 18:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=461083&group_id=23194

Category: General
>Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Lango (jasonlango)
Assigned to: Rob Lanphier (robla)
Summary: Body w/o Content-Length clarification

Initial Comment:
RFC 2326 says: 

4.4 Message Length

   When a message body is included with a message, the
length of that body is determined by one of the
following (in order of precedence):
 
   1.     Any response message which MUST NOT include a
message body
          (such as the 1xx, 204, and 304 responses) is
always terminated
          by the first empty line after the header
fields, regardless of
          the entity-header fields present in the
message. (Note: An
          empty line consists of only CRLF.)

   2.     If a Content-Length header field (section
12.14) is present,
          its value in bytes represents the length of
the message-body.
          If this header field is not present, a value
of zero is
          assumed.
 
   3.     By the server closing the connection.
(Closing the connection
          cannot be used to indicate the end of a
request body, since
          that would leave no possibility for the
server to send back a
          response.)
 
.. so it is saying that closing the connection is Ok to
indicate the length.

.. but then in section 12.14, it also says that the
Content-Length header MUST be sent.

The two sections should probably be made consistent.

Currently a popular RTSP server implementation (QTSS)
sends
"Connection: Close" followed by a message body for
certain
RTSP error status responses.

It might be worth requiring 'Connection: Close' in item
3 of
section 4.4 to reduce the ambiguity of whether or not a
compatible implementation may expect a response to
contain
a message body.

Alternatively it might be worth -not- saying that
message length
may be determined by the server closing the connection.

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-28 14:28

Message:
Logged In: YES 
user_id=437905

RESOLUTION: (Jan 9, 2002 teleconference)

Eliminate implicit body-length via connection: close.  
COntactt David SInger on this issues and encourage f 
future participation.  Verify resolution is consistent 
with SIP specificaiton.

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 09:32

Message:
Logged In: YES 
user_id=3796

This is a potentially gnarly issue.  We agree that this is a problem that needs fixing.

We propose that we eliminate the option of implied Content-Length if possible (need 
to check with implementors on this....Darwin server in particular).  If we can't do 
that, require Connection: close, and change header definition.

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

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

--__--__--

Message: 9
To: [email-masked]
From: [email-masked]
Date: Tue, 29 Jan 2002 18:03:17 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477407 ] Transport BNF, ; and unclearities

Bugs item #477407, was opened at 2001-11-01 23:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477407&group_id=23194

Category: None
>Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transport BNF, ; and unclearities

Initial Comment:
Page 61, Transport BNF: Should not multicast/unicast be proceeded by a ";"? Is multiple entries of 
the same type allowed? Are there any requirement on having multicast/unicast first?

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-28 16:46

Message:
Logged In: YES 
user_id=437905

RESOLUTION:

BNF will require semicolon, no mandated ordering, and 
example will be added.

Question was raised if multiple entries of the same type 
should be allowed?  This question was referred to a new 
issue.

Question was raied if interleave parameters should require 
paramters?  This question was referred to a new issue.

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

Comment By: Henning Schulzrinne (hgschulz)
Date: 2002-01-09 09:59

Message:
Logged In: YES 
user_id=115926

BNF will be fixed to have semicolon. Ordering doesn't
matter. Say before header section that parameter order
doesn't matter. Also state that parameters can't be
replicated (;port=1;port=2) within the same header instance.

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 19:34

Message:
Logged In: YES 
user_id=3796

Agreed it needs fix.  We'll need to sort out the right BNF for this, in such a way that it doesn't break
backwards compatibility

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

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

--__--__--

Message: 10
To: [email-masked]
From: [email-masked]
Date: Tue, 29 Jan 2002 18:06:07 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477413 ] Transport BNF: mode

Bugs item #477413, was opened at 2001-11-01 23:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477413&group_id=23194

Category: None
Group: Fix for DS - Need WG Input
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transport BNF: mode

Initial Comment:
Transport ABNF, mode line, The "=" lacks " around it. There are also unclearities if you could 
actually have mode=""PLAY","RECORD"" ?

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

>Comment By: Rob Lanphier (robla)
Date: 2002-01-29 18:06

Message:
Logged In: YES 
user_id=3796

RESOLVED (Jan 9 telecon: http://rtsp.org/2002/telecon/jan09.html

Rework BNF, fixing multiple problems not limited to allow outside
quotes, but not inside quotes. Quotes are optional 

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 19:45

Message:
Logged In: YES 
user_id=3796

First issue is a thinko, and just needs to be fixed.  The BNF is pretty sloppy the way that it is, and needs to 
be fixed

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

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

--__--__--

Message: 11
To: [email-masked]
From: [email-masked]
Date: Tue, 29 Jan 2002 18:06:48 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477413 ] Transport BNF: mode

Bugs item #477413, was opened at 2001-11-01 23:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477413&group_id=23194

Category: None
>Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Transport BNF: mode

Initial Comment:
Transport ABNF, mode line, The "=" lacks " around it. There are also unclearities if you could 
actually have mode=""PLAY","RECORD"" ?

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

Comment By: Rob Lanphier (robla)
Date: 2002-01-29 18:06

Message:
Logged In: YES 
user_id=3796

RESOLVED (Jan 9 telecon: http://rtsp.org/2002/telecon/jan09.html

Rework BNF, fixing multiple problems not limited to allow outside
quotes, but not inside quotes. Quotes are optional 

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 19:45

Message:
Logged In: YES 
user_id=3796

First issue is a thinko, and just needs to be fixed.  The BNF is pretty sloppy the way that it is, and needs to 
be fixed

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

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

--__--__--

Message: 12
To: [email-masked]
From: [email-masked]
Date: Tue, 29 Jan 2002 18:08:02 -0800
Subject: [rtspspec-bugs] [ rtspspec-Bugs-477416 ] BNF error section 3.6 NPT

Bugs item #477416, was opened at 2001-11-01 23:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477416&group_id=23194

Category: None
>Group: Fix - Discussed/Resolved
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Westerlund (magwes)
Assigned to: Nobody/Anonymous (nobody)
Summary: BNF error section 3.6 NPT

Initial Comment:
BNF definition:npt-range, sec 3.6 lacks "npt=" in the begining of the definition. Compare with 
smpte-range or utc-range. 

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

Comment By: David W. Walker (davidwwalker)
Date: 2002-01-28 16:49

Message:
Logged In: YES 
user_id=437905

RESOLUTION:

Require npt=, but have backwards-compatibility note in 
specificaton.

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

Comment By: Rob Lanphier (robla)
Date: 2001-12-13 19:53

Message:
Logged In: YES 
user_id=3796

Hmmm...do implementors predominantly implement from the BNF, or from the numerous examples?

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

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

End of Rtspspec-bugs Digest

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