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

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 1 Oct 2007 10:11:13 +0200

Hi,
 
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)

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?
 
Regards,
 
Christer
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Mon, 01 Oct 2007 14:21:18 -0400

"Christer Holmberg" <[email-masked]> writes:
>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... 
> 

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
[email-masked]
"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)

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 1 Oct 2007 15:22:01 -0700

> That probably violates a number of the offer-answer MUSTs, 
> but technically it certainly can be handled.  From Section 5:
> 
> 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.
 
> >and says that an appropriate grouping mechanism should be 
> >used to group the AVPF and AVP alternatives. 
> > 
> >that rule hasn't been changed. I assume this would be only 
> >an editorial bug? 
> 
> RFC 4566:
> 
> 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

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 2 Oct 2007 09:24:35 +0200

Christer,

Inline

________________________________

From: Christer Holmberg [mailto:[email-masked]] 
Sent: Monday, October 01, 2007 10:11 AM
To: [email-masked]
Subject: [AVT] Offer/answer questions on RFC 4585

Hi,

[RE:]  I think that is this case the offer  will include a=rtcp-fb with rtcp-fb-vals. Since the receiver understands AVPF but do not support any feedback message it will remove all rtcp-fb-val in the answers.

To me that looks like support of AVP so why do you want to change the avpf to avp.

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

[RE:] Yes

Regards,

Christer