[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MMUSIC] RE: alternate RTP profiles in SDP offer/answer


Hi Francois,

sorry for the response delay.  I just returned from travel and did not
have connectivity during the recent mail flood.  I'll respond to this
one and then try to work my way backwards.


Perhaps a simple statement upfront to clarify it would help.

For example, the  first paragraph of Page 7 currently state:

   Different RTP profiles MAY be used in different media sessions.
   For negotiation of a media description, the four profiles AVP,
   AVPF, SAVP, and SAVPF are mutually exclusive.  Note, however, that
   SAVP and SAVPF entities MAY be mixed in a single RTP session (see
   section 4).  Also, the offer/answer mechanism MAY be used to offer
   alternatives for the same media session (e.g. using the same
   transport parameters) and allow the answered to choose one of the
   profiles.

It could be emphasised that what you are really saying is that the
alternatives are using multiple media descriptions (i.e., multiple m
lines)
in a single media session. Something like:

   Different RTP profiles MAY be used in different media sessions.
   For negotiation of a media description, the four profiles AVP,
   AVPF, SAVP, and SAVPF are mutually exclusive.  Note, however, that
   SAVP and SAVPF entities MAY be mixed in a single RTP session (see
   section 4).  Also, the offer/answer mechanism MAY be used to offer
   alternatives for the same media session (e.g. using the same
transport parameters and multiple media descriptions) and allow ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
   the answered to choose one of the profiles.


That could work.


Also, in section 1.1, the description of (SDP) media description could
be clarified with something like:

   (SDP) media description:
        This term refers to the specification given in a single m=
        line in an SDP message.  An SDP media description may define
only one RTP session. Grouping of m= lines in SDP (each with ^^^^^^^^^^ 
        their own distinct transport address as described in [9]) may
cause
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        several SDP session level descriptions to define (alternatives
        of) the same RTP session for the same media type.
Or something along those lines. 

Adding this sentence would kill one interesting use case: For example,
AVP and AVPF can work in the same session in a mixed operation (while
AVO anf SAVP cannot).  For mixed operation to be possible, however,
these tools MUST use the same transport addresses.

Therefore, the above description needs to be a bit more explicit about
what it allows in order not to defeat perfectly legitimate use cases.

But you brought up an important point for which I need to scan the
draft spec in depth.  I will collect further items from the other
mails and reply one by one (but this may take a day or two) and
then hopefully get a revised spec within two weeks or so that reflects
these clarifications.

Thanks,
Joerg