Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #98 - 2 msgs

From: [email-masked]
Date: Thu, 25 Sep 2003 20:25:45 -0700

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-501599 ] Collect BNF at end, convert to 2234 (SourceForge.net)
   2. [ rtspspec-Bugs-506684 ] Allow Rtp-Info header in more contexts (SourceForge.net)

--__--__--

Message: 1
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 25 Sep 2003 04:38:19 -0700
Subject: [rtspspec-bugs] [ rtspspec-Bugs-501599 ] Collect BNF at end, convert to 2234

Bugs item #501599, was opened at 2002-01-10 03:43
Message generated for change (Comment added) made by magwes
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: 2003-09-25 13:38

Message:
Logged In: YES 
user_id=302620

A question is if the syntax chapter is the only place where

there should be syntax. This mean deleting it everywhere

else. Is this a good thing?

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

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: 2
To: [email-masked]
From: "SourceForge.net" <[email-masked]>
Date: Thu, 25 Sep 2003 04:44:05 -0700
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: Fixed in CVS/Need WG Approval
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: 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

End of Rtspspec-bugs Digest

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