Subject: [MMUSIC] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt

From: Justin Uberti <[email-masked]>
Date: Thu, 2 May 2013 23:08:43 -0700

Scribbled down the basic concepts of what I have been referring to as "Plan
B" - a way to signal multiple MediaStreamTracks in SDP without needing a
separate m= line for each.

Hopefully this will make discussion of this topic easier.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <[email-masked]>

A new version of I-D, draft-uberti-rtcweb-plan-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename:        draft-uberti-rtcweb-plan
Revision:        00
Title:           Plan B: a proposal for signaling multiple media sources in
WebRTC.
Creation date:   2013-05-03
Group:           Individual Submission
Number of pages: 15
URL:
http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
Status:          http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan
Htmlized:        http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00

Abstract:
   This document explains how multiple media sources can be signaled in
   WebRTC using SDP, in a fashion that avoids many common problems and
   provides a simple control surface to the receiver.

The IETF Secretariat

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 06 May 2013 16:19:48 +0200

Note - I regard the Plan A / Plan B conflict as the "long end of the 
pole" with regards to resolving issues regarding SDP signalling in 
RTCWEB - and as such, I regard it as very important to get it resolved.

The silence on this issue is disquieting.

            Harald

On 05/03/2013 08:08 AM, Justin Uberti wrote:
> Scribbled down the basic concepts of what I have been referring to as 
> "Plan B" - a way to signal multiple MediaStreamTracks in SDP without 
> needing a separate m= line for each.
>
> From: <[email-masked] <mailto:[email-masked]>>
> To: Justin Uberti <[email-masked] <mailto:[email-masked]>>
>
>
>
> Title:           Plan B: a proposal for signaling multiple media 
> sources in WebRTC.
> URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 May 2013 10:11:55 +0000

Hi,

A few questions on the draft:

Q1_CODEC/CODEC CONFIGURATION:

The examples only show one PT per m- line, and the draft seem to assume that all PTs (ie codecs and/or codec configurations) apply to all SSRCs within an m- line. I think that is very important to point out, because at least in my opinion it is an important factor that we need to discuss.

Example: I think Cullen often talks about using a camera with built in codec X. But, Plan B does not allow to (or, at least does not describe how to) explicitly offer codec X for the track/ssrc associated with the camera. Codec X is offered for ALL tracks/ssrcs associated with the m- line.

Q2_1_LEGACY:

The text says that things must work with legacy devices, and that an endpoint can choose a single source when communicating with a legacy device. But, there is really no text about how the legacy device will know which source to use, etc.

Q2_2_LEGACY:

The example in section 5.2 (and sub sections) confuses me a little. You indicate that the m- line itself represents "main", while ssrc attributes are used to describe the left/center/right mic sources. Why is there no ssrc attribute for the main flow?

Q3_NUMBER_OF_M_LINES:

The draft does not explicitly forbid the usage of multiple m- lines for a given media type (e.g. audio). It would probably be good to point that out also.

Regards,

Christer

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 6. toukokuuta 2013 17:20
To: Justin Uberti
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt

Note - I regard the Plan A / Plan B conflict as the "long end of the pole" with regards to resolving issues regarding SDP signalling in RTCWEB - and as such, I regard it as very important to get it resolved.

           Harald

On 05/03/2013 08:08 AM, Justin Uberti wrote:
Scribbled down the basic concepts of what I have been referring to as "Plan B" - a way to signal multiple MediaStreamTracks in SDP without needing a separate m= line for each.

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <[email-masked]<mailto:[email-masked]>>

Title:           Plan B: a proposal for signaling multiple media sources in WebRTC.

Abstract:

The IETF Secretariat

rtcweb mailing list

[email-masked]<mailto:[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 07 May 2013 12:39:01 +0200

On 05/07/2013 12:11 PM, Christer Holmberg wrote:
> The examples only show one PT per m- line, and the draft seem to 
> assume that all PTs (ie codecs and/or codec configurations) apply to 
> all SSRCs within an m- line. I think that is very important to point 
> out, because at least in my opinion it is an important factor that we 
> need to discuss.
>
> Example: I think Cullen often talks about using a camera with built in 
> codec X. But, Plan B does not allow to (or, at least does not describe 
> how to) explicitly offer codec X for the track/ssrc associated with 
> the camera. Codec X is offered for ALL tracks/ssrcs associated with 
> the m- line.
>

My read: This is a very special use case. The sender always chooses the 
codec from the available codecs that the recipient can understand - and 
it's then free to choose the built in codec X if supported by the recipient.

If, for some reason, the application is dependent on segregating the 
codecs, it can use the "a=content" mechanism to segregate the streams 
onto different M-lines.

> Q2_1_LEGACY:
>
> The text says that things must work with legacy devices, and that an 
> endpoint can choose a single source when communicating with a legacy 
> device. But, there is really no text about how the legacy device will 
> know which source to use, etc.
>

The application that drives the API will have to decide that it can send 
only one source. The browser cannot (in my opinion) sensibly make that 
choice on behalf of the application.

> Q2_2_LEGACY:
>
> The example in section 5.2 (and sub sections) confuses me a little. 
> You indicate that the m- line itself represents "main", while ssrc 
> attributes are used to describe the left/center/right mic sources. Why 
> is there no ssrc attribute for the main flow?
>

The MSID identifier is, by definition, meaningless. The association 
between the MSID and the function of the stream is not carried in the 
MSID attribute. The example is a bit unfortunate in that it uses MSIDs 
that look as if they're human-readable strings that carry semantics.

> Q3_NUMBER_OF_M_LINES:
>
> The draft does not explicitly forbid the usage of multiple m- lines 
> for a given media type (e.g. audio). It would probably be good to 
> point that out also.
>

In fact the a=content mechanism (see section 3.1) depends on the ability 
to use multiple m- lines for a given media type, so it would be really 
hard to interpret the draft as forbidding this.

There's an issue with representing the semantics of an incoming call 
that uses multiple m- lines for a given media type and doesn't give 
differing a=content attributes for those media types.
I don't know if such a scenario ever occurs in practice.
>
> Regards,
>
> Christer
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Harald Alvestrand
> *Sent:* 6. toukokuuta 2013 17:20
> *To:* Justin Uberti
> *Cc:* [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> *Subject:* Re: [rtcweb] Fwd: New Version Notification for 
> draft-uberti-rtcweb-plan-00.txt
>
>     Scribbled down the basic concepts of what I have been referring to
>     as "Plan B" - a way to signal multiple MediaStreamTracks in SDP
>     without needing a separate m= line for each.
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 7 May 2013 12:45:23 +0200

> The silence on this issue is disquieting.

I agree. Thinking out loud: could a meeting (joint mmusic and rtcweb I 
guess), that has as objective to discuss and decided which Plan to move 
forward with, be set up?

Then there would be concrete deadlines, and most likely things would not 
stay as quiet.

I guess it is a question for the chairs of those groups.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 May 2013 12:08:19 +0000

Hi,
 
>> The examples only show one PT per m- line, and the draft seem to assume that all PTs (ie codecs and/or codec configurations) apply to all SSRCs 
>> within an m- line. I think that is very important to point out, because at least in my opinion it is an important factor that we need to discuss.
>>
> Example: I think Cullen often talks about using a camera with built in codec X. But, Plan B does not allow to (or, at least does not describe how to) 
> explicitly offer codec X for the track/ssrc associated with the camera. Codec X is offered for ALL tracks/ssrcs associated with the m- line.
>
> My read: This is a very special use case. The sender always chooses the codec from the available codecs that the recipient can understand - and it's then free to choose the built in codec X if supported by the recipient.
>
> If, for some reason, the application is dependent on segregating the codecs, it can use the "a=content" mechanism to segregate the streams onto different M-lines.

- Assume I have two cameras, one which can handle codec X, and one which can handle codec Y. 

- I send you an offer with a video m- line, offering X, Y and a ssrc for each camera

- You only want one of my camera streams, AND you only support codec X. Now, how do you know which ssrc to choose? You don't know which uses codec X.

Now, maybe this is a theoretical problem, but I think the draft needs to describe that codecs, and codec configurations, apply to all ssrcs associated with an m- line.

And, IF there is a need to apply codecs to a specific ssrc only, you need to use a separate m- line for that ssrc.

>> Q2_1_LEGACY:
>> 
>> The text says that things must work with legacy devices, and that an endpoint can choose a single source when communicating with a 
>> legacy device. But, there is really no text about how the legacy device will know which source to use, etc.
>
> The application that drives the API will have to decide that it can send only one source. The browser cannot (in my opinion) sensibly make that choice on behalf of the application.

Fair enough, but that needs to be clearly described.

>> Q2_2_LEGACY:
>> 
>> The example in section 5.2 (and sub sections) confuses me a little. You indicate that the m- line itself represents "main", while ssrc 
>> attributes are used to describe the left/center/right mic sources. Why is there no ssrc attribute for the main flow?
>
> The MSID identifier is, by definition, meaningless. The association between the MSID and the function of the stream is not carried in 
> the MSID attribute. The example is a bit unfortunate in that it uses MSIDs that look as if they're human-readable strings that carry semantics.

I wasn't referring to the MSID identifier, but more to the fact that you don't indicate the ssrc value for the "main" flow. I thought we were going to mandate the indication of the ssrc value for each flow, but maybe I remember wrong.

> In fact the a=content mechanism (see section 3.1) depends on the ability to use multiple m- lines for a given media type, so it would be really hard to interpret the draft as forbidding this.

Fair enough. My mistake.

Regards,

Christer

There's an issue with representing the semantics of an incoming call that uses multiple m- lines for a given media type and doesn't give differing a=content attributes for those media types.
I don't know if such a scenario ever occurs in practice.

 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 6. toukokuuta 2013 17:20
To: Justin Uberti
Cc: [email-masked]; [email-masked]
Subject: Re: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt

           Harald

 
---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <[email-masked]>

Abstract:

The IETF Secretariat

---

From: "Roni Even" <[email-masked]>
Date: Tue, 7 May 2013 15:51:40 +0300

Hi,

I think that plan B is the right direction. I am wondering if this should be discussed in RTCWEB or MMUSIC

I like the proposed solution for multicast support but there is also an individual draft in MMUSIC see http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-02 . I think that it will be good to have a separate document on simulcast support

Some comments

1.       In section 3.1 when talking about using more than one m-line for a media type I think that there are other cases when this may be required . for example, if an attribute is not specified at SSRC level or if the SDP will be simpler when using multiple m-line  )describing different codec combinations

2.       In section 3.2 the document says that collision will not happen if the answerer sees the SDP from the Offer. I am not sure it will work when joining a multipoint conference since the offer is joining an existing session and do not know what SSRC have been used. I think that the issue is handled in RFC5576 so you can point at it.

3.       The draft, as far as I can tell, is discussing point to point calls and full meshed conferences. I think we need to look at other topologies including a centralized MCU doing video switch, for example.

4.       In section 4.1 you suggest using the MSID as an indication for supporting plan B. I think that this may be RTCWEB specific and other usages like CLUE may use a different way to associate an SSRC to a Media Capture. My proposal is to use maxssrc. I think that it will be needed since an offer may include more options than can be really sent by the offerer and the maxssrc can tell the answerer how many it can select. It can also tell the answerer how many simultaneous RTP streams the offerer can receive. Otherwise it may be better to have a specific identifier that will tell that multiple RTP streams in an m-line are supported.

5.       I have a question about the last paragraph of section 4.2. Currently the answerer can start sending media immediately when getting the offer in parallel to sending the SDP answer since the offer includes receive capabilities and receive transport address. Are you suggesting that media will flow only after the 3 way handshake?

6.       Small nit on section 5.1.4, according to section 8 of the Lennox source selection draft, the third offer must have sending:on for the streams that are being sent so probably need a=ssrc:1 msid:left-mic sending:on

Roni Even

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 03 May, 2013 9:09 AM
To: [email-masked]; [email-masked]
Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt

---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <[email-masked]>

Abstract:

The IETF Secretariat

  _____

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 07 May 2013 15:08:35 +0200

> - You only want one of my camera streams, AND you only support codec X. Now, how do you know which ssrc to choose? You don't know which uses codec X.

Right. That's the part that goes all artificial on me. Two cameras, and 
I'm going to choose blindly between them if I support both codecs, but I 
can't accept both and let you deal with sending me only the one I can 
handle?

You can, if you want to, send me two M-lines: "a=content:codec-x" and 
"a=content:codec-y". This is an example of "the application is dependent 
on segregating the codecs".

> And, IF there is a need to apply codecs to a specific ssrc only, you need to use a separate m- line for that ssrc.

Agreed.

> I wasn't referring to the MSID identifier, but more to the fact that you don't indicate the ssrc value for the "main" flow. I thought we were going to mandate the indication of the ssrc value for e…

I was trying to locate the flows in the example in section 5.2, and I 
couldn't find them anywhere but in the MSID attribute. So I couldn't 
parse your comment.

The way I read the document, the first m=audio line is the main audio; 
it has 3 audio flows.
The first m=video line is the main video; it has 3 video flows.
The third m=video line is the slides video; it has 2 SSRCs, one for the 
main flow and one for the repair flow.

So - the issue seems to be that the word "main" as in "main audio" is 
easy to mistake for "a single main flow". It isn't intended to be that 
way. I guess the text could be clearer.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 07 May 2013 15:25:35 +0200

> should be discussed in RTCWEB or MMUSIC

Good question.

> I like the proposed solution for multicast support but there is also 
> an individual draft in MMUSIC see 
> http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-02 . 
> I think that it will be good to have a separate document on simulcast 
> support
>
> Some comments
>
> 1.In section 3.1 when talking about using more than one m-line for a 
> media type I think that there are other cases when this may be 
> required . for example, if an attribute is not specified at SSRC level 
> or if the SDP will be simpler when using multiple m-line  )describing 
> different codec combinations
>
> 2.In section 3.2 the document says that collision will not happen if 
> the answerer sees the SDP from the Offer. I am not sure it will work 
> when joining a multipoint conference since the offer is joining an 
> existing session and do not know what SSRC have been used. I think 
> that the issue is handled in RFC5576 so you can point at it.
>
> 3.The draft, as far as I can tell, is discussing point to point calls 
> and full meshed conferences. I think we need to look at other 
> topologies including a centralized MCU doing video switch, for example.
>

I'm not sure the multipoint conference scenario (using a mixer, 
transport relay or multicast) is in scope here. Those scenarios can't be 
done with offer/answer anyway.

With scenarios that do centralized call termination (and not using 
CSRC), doing per-leg SSRC allocation is reasonable.

> 4.In section 4.1 you suggest using the MSID as an indication for 
> supporting plan B. I think that this may be RTCWEB specific and other 
> usages like CLUE may use a different way to associate an SSRC to a 
> Media Capture. My proposal is to use maxssrc. I think that it will be 
> needed since an offer may include more options than can be really sent 
> by the offerer and the maxssrc can tell the answerer how many it can 
> select. It can also tell the answerer how many simultaneous RTP 
> streams the offerer can receive. Otherwise it may be better to have a 
> specific identifier that will tell that multiple RTP streams in an 
> m-line are supported.
>
> 5.I have a question about the last paragraph of section 4.2. Currently 
> the answerer can start sending media immediately when getting the 
> offer in parallel to sending the SDP answer since the offer includes 
> receive capabilities and receive transport address. Are you suggesting 
> that media will flow only after the 3 way handshake?
>
> 6.Small nit on section 5.1.4, according to section 8 of the Lennox 
> source selection draft, the third offer must have sending:on for the 
> streams that are being sent so probably need a=ssrc:1 msid:left-mic 
> sending:on
>
> Roni Even
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Justin Uberti
> *Sent:* 03 May, 2013 9:09 AM
> *To:* [email-masked]; [email-masked]
> *Subject:* [rtcweb] Fwd: New Version Notification for 
> ------------------------------------------------------------------------
>
>
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 May 2013 17:03:21 +0000

Hi,
 
> way. I guess the text could be clearer.

That is how I understood it - that "main" is a flow by itself, separate from the left/center/right mic flows :)

Maybe "media description for main audio flows" would be a move clear description, rather than simply "main audio".

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 May 2013 14:56:10 -0700

Roni said:  
3.       The draft, as far as I can tell, is discussing point to point calls and full meshed conferences. I think we need to look at other topologies including a centralized MCU doing video switch, for example.
[BA] There should be an evaluation against the RTP topology bis draft which would include assessment of compatibility.  In addition to "video switch" I would be interested in RTP translator compatibility as well. 

4.       In section 4.1 you suggest using the MSID as an indication for supporting plan B. I think that this may be RTCWEB specific and other usages like CLUE may use a different way to associate an SSRC to a Media Capture. My proposal is to use maxssrc. 

[BA] Among other things, putting maxssrc in the Offer partially addresses the issue of being able to receive streams before the Answer is received.  However, since the Offerer will not know the SSRCs that it is expected to receive there has got to be a way to map the incoming streams to WebRTC mediastreams.   

5.       I have a question about the last paragraph of section 4.2. Currently the answerer can start sending media immediately when getting the offer in parallel to sending the SDP answer since the offer includes receive capabilities and receive transport address. Are you suggesting that media will flow only after the 3 way handshake?
[BA] Yes, I think that is the implication, though it doesn't seem either necessary or desirable to me.  Actually, I don't think that "Peer B" will be able to send until it gets an Answer to its Offer (the second Offer/Answer exchange), because it won't know what streams "Peer A" is prepared to accept (assuming there is no maxssrc in the initial offer).

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 May 2013 15:02:09 -0700

Roni said: 

I
            think that plan B is the right direction. I am wondering if
            this should be discussed in RTCWEB or MMUSIC

    To the extent that the proposals are attempts to "profile" existing RFCs or MMUSIC work in progress for use in WebRTC, it seems to me like the discussion belongs in RTCWEB. One advantage of that approach is that the solution need not necessarily apply to "all uses of SDP for any scenario for all time", just to the WebRTC use cases. 

To the extent that NEW SDP functionality is needed, MMUSIC discussion would be appropriate.  But until the general direction is decided, it won't be clear what the required new functionality is (if any).

---

From: "Roni Even" <[email-masked]>
Date: Wed, 8 May 2013 01:47:02 +0300

Hi Bernard,

The reason I asked was before plan A and plan B were discussed in MMUSIC in
Orlando. Yet I understand that if the purpose of this draft and Adam's one
are to describe how to do things in RTCweb it should be discussed in RTCWEB.
And we will need a similar one in CLUE probably in
draft-ietf-clue-rtp-mapping

Roni

From: Bernard Aboba [mailto:[email-masked]] 
Sent: 08 May, 2013 1:02 AM
To: Harald Alvestrand; Roni Even
Cc: [email-masked]; [email-masked]
Subject: RE: [rtcweb] [MMUSIC] Fwd: New Version Notification for
draft-uberti-rtcweb-plan-00.txt

Roni said: 

I think that plan B is the right direction. I am wondering if this should be
discussed in RTCWEB or MMUSIC

To the extent that the proposals are attempts to "profile" existing RFCs or
MMUSIC work in progress for use in WebRTC, it seems to me like the
discussion belongs in RTCWEB. One advantage of that approach is that the
solution need not necessarily apply to "all uses of SDP for any scenario for
all time", just to the WebRTC use cases. 

To the extent that NEW SDP functionality is needed, MMUSIC discussion would
be appropriate.  But until the general direction is decided, it won't be
clear what the required new functionality is (if any).

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 May 2013 16:07:06 -0700

Roni said: 
"If the purpose of this draft and Adam’s one are to describe how to do things in RTCweb it should be discussed in RTCWEB. And we will need a similar one in CLUE probably in draft-ietf-clue-rtp-mapping."

[BA] There are RTP issues to discuss (e.g. draft-ietf-clue-rtp-mapping relationship to draft-ietf-rtcweb-rtp-usage), and there are SDP issues.  To date, I believe we have somewhat neglected the RTP discussion, which is unfortunate, because if all the time is spent talking about the SDP Hammer, then the inclination is to use it to pound every nail, and if there is no SDP, then we have no tools at all. 

The place for the RTP discussion is probably not in RTCWEB (more like AVTCORE).

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 08 May 2013 12:05:35 +0200

On 05/08/2013 01:07 AM, Bernard Aboba wrote:
> Roni said:
> "If the purpose of this draft and Adam’s one are to describe how to do 
> things in RTCweb it should be discussed in RTCWEB. And we will need a 
> similar one in CLUE probably in draft-ietf-clue-rtp-mapping."
>
> [BA] There are RTP issues to discuss (e.g. draft-ietf-clue-rtp-mapping 
> relationship to draft-ietf-rtcweb-rtp-usage), and there are SDP 
> issues.  To date, I believe we have somewhat neglected the RTP 
> discussion, which is unfortunate, because if all the time is spent 
> talking about the SDP Hammer, then the inclination is to use it to 
> pound every nail, and if there is no SDP, then we have no tools at all.

I felt that the discussion of draft-ietf-rtcweb-rtp-usage was largely 
uncontroversial in the Stockholm interim, and that not much further 
discussion of that level of the stack was needed - so I have not been 
worrying much about it after that.

It's more like we've got the RTP nail in place, and are hammering on it 
with the SDP hammer... if we were to use an axe instead (hopefully the 
back end of it), not much in RTP would change.

> The place for the RTP discussion is probably not in RTCWEB (more like 
I think we've already done most of the discussion needed in AVTCORE - we 
seem to have the dictum of "don't send audio and video on the same 
5-tuple" changed to "if you send audio and video on the same 5-tuple, 
here's what you need to consider", which was really the only critical 
*change* I saw in RTP-land.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 9 May 2013 15:49:45 +0000

> Hopefully this will make discussion of this topic easier.

I think my largest questions was does an endpoint have to know when it carets an offer if that is going to be sent to a legacy end point or not. I'm particularly interested in multiscreen video conferences systems.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 9 May 2013 18:43:09 +0000

ON: 09 May 2013 16:50 Cullen Jennings (fluffy) Wrote:

> 
> I think my largest questions was does an endpoint have to know when it
> carets an offer if that is going to be sent to a legacy end point or
> not. I'm particularly interested in multiscreen video conferences
> systems.
> 

The same question also seems relevant to the respun plan A given that the temptation will be to use a=bundleonly which greatly simplifies the offer (i.e. less confusion over candidates etc.) but at the cost of interoperability with legacy multiscreen systems.  Don't you agree?

Andy