Re: [rtcweb] Plan A, respun - bundle-only attribute

Hi,

One more question, regarding the bundle-only attribute:

Q3: Assume the answerer supports BUNDLE, and return an SDP answer with identical port numbers, as shown in section 7.1. I guess the second offer will then replace the zero port lines with the actual port value that the offerer uses for the multiplexing?

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Puolesta Christer Holmberg
Lähetetty: 7. toukokuuta 2013 22:46
Vastaanottaja: Adam Roach; rtcweb@ietf.org
Aihe: Re: [rtcweb] Plan A, respun - bundle-only attribute

Hi,

After couple of initial questions, related to the bundle-only attribute:

Q1: You are adding m- lines with a zero port value into a BUNDLE group. RFC 5888  (SDP grouping framework) currently explicitly forbids that, we have discussed it on the MMUSIC list, and the outcome (eventhough there weren't too many expressing their opinion) was that we were not going to allow zero port m- lines in BUNDLE groups.

Of course, we can always change that decision, but that would mean modifying RFC 5888.

Q2: It is indicated that devices that do not support BUNDLE will reject the bundle-only m- lines, by setting the port value to zero in the SDP Answer. That is probably true. But, what if the device DOES support BUNDLE as such, but does NOT want to use the same port number? I think that e.g. a gateway could act that way.

In my opinion, as BUNDLE now uses 2 offer/answer transactions, the device could be allowed to return different port values. Then the offerer, when sending the second offer, can decide whether it wants to keep them.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] Puolesta Adam Roach
Lähetetty: 7. toukokuuta 2013 21:31
Vastaanottaja: rtcweb@ietf.org
Aihe: [rtcweb] Plan A, respun

In order to facilitate discussion between the two SDP format alternatives we're considering, I've put together a document that more clearly spells out the Plan A approach as we originally envisioned it. 
Note that this is a slightly different approach than Cullen outlined in Orlando. I fear the Orlando approach may have suffered from its attempts to incorporate some elements of Plan B in an attempt to appease proponents of that approach; and, in doing so, lost some of its clean architecture.

The cleaned up, new-and-improved description of the Plan A approach is available here:

http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt

Note that we've omitted discussion of glare reduction from that document, as I believe that mid-session glare can be completely avoided by applications implementing a set of non-normative behaviors. These behaviors are described in the a separate companion document:

http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt

Thanks.

/a
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb