Subject: [MMUSIC] draft-rfc2326-06 minor comments

From: Geetha Srikantan <[email-masked]>
Date: Fri, 19 Mar 2004 10:06:27 -0800

Here are some minor - at least, I think they're minor :-)
- comments on draft-ietf-mmusic-rfc2326bis-06.txt.

Section 3.7, page 24: It would be helpful to provide a forward
reference to the feature tag discussion in section 19.

Section 6, page 26, last paragraph before 6.1:
Length of the message body is sent in the Content-Length header only
right? The last sentence says 'headers', which has me confused.

Section 6.1, page 26:
'Please note: The request...'
This line seems to contradict what was in bullet #3 of 1.6 on page 17.
Which is correct - this line here or 1.6?

Section 6.2, page 27:
Refers to table 6.2, it should be table 3.

Section 7.1.2, page 30:
Refers to table 7.1.2, it should be table 5.
Also tables 4 and 5 are not in order - 5 is before 4.

Section 11.3, page 43:
1st paragraph, 2nd sentence: it should be 'three' not 'two' different
cases, right?

Section 11.3, page 44:
1st paragraph: An example of the timeout parameter with session id
would be helpful.

Section 11.3, page 44:
SSRC: If the SSRC of the media stream changes mid-stream due to SSRC
collision in a multicast say, there is no way to signal it via RTSP.
Should we add a note about that? (This is the same as in RFC 2326.)

Section 11.4, page 47:
An example of live streaming would be very helpful.
BTW, the examples in section 11.5 are excellent.

Section 11.10, page 57:
1st paragraph, 2nd sentence:
PING does have the side effect of updating the session
liveness, even though it doesn't cause any state change.

Section 13.3.5, page 60:
Refers to section 12.23 it should be 14.23
Etags are mentioned - it would be helpful to provide a reference to
more details on Etags.

Section 13.5.1, page 63:
Status code 551 is not mentioned in table 4, perhaps a typo?

Section 14, page 63:
It would be good to have table 9 and 10 earlier in this section before
they are discussed.

Section 14.29, page 78:
1st paragraph: 10.08 is before 10.1, the text seems to indicate
otherwise..

Section 14.40, page 92:
An example with src_addr and dest_addr would be very helpful.
An example with non-contiguous RTP/RTCP ports would be helpful too.

Section 16.2 page 99 and section 16.3 page 101:
On page 99 the url in the PLAY request has a trailing '/'
although on page 101 the url in the PLAY request, there is no trailing
'/'. In both cases the SDP has 'a=control: *.
This seems to contradict the last paragraph in C.1.1.

Section B.1.2, page 127:
1st bullet, last line: Not sure what it means.

Section B.1.4, page 129:
1st paragraph, Last sentence:
There is a possibility of RTP timestamps in consecutive RTP packets
not being monotonic, according to the RTP spec. I can see that
sequence numbers should be monotonically increasing, however, can we
really mandate the same for the RTP timestamps?

thanks
geetha

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 23 Mar 2004 18:18:15 +0100

Hi Geetha,

Thanks for the comments. Comments inline.

> reference to the feature tag discussion in section 19.

I guess that you mean section 10 capability handling.

> right? The last sentence says 'headers', which has me confused.

Yes, I will change this to "Content-Length entity header"
> Which is correct - this line here or 1.6?

No, they are not really contradicting, slightly differently interpreted.
Section 1.6 says: "
           A new version of the protocol can be defined, allowing almost
           all aspects (except the position of the protocol version
           number) to change."

Section 6.1:
   "Please note: The request line's syntax can't be changed in future
    versions of RTSP, as this line indicates the version of the messages
    and need to be parsable also by older versions."

If one changes the syntax of the request line on does in fact change the 
position of the protocol version. The text in 6.1 is simply stricter of 
what in fact must be required by an updated version.

I could soften the language in section 6.1 to the following:
Please note: The request line's syntax can't be freely changed in
future versions of RTSP, as this line indicates the version of the
messages and need to be parsable also by older versions.

> Refers to table 6.2, it should be table 3.

Fixed, a bit of latex error.

> Also tables 4 and 5 are not in order - 5 is before 4.

Fixed.
> 1st paragraph, 2nd sentence: it should be 'three' not 'two' different

I was meaning two, but the rest of the sentence does not get the case 
across, so I use three instead.

> 1st paragraph: An example of the timeout parameter with session id

Now included.

> Should we add a note about that? (This is the same as in RFC 2326.)

I agree that there is no way to signal it. However this does not belong 
in this section. Instead it belongs to the appendix B deciding RTP usage.

New proposed text for that section is:
An SSRC collision with the SSRC that transmits media does also has
consequences, as it will force it to change its SSRC in accordance
with the RTP specification ~\cite{rfc3550}. This will result in a
loss of synchronization context, and require any receiver to wait
for RTCP sender reports for all media requiring synchronization
before being able to play out synchronized. Due to these reasons a
client joining a session should take care to not select the same
SSRC as the server. Any SSRC signalled in the \header{Transport}
header {\SHOULD} be avoided. Also a client detecting a collision
prior to sending any RTP or RTCP messages can also select a new
SSRC.

> BTW, the examples in section 11.5 are excellent.

Isn't section 16.4 enough? What aspects do you desire an example to 
cover. Could you please present the example you would like to be included?

> liveness, even though it doesn't cause any state change.

No, not in my version the first paragraph says:
   "This method is a bi-directional mechanism for server or client
    liveness checking. It has no side effects. The issuer of the request
    MUST include a session header with the session ID of the session that
    is being checked for liveness."

> Etags are mentioned - it would be helpful to provide a reference to

There is some problem with ETag. As Jae-Hwan Kim pointed out there is a 
missing header.

> Status code 551 is not mentioned in table 4, perhaps a typo?

Well it is in my table. However it might have been lost in the post 
processing.

> It would be good to have table 9 and 10 earlier in this section before

I am having problem controlling exactly where they are put. Maybe my 
lack of LaTeX knowledge. They should be after the explanation of the 
text. However now they float a bit to far.

> 1st paragraph: 10.08 is before 10.1, the text seems to indicate

   "Ranges are half-open intervals, including the first point, but
    excluding the second point. In other words, a range of A-B starts
    exactly at time A, but stops just before B. Only the start time of a
    media unit such as a video or audio frame is relevant. As an example,
    assume that video frames are generated every 40 ms. A range of
    10.0-10.1 would include a video frame starting at 10.0 or later time
    and would include a video frame starting at 10.08, even though it
    lasted beyond the interval. A range of 10.0-10.08, on the other hand,
    would exclude the frame at 10.08."

What is the problem with the section? I don't understand what you 
interpret as indicating that 10.08 is after 10.1?

> An example with non-contiguous RTP/RTCP ports would be helpful too.

See example 16.2. It doesn't have non-contiguous ports, but as all ports 
are given explicitly I don't think this is a problem.

> This seems to contradict the last paragraph in C.1.1.

A bug, fixed.

> 1st bullet, last line: Not sure what it means.
         o RTP/UDP packet from the server to the client SHALL be sent to
           the address specified in the "destination" parameter and first
           even port number given in client_port range. If there is only
           a single port number given that MUST be given.

I think the intent is to clarify that if no range is given, the RTP port 
must be explicitly given. For a range the first even number is used. 
Thus there is certain differences.

I propose to change the last sentence to:
If only a RTP
port is to be specified, then only that even port number {\SHALL}
be given, i.e. no range starting at a odd number {\SHALL} be used.

Better?

> really mandate the same for the RTP timestamps?

In respect to:
"Thus, both RTP sequence numbers and RTP timestamps MUST be     |
    continuous and monotonic across jumps of NPT."

This is not a general rule that always apply, it only is given for jumps 
in NPT. It could not possibly work correctly if the timestamp do not 
increase between a media packet belonging to another NPT than after the 
NPT jump. So even when jumping backwards in NPT one must increase the TS 
to make the client present the packet correctly after the previous range.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Geetha Srikantan <[email-masked]>
Date: Thu, 25 Mar 2004 11:09:19 -0800

hi Magnus,

Thanks for the response. I'll skip over the obvious typo
and editorial issues. Thanks for addressing them right away.
Comments inline for the rest of the items.

geetha

> I guess that you mean section 10 capability handling.

Actually I meant section 19, where feature tags are explained in some 
detail.
In addition, a reference to section 10 would be good too.

> If one changes the syntax of the request line on does in fact change 
> the position of the protocol version. The text in 6.1 is simply 
> stricter of what in fact must be required by an updated version.
>

Sounds good..

> I agree that there is no way to signal it. However this does not 
> belong in this section. Instead it belongs to the appendix B deciding 
> RTP usage.
>

This is fine with minor suggestions on wording:
1st sentence: ...does also has -> has
2nd sentence:  ...able to play out synchronized -> able to synchronize 
media play out

> cover. Could you please present the example you would like to be 

The example in 16.4 talks about multicast live streams. It would be 
helpful to have a unicast live example similar to the
one in 16.4. Either location for such an example, i.e. 11.4 or 16.4, 
would be fine.
I can provide the example in a separate message.

>    is being checked for liveness." 

I should clarify what I meant.
The text you quote above says there is no side effect of the PING 
method, however
in Section 11.3 on page 44 there is a discussion about liveness signs.
Here it says any RTSP method with a session id can be used to 'update' 
liveness
of a session - and presumably the timeout value of the session. This is a
side effect, is it not?
I agree that there is no state change - a session continues to remain in 
whatever
state it was, after the PING request is processed.

> interpret as indicating that 10.08 is after 10.1?

The 4th sentence: 'A range of 10.0-10.1 would include...., even though 
it lasted beyond the interval.'
                                                                         
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This was confusing..it might help to skip that phrase from the sentence? 

> See example 16.2. It doesn't have non-contiguous ports, but as all 
> ports are given explicitly I don't think this is a problem.

Yes I did see the example in 16.2 also.
Providing a forward reference to 16.2 in this section would help since 
two new parameters
'src_addr' and 'dest_addr' are being introduced in this draft. Some 
guidance on usage would
help.

> I think the intent is to clarify that if no range is given, the RTP 
> port must be explicitly given. For a range the first even number is 
> used. Thus there is certain differences.
>

Yes..thanks!

> This is not a general rule that always apply, it only is given for 
> jumps in NPT. It could not possibly work correctly if the timestamp do 
> not increase between a media packet belonging to another NPT than 
> after the NPT jump. So even when jumping backwards in NPT one must 
> increase the TS to make the client present the packet correctly after 
> the previous range.

I understand that this section only applies to cases where NPT jumps happen.
This is probably ok.

geetha

> This communication is confidential and intended solely for the 
> addressee(s). Any unauthorized review, use, disclosure or distribution 
> is prohibited. If you believe this message has been sent to you in 
> error, please notify the sender by replying to this transmission and 
> delete the message without disclosing it. Thank you.
>
> E-mail including attachments is susceptible to data corruption, 
> interruption, unauthorized amendment, tampering and viruses, and we 
> only send and receive e-mails on the basis that we are not liable for 
> any such corruption, interception, amendment, tampering or viruses or 
> any consequences thereof.
>