Subject: Re: RE: [MMUSIC] OPTIONS method in RTSP. Is it required or not in minimal client and server implementations?

From: [email-masked]
Date: Wed, 10 Jul 2002 17:23:07 +0300

Hi Magnus,

Thanhs for the quick answer. The reason why I asked this mainly is that, I don't actually know an RTSP client which didn't implement OPTIONS :-) (by implementing, I mean which can send OPTIONS request). So, wouldn't it be better to make it required also for the minimal implementation on the client side?

I also think that it is a quite clean solution to use OPTIONS with Session-Id to check/keep session aliveness. I remember the big discussions about this in this reflector, and I don't intend open them again :-). Just to keep in mind, in 3GPP Packet Switched Streaming Service definitions, RTCP and OPTIONS are the preferred methods for session aliveness checking, in the given preference order. (Ref: Section A.2.2.2.2 in document TS 26.234 v4.40 (Release 4) and v5.10 (Release 5)).

Best Regards,

Emre

> -----Original Message-----

> From: ext Magnus Westerlund [mailto:[email-masked]]

> Sent: 10. July 2002 17:10

> To: Aksu Emre (NMP/Tampere)

> Cc: [email-masked]

> Subject: Re: [MMUSIC] OPTIONS method in RTSP. Is it required or not in

> minimal client and server implementations?

> Hi Emre,

> Table 2 is actually rather unclear regarding the requirement 

> levels. It 

> does not specify which entity the requirements concern. If you would 

> read both the clients and the server minimal implementation 

> requirements 

> you would find a difference. The server is required to implement the 

> options method while the client is not.

> So follow annex D and be aware that the table is incomplete. It is 

> necessary to do something about it.

> I agree that options is very useful and all clients are 

> recommended to 

> implement it. I would say that options is the third or fourth 

> variant of 

> doing keep alive on my list after RTCP and PING and in hard 

> combat with 

> SET_PARAMETER. It main purpose however is capability discovery.

> Regards

> Magnus

> [email-masked] wrote:

> >Hello,

> >I have a question related to the RTSP OPTIONS method.

> >In the latest draft of RTSP RFC and also in the RFC 2326, in 

> Table 2, OPTIONS method requirement is listed as follows:

> > method direction object requirement

> >OPTIONS C->S, S->C P,S required 

> (S->C: optional)

> >In the Annex D.1 , minimal RTSP Client implementation, 

> OPTIONS method is not included to the list of methods which 

> MUST be implemented. 

> >So, My question is: How should this be interpreted? 

> According to Table 2, OPTIONS method looks like to be 

> mandated at least in the C->S direction. But this seems to 

> conflict with the minimal implementation. If Table.2 does not 

> apply to the minimal implementation, how should Table 2 be 

> interpreted? I would really appreciate if this could be clarified.

> >I would also like to point out the usefulness of OPTIONS, 

> especially for checking the 'session aliveness' according to 

> the latest draft...

> >BR

> >Emre

> >Emre Baris Aksu

> >Senior Design Engineer

> >Nokia Mobile Phones

> >Tampere / Finland

> >e-mail : [email-masked]

> >Mobile : +358 40 743 1972

> >Fax : +358 7180 70504

> >_______________________________________________

> >mmusic mailing list

> >[email-masked]

> >https://www1.ietf.org/mailman/listinfo/mmusic

> -- 

> Magnus Westerlund 

> Multimedia Technologies, Ericsson Research ERA/TVA/A

> ----------------------------------------------------------------------

> Ericsson AB | Phone +46 8 4048287

> Torshamsgatan 23 | Fax +46 8 7575550

> S-164 80 Stockholm, Sweden | mailto: [email-masked]

> _______________________________________________

> mmusic mailing list

> [email-masked]

> https://www1.ietf.org/mailman/listinfo/mmusic

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

---

From: Jeremy Worley <[email-masked]>
Date: Wed, 10 Jul 2002 08:41:43 -0700

Hello Emre,

At 05:23 PM 7/10/2002 +0300, [email-masked] wrote:
>Hi Magnus,
>
>Thanhs for the quick answer. The reason why I asked this mainly is that, I 
>don't actually know an RTSP client which didn't implement OPTIONS :-) (by 
>implementing, I mean which can send OPTIONS request). So, wouldn't it be 
>better to make it required also for the minimal implementation on the 
>client side?

I agree most clients implement sending of OPTIONS requests.  It also common 
for clients to not implement OPTIONS response.  The rationale for not 
requiring to send OPTIONS requests on the client is OK in my opinion 
because it is usually used to query features that a server implements.  If 
the client does not use any optional features, then it has no need to send 
an OPTIONS request, and so it would not need to implement sending of 
OPTIONS.  On the other hand, if the client uses optional RTSP features, 
then it must implement an OPTIONS request.

I agree with Magnus that Table 2 should be clarified to describe what must 
be implemented as both requests and responses by client and server.

>I also think that it is a quite clean solution to use OPTIONS with 
>Session-Id to check/keep session aliveness. I remember the big discussions 
>about this in this reflector, and I don't intend open them again :-). Just 
>to keep in mind, in 3GPP Packet Switched Streaming Service definitions, 
>RTCP and OPTIONS are the preferred methods for session aliveness checking, 
>in the given preference order. (Ref: Section A.2.2.2.2 in document TS 
>26.234 v4.40 (Release 4) and v5.10 (Release 5)).

When the new RTSP draft becomes an RFC, we may want to add PING to the list 
of methods for checking session aliveness in 26.234.  In such a scenario, I 
think PING might be preferred over OPTIONS.

Thanks,
         Jeremy

---

From: [email-masked]
Date: Wed, 10 Jul 2002 19:05:41 +0300

Hi Jeremy,
Please find my comments inlined:

> From: ext Jeremy Worley [mailto:[email-masked]]
> Sent: 10. July 2002 18:42
> To: Aksu Emre (NMP/Tampere); [email-masked]
> Subject: Re: RE: [MMUSIC] OPTIONS method in RTSP. Is it 
> required or not
> in minimal client and server implementations?
> 
> 
> Hello Emre,
> 
> for clients to not implement OPTIONS response. 

I agree with this. But in such a case, at least a "Not implemented" error status message has to be sent by the client to the server, right? In fact, my intention was to have the request to be a mandated requirement for the client. For the response to OPTIONS on the cliet side, I agree it can be optional as an implementation. 

> The rationale for not 

I see your point, but this is quite a statement, which I believe should be present in the RFC then. Also, the minimal implementation for server and client has some 'or' statements in it (for example for RECORD and PLAY method), which I believe, means that different sets of minimal implementations are possible, and a client has to check which set of implemenentation the server supports, even if the server is assumed to be a minimal implementation in the very beginning.

> think PING might be preferred over OPTIONS.

I agree, PING is a very good choice and I believe it will definitely find its place in the 3GPP spec. I have one question though. Can PING method identify a streaming session?. What I exactly mean is that, can a PING request bear a Session-ID?

Best Regards,
Emre

> > > From: ext Magnus Westerlund 
> [mailto:[email-masked]]
> >

---

From: Jeremy Worley <[email-masked]>
Date: Thu, 11 Jul 2002 22:07:00 -0700

Hi Emre and Magnus,

More comments inline.

At 12:48 PM 7/11/2002 +0300, [email-masked] wrote:
>Hi Magnus,
>
>Please see my comments inlined:
>
>
> > Sent: 11. July 2002 12:14
> > To: Jeremy Worley
> > Cc: Aksu Emre (NMP/Tampere); [email-masked]
> > See comments inline:
> > Jeremy Worley wrote:
> > > At 07:05 PM 7/10/2002 +0300, [email-masked] wrote:
> > >
> > >> Hi Jeremy,
> > >> I agree with this. But in such a case, at least a "Not
> > implemented"
> > >> error status message has to be sent by the client to the server,
> > >> right? In fact, my intention was to have the request to be
> > a mandated
> > >> requirement for the client. For the response to OPTIONS on
> > the cliet
> > >> side, I agree it can be optional as an implementation.
> > >
> > >
> > > I agree that the client should respond if it does not support
> > > responding to a server OPTIONS request.
> > >
> > > My opinion is that if the client does not use optional
> > features, then
> > > it should not have to issue an OPTIONS request.
> >
> > In other word you are happy with what is written today in appendix D.
> > Server must implement OPTIONS while it is totally optional
> > for a client.
> >
> > >
> > >
> > >> > The rationale for not
> > >> I see your point, but this is quite a statement, which I believe
> > >> should be present in the RFC then. Also, the minimal
> > implementation
> > >> for server and client has some 'or' statements in it (for
> > example for
> > >> RECORD and PLAY method), which I believe, means that
> > different sets
> > >> of minimal implementations are possible, and a client has to check
> > >> which set of  implementationthe server supports, even if
> > the server
> > >> is assumed to be a minimal implementation in the very beginning.
> > >
> > >
> > > You raise an interesting point.  Table 2 of 2326 and 2326bis states
> > > that RECORD is optional and PLAY is mandatory for the
> > client.  However
> > > D.1 and D.2 appear to state that it is required that either PLAY or
> > > RECORD can be implemented.  RECORD is described as an
> > optional feature
> > > in several places in 2326 (e.g., 1.5, 10.11, table 2).  I think in
> > > this case, it makes sense to make Section D consistent with
> > the rest
> > > of the document.
> > >
> > In this case my interpretation is that Appendix D is correct. There
> > actually exist several types of minimal implementations, one
> > for doing
> > playback from server, one for doing playback for servers of on demand
> > content and a third for recording to servers. They can further also
> > support authentication.
>
>
>If these many possibilites are present for minimal implementation where 
>the implementations actually differ in means of supported functionalities, 
>how does a client identify what kind of a server it is dealing with 
>without using OPTIONS method, if OPTIONS is not mandated also for the 
>client as a way of request to check the server capabilities? Can there be 
>a logical mismatch here?

For the client, I think it is OK to send a PLAY or a ANNOUNCE and get a 501 
(Not implemented) back.  In other words, a client should not be required to 
send an OPTIONS before it issues a PLAY or ANNOUNCE request.

On a related topic, I think that a problem does exist in section D.2 vs. 
the rest of the document.  Table 2 states that PLAY is required and 
ANNOUNCE/RECORD is optional.  Here again, a problem exists in that the 
table is not clear as to whether the requirement for support is on the 
client, server, or both.  I interpret this and statements in other sections 
(1.5, Table 3 in 12) to mean this:

- A client must implement one or more of PLAY, RECORD.  A client 
implementing RECORD must implement sending ANNOUNCE.  A server implementing 
RECORD must implement handling ANNOUNCE from a client and may implement 
sending ANNOUNCE to a client.

- A server must implement PLAY and may implement RECORD.

Reasoning:  there are reasonable cases where a client may implement only 
PLAY or RECORD.  I can't think of a likely scenario where a server would 
implement record functionality but not playback.

Jeremy

>Best Regards,
>Emre
>
>
>
> > The contradictions we must do the best to
> > remove. They are unfortunately very common in RFC 2326. As an
> > example I
> > found one more in Appendix D. The user agent header is only
> > RECOMMENDED
> > to implement by clients in Appendix D while the header definition in
> > RFC2616 section 14.43 says: "User agents SHOULD include this
> > field with
> > requests."
> >
> > >
> > >> I agree, PING is a very good choice and I believe it will
> > definitely
> > >> find its place in the 3GPP spec. I have one question
> > though. Can PING
> > >> method identify a streaming session?. What I exactly mean is that,
> > >> can a PING request bear a Session-ID?
> > >
> > >
> > > Table 4 in the draft states that the Session header mandatory for
> > > PING.  Interestingly, the example transaction in 10.12 does not
> > > include a Session header.  That example should be modified
> > to include
> > > a Session header.
> >
> > Yes, an error which will be corrected in the next version.
> >
> > >
> > > A minor editorial note: table 4 also seems to have floated
> > to a later
> > > section of the document in the current draft.  That should
> > be cleaned
> > > up in the next draft.
> >
> > Yes, the tables are floating around a bit. I don't think we will fix
> > that. I do feel that it is better to have as much of the table as
> > possible in one page. We still have to reformat the table as it is to
> > wide for a single page.
> >
> > Regards
> >
> > Magnus Westerlund
> >