RE: [AVT] Offer/answer questions on RFC 4585

>"Christer Holmberg" <christer.holmberg@ericsson.com> writes:
>>I have a couple of questions on RFC 4585, regarding the usage with 
>>offer/answer.
>> 
>>My FIRST question is: are there any TECHNICAL reasons (I know it's
>>probably not allowed by RFC 3264) why a user receiving an AVPF offer, but
>>doesn't support it, can't reply with AVP answer (instead of rejecting the
>>stream)? My understanding is that if you offer AVPF you still have to be
>>able to do AVP, so... 
>> 
>>(The receiver of course needs to understand the "AVPF" string in the SDP)

> That probably violates a number of the offer-answer MUSTs, 
> but technically it certainly can be handled.  From Section 5:
> 
>    AVP and AVPF are defined in a way that, from a robustness point of
>    view, the RTP entities do not need to be aware of entities of the
>    respective other profile: they will not disturb each other's
>    functioning.  However, the quality of the media presented may
>    suffer.
> 
> and the rest of section 5 in general addresses this point, 
> though not head-on.  (Section 5 is obviously written with non-point-
> to-point uses in mind, where each participant may have accepted 
> one or the other).

The better way to handle this is to use SDP capability negotiation
(draft-ietf-mmusic-sdp-capability-negotiation) which doesn't require 
the answerer to understand the "F" of "AVPF" at all.  Using SDP
capability negotiation is more robust and allows much cleaner 
fallback.

> >My SECOND question is on example 3 in chapter 4.4. The RFC shows two
> >m=video lines (one AVPF and one AVP) with the SAME port 
> >number (51372),
> >and says that an appropriate grouping mechanism should be 
> >used to group the AVPF and AVP alternatives. 
> > 
> >However, I believe that even if you use some grouping 
> >mechanism, you are
> >still not allowed to use the same port number in two m= 
> >lines. There has
> >been much discussion about this on the MMUSIC list, but as 
> >far as I know
> >that rule hasn't been changed. I assume this would be only 
> >an editorial bug? 
> 
> RFC 4566:
> 
>       The semantics of multiple "m=" lines using the same transport
>       address are undefined.  This implies that, unlike limited past
>       practice, there is no implicit grouping defined by such 
> means and
>       an explicit grouping framework (for example, [18]) 
> should instead
>       be used to express the intended semantics.
> 
> The "limited past practice" probably refers to people ad-hoc using
> identical ports as a way of saying "accept a or b but not 
> both". 

I agree, that is probably what it was referring to.  However, its
reference to [18] (RFC3388) doesn't provide the escape clause that
the authors of RFC4566 intended.  Specifically, RFC3388 says this
about using the same transport address:

  "7.5.3 Same IP Address and Port Number

   If several codecs have to be sent to the same IP address and port,
   the traditional SDP syntax of listing several codecs in the same "m"
   line MUST be used.  FID MUST NOT be used to group "m" lines with the
   same IP address/port.  Therefore, an SDP like the one below MUST NOT
   be generated.

       v=0
       o=Laura 289083124 289083124 IN IP4 six.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       a=group:FID 1 2
       m=audio 30000 RTP/AVP 0
       a=mid:1
       m=audio 30000 RTP/AVP 8
       a=mid:2

   The correct SDP for the session above would be the following one:

       v=0
       o=Laura 289083124 289083124 IN IP4 six.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       m=audio 30000 RTP/AVP 0 8

   If two "m" lines are grouped using FID they MUST differ in their
   transport addresses (i.e., IP address plus port)."

-d

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt