Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-19.txt

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Rémi Denis-Courmont skrev:
> Le lundi 3 novembre 2008 20:30:01 Internet-Drafts at ietf.org, vous avez écrit :
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-19.txt
> 
> | 2.2.  RTSP's Relationship to HTTP
> | (...)
> |    *  Both an RTSP server and client can issue requests.
> 
> I am not questioning the need for this. But it might be worth to mention 
> somewhere that RTSP agents MUST be ready to handle an incoming requests even 
> when they are "waiting" for a response to one of their own requests. Without 
> this, we might get into a race condition failure scenario.
> 
> Also, RTSP agents MUST be ready to dequeue incoming (chunks of) requests 
> whenever they are in the middle of sending a request in the other direction. 
> Otherwise, they could get into a complete deadlock if a full request is 
> bigger than the TCP receive buffer.


I think this text is belonging in section 10 on connections. Proposed
text for Section 10.2 after the paragraph about Servers sending requests.

"The client and server sending requests can be asynchronous events. To
avoid issues both client and server MUST be able to send and receive
requests simultaneously."


> 
> | 13.4.1.  General Usage
> | (...) Range: npt=10-15, npt=20-25, npt=30-
> 
> I never really understood the need for multiple ranges. It's impossible to 
> support this with a user-grade interface. And for advanced uses, I don't see 
> the advantage over using multiple PLAY requests (I do see the big 
> inconvenience that it's a burden for server vendors to implement, and in fact 
> our RTSP server never supported this and will continue to ignore such 
> requests).

I will split this into its own thread.


> 
> | 16.19.  CSeq
> 
> I wonder why we have it at all. I assume I must be missing something. It made 
> sense for rtspu, but now? It is quite trivial to implement for clients and 
> servers, but not for proxies.

As section 10 says:

   Certain RTSP headers, such as the CSeq header (Section 16.19), which
   may appear to be relevant only to connectionless transport scenarios
   are still retained and must be implemented according to the
   specification.  In the case of CSeq, it is quite useful for matching
   responses to requests if the requests are pipelined (see Section 12).
   It is also useful in proxies for keeping track of the different
   requests when aggregating several client requests on a single TCP
   connection.


> 
> | D.1.6  Range of Presentation
> |  (...) In case of
> |  different length the range attribute MUST be given at media level
> |  for all media, and SHOULD NOT be given at session level.
> 
> This will for sure cause interoperability problems if it's ever used. The 
> basic video player for A/V streams won't know what to cope with that.

So what is your suggestion?

I have seen streams that hasn't have had audio all the way and that
ending slightly before the video. I think you need to handle those cases
in a graceful way. We already clarified that if you have this case in an
aggregated session you need to support requests with range values for
any point where there exist media.

> 
> | D.1.8.  Connection Information
> | (...) for type "IP6", this value SHALL be "0:0:0:0:0:0:0:0", i.e. the
> | unspecified address according to RFC 4291 
> 
> The canonical notation for the unspecified IPv6 address is "::". Then again, 
> it might be better to not put an explicit quoted value. The value matters, 
> not its notation.

Yes, that might be, but how many will be completely clear on this. I can
add a clarification that this is equivalent to "::".

> 
> | Appendix J.  Acknowledgements
> | (...) Mela Martti
> 
> Hist name is Martti Mela.
> 

Fixed


Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic