Subject: [MMUSIC] BUNDLE and ZERO PORT VALUE

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 May 2013 12:55:13 +0000

Hi,

One of the open issues is the usage of m- lines with port value zero within a BUNDLE group.

As Paul has indicated, RFC 5888 does not currently allow it.

One suggestion has been to update RFC 5888. But, before we go down that path, I think we need to see whether NOT allowing zero port m- lines in BUNDLE groups would work.

So, how would it impact BUNDLE?

Zero port value in answer:

If an m- line in the offer contains a non-zero port value, but the associated m- line in the answer contains a zero port value (read: the answerer rejected the offered media associated with the m- line), the number of m- lines associated with the BUNDLE group would differ in the offer and answer.

As the media is rejected, no matter whether it would be part of a BUNDLE group or not, I can't think of any issues.

Zero port value in offer:

If an m- line in the offer contains a zero port value, the associated m- line in the answer MUST also contain a zero port value.

If the m- line has previously been part of a BUNDLE group, with a non-zero port value, it means that the number of m- lines in the BUNDLE group will be reduced. But, again, as the media is rejected, no matter whether it would be part of a BUNDLE group or not, I can't think of any issues.

Then, if one later wants assign a non-zero value to the m- line, and insert it into a BUNDLE group, the number of m- lines in the BUNDLE group would increase. I don't see any issues as such with that. One question, however, is whether the answerer is allowed to accept the m- line, but reject it being part of a BUNDLE group. But, let's discuss that in a separate thread.

SUGGESTION:

My suggestion is that we do NOT allow m- lines with zero port value in a BUNDLE group. Please indicate whether you are aware of restrictions, or problems, that this would bring, and we will document those.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 May 2013 10:49:30 -0400

Christer,

I think what you suggest should work.

An implication is that you can't signal how you would like to bundle a 
hypothetical m-line (currently with port zero) were it to subsequently 
be offered with a non-zero port. I think that is ok.

My take has always been that the mechanism of signaling a 
rejected/unused m-line with a zero port was intended to imply that none 
of the accompanying media section lines need to be valid, and ones that 
otherwise might have been required are not required in this case. That 
is necessary so that an answerer can successfully refuse an offered 
m-line that it doesn't understand, and so can't construct a consistent 
answer. So the recipient must be very tolerant about what it receives in 
this case. That means it isn't appropriate to specify *anything* about 
what goes into the media section of a rejected m-line.

	Thanks,
	Paul

On 5/2/13 8:55 AM, Christer Holmberg wrote:
> One suggestion has been to update RFC 5888. But, before we go down that
> path, I think we need to see whether NOT allowing zero port m- lines in
> BUNDLE groups would work.
>
> If an m- line in the offer contains a non-zero port value, but the
> associated m- line in the answer contains a zero port value (read: the
> answerer rejected the offered media associated with the m- line), the
> number of m- lines associated with the BUNDLE group would differ in the
> offer and answer.
>
> As the media is rejected, no matter whether it would be part of a BUNDLE
> group or not, I can’t think of any issues.
>
> If an m- line in the offer contains a zero port value, the associated m-
> line in the answer MUST also contain a zero port value.
>
> If the m- line has previously been part of a BUNDLE group, with a
> non-zero port value, it means that the number of m- lines in the BUNDLE
> group will be reduced. But, again, as the media is rejected, no matter
> whether it would be part of a BUNDLE group or not, I can’t think of any
> issues.
>
> Then, if one later wants assign a non-zero value to the m- line, and
> insert it into a BUNDLE group, the number of m- lines in the BUNDLE
> group would increase. I don’t see any issues as such with that. One
> question, however, is whether the answerer is allowed to accept the m-
> line, but reject it being part of a BUNDLE group. But, let’s discuss
> that in a separate thread.
>
> SUGGESTION:
>
> My suggestion is that we do NOT allow m- lines with zero port value in a
> BUNDLE group. Please indicate whether you are aware of restrictions, or
> problems, that this would bring, and we will document those.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 May 2013 17:42:08 +0000

Hi,

> be offered with a non-zero port. I think that is ok.

I was thinking about that also, and if someone can come up with a reason why it would be needed I'd like to hear it.

And, IF there is a good use-case, we could e.g. define an SDP media level attribute for indicating such thing.

m=audio 0 ....
a=maybe-I-want-to-be-part-of-the-following-bundle-group: BGROUP1

> what goes into the media section of a rejected m-line.

Agree. Good point.

Regards,

Christer