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).

>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".  The older
RFC for SDP didn't mention it.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup@wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

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