Subject: [rtcweb] No Plan

From: Emil Ivov <[email-masked]>
Date: Wed, 29 May 2013 21:59:35 +0300

Hey all,

Based on many of the discussions that we've had here, as well as many 
others that we've had offlist, it seemed like a good idea to investigate 
a negotiation alternative that relies on SDP and Offer/Answer just a 
little bit less.

The following "no plan" draft attempts to present one such approach:

http://tools.ietf.org/html/draft-ivov-rtcweb-noplan

The draft relies on conventional use of SDP O/A but leaves the 
intricacies of multi-source scenarios to application-specific 
signalling, with potentially a little help from RTP.

Hopefully, proponents of Plans A and B would find that the 
interoperability requirements that concerned them can still be met with 
"no plan". Of course they would have to be addressed by 
application-specific signalling and/or signalling gateways.

Comments are welcome!

Cheers,
Emil

-- 
https://jitsi.org

---

From: Mary Barnes <[email-masked]>
Date: Wed, 29 May 2013 14:23:22 -0500

Personally, I really like this approach.  I think it will work well
for CLUE. You might also want to add a reference to XCON in section 4.
  The very reason we chartered XCON was because it seemed much more
sensible to include more complex conferencing operations in a separate
application layer protocol as opposed to overloading SIP/SDP O/A.

Mary.

On Wed, May 29, 2013 at 1:59 PM, Emil Ivov <[email-masked]> wrote:
> Hey all,
>
> Based on many of the discussions that we've had here, as well as many others
> that we've had offlist, it seemed like a good idea to investigate a
> negotiation alternative that relies on SDP and Offer/Answer just a little
> bit less.
>
> The draft relies on conventional use of SDP O/A but leaves the intricacies
> of multi-source scenarios to application-specific signalling, with
> potentially a little help from RTP.
>
> Hopefully, proponents of Plans A and B would find that the interoperability
> requirements that concerned them can still be met with "no plan". Of course
> they would have to be addressed by application-specific signalling and/or
> signalling gateways.
>
> Comments are welcome!
>
> Cheers,
> Emil
>
> --
> https://jitsi.org
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 May 2013 15:57:44 -0400

Emil,

I'm going to reserve judgment on this pending further discussion.
I think this *might* work for CLUE, but I want to be certain.

The following statements (culled from various places in the text) leave 
me confused about your intent:

    This is exactly what the use of Offer/Answer discussed here strives
    to achieve.  Audio/Video offers originating from WebRTC endpoints
    will always have a maximum of one audio and one video m= line.  It
    will be up to applications to determine exactly how many streams they
    can afford to send once such a session has been established.  The
    exact mechanism to do this is outside the scope of this document (or
    WebRTC in general).

    For the sake of interoperability this specification strongly advises
    against the use of multiple m= lines for a single media type.  Not
    only would such use be meaningless to a large number of legacy
    endpoints but it is also likely to be mishandled by many of them and
    to cause unexpected behaviour.

    ...  Whatever the reason, offerers that find
    they need more than the available payload type numbers, will simply
    need to either use a second bundle group or not use BUNDLE at all
    (which in the case of a single audio and a single video m= line
    amounts to roughly the same thing).  ...

I'm concerned with decomposed endpoints that can't manage all the 
streams on the same address/port. They will need multiple independent 
m-lines and/or bundle groups.

Further questions:

I presume that you expect bandwidth in the SDP to be an aggregate 
per-m-line, with application specific signaling for bandwidth at the 
per-RTP-stream level?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 May 2013 07:44:23 +0000

Hi Emil,

The draft says:

	"For the sake of interoperability this specification strongly advises
   	against the use of multiple m= lines for a single media type."

My understanding is that the usage of multiple m= lines for a single media type would not affect the mechanism as such, but I just want to verify that :)

Also, there ARE "legacy" implementations that use multiple m= lines for a single media type (e.g. video enabled devices using two video m= lines: one for camera content, and one for slides).

So, while I definitely think that legacy interoperability shall be taken into consideration, I would not like to make such strong statements. In my opinion (the draft also talks about it), the usage of multiple simultaneous SSRCs per m- line is a much bigger issue when it comes to legacy interoperability.

Also, in CLUE we have been working on signaling scenarios with multiple m= lines per media type.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Emil Ivov
Sent: 29. toukokuuta 2013 22:00
To: [email-masked]
Subject: [rtcweb] No Plan

Hey all,

Based on many of the discussions that we've had here, as well as many others that we've had offlist, it seemed like a good idea to investigate a negotiation alternative that relies on SDP and Offer/Answer just a little bit less.

The draft relies on conventional use of SDP O/A but leaves the intricacies of multi-source scenarios to application-specific signalling, with potentially a little help from RTP.

Hopefully, proponents of Plans A and B would find that the interoperability requirements that concerned them can still be met with "no plan". Of course they would have to be addressed by application-specific signalling and/or signalling gateways.

Comments are welcome!

Cheers,
Emil

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 30 May 2013 10:24:28 +0200

Hi Emil,

a couple of comments:

"1.  Expose the SSRCs of all local MediaStreamTrack-s that the
        application may want to attach to a PeerConnection."

I don't think that would be possible, or desirable. SSRC _only_ come 
into play when a MediaStreamTrack is to be transported over the network 
- it is useless in local cases. And, the same local MediaStreamTrack 
could be sent to several peers (using different PeerConnections) and 
could have different SSRC's (and even different number of SSRC's) for 
the different peers.

I think SSRCs would only be available for MediaStreamTracks that are 
attached to a PeerConnection.

One thing I like about Plan A and B is that the naive application 
developer does not have to deal with things below MediaStream and 
MediaStreamTrack level. The application would simply add a MediaStream 
(containing MediaStreamTracks) to the PeerConnection, do the 
createOffer/setLocal and exchange signaling blobs that it need not look 
into, and the MediaStream with MediaStreamTrack's would be reflected at 
the remote end. The application would not have to deal with PT's, SSRC's 
etc.

I think that the "No Plan" proposal could be made similar if the info 
about how MediaStreamTrack's relate to SSRC's (including those for FEC 
and RTX) is exchanged using some blobs that the (naive) app can just 
exchange and need not look into.

If done that way, "No Plan" seems to me to be quite similar to Plan B, 
with the difference being that the info about how SSRC's relate to 
MediaStreamTrack's is exchanged not in the core SDP but in separate 
messages. This could be seen as an improvement I think.

Stefan

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 30 May 2013 02:19:39 -0700

Comments below.

On May 30, 2013, at 1:24, "Stefan Håkansson LK" <[email-masked]> wrote:

> I don't think that would be possible, or desirable. SSRC _only_ come into play when a MediaStreamTrack is to be transported over the network - it is useless in local cases. And, the same local MediaStreamTrack could be sent to several peers (using different PeerConnections) and could have different SSRC's (and even different number of SSRC's) for the different peers.
> 
> I think SSRCs would only be available for MediaStreamTracks that are attached to a PeerConnection.

[BA] If ICE fails, it may be necessary to use alternative transport, outside of PeerConnection. So if SSRCs are to be used in signaling for that case, the API needs to make them available.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 30 May 2013 11:55:02 +0200

On 2013-05-30 11:19, Bernard Aboba wrote:
> Comments below.
>
> On May 30, 2013, at 1:24, "Stefan Håkansson LK"
> <[email-masked]> wrote:
>
>> Hi Emil,
>>
>> a couple of comments:
>>
>> I don't think that would be possible, or desirable. SSRC _only_
>> come into play when a MediaStreamTrack is to be transported over
>> the network - it is useless in local cases. And, the same local
>> MediaStreamTrack could be sent to several peers (using different
>> PeerConnections) and could have different SSRC's (and even
>> different number of SSRC's) for the different peers.
>>
> [BA] If ICE fails, it may be necessary to use alternative transport,
> outside of PeerConnection. So if SSRCs are to be used in signaling
> for that case, the API needs to make them available.

Definitely.

But my point was that unless there is an intention to transport, SSRCs 
are useless (and they only have a meaning if there is RTP involved, 
right?). There are a lot of local use cases for MediaStream's 
(containing MediaStreamTrack's), so it does not make sense to add SSRC 
APIs to those objects; it belongs to PeerConnection IMO.

But when (if) another transport object in JS space than PeerConnection 
is defined, it would also need an API where SSRCs could be accessed.

Stefan

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 May 2013 11:07:46 -0400

> attached to a PeerConnection.

If that is true, then I think it calls for exposing to the API an object 
that binds MediaStreamTrack to the PeerConnection, so that there is a 
place to hang the SSRC attribute.

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 30 May 2013 11:07:17 -0600

So my read of this draft is that it allows two camera to send on the same PT but the applications would demux them based on SSRC and the browser would only look at the PT. 

I can't understand how this would possibly work. Lets say they are both VP8, we two different VP8 decoder contexts. The jitter buffers for the two need to be different. Unless that VP8 decoder is in the JS along with the jitter buffer, how does this work ?

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 30 May 2013 11:07:15 -0600

Interesting draft but it seemed to have more questions about how things would wok than answers. Let me try and ask you some specifics to help flesh out what this plan is and offer a few comments.

Of the actual recommendations in the draft that relate to the problem I would summarize that draft as 

1) demux RTP based on PT but let the application know the SSRC in case it wants to do something more 

2) the way the applications interacts with the browser for set up of the media stack is via SDP 

3) Other session control not related to the media stack is left up to the application to do how it wants

4) Things like conference control and clue control  and call control should be handled by the application

5) you have a few avenues we might pursue for making FEC, RTC, etc work 

6) you have some API requirements which, with the exception of 4 about exposing the max number of incoming streams that can be decoded, I think are pretty much agreed to be put put in W3C API already. On the topic of #4, it's a big unclear what is really needed and ongoing discussion is happening around how do indicate what can be received but thats a webrtc issue

This is very close to Plan A. So I read the whole draft and asked myself how is this different than plan A. What parts of this draft would not be abel to do if we did Plan A. The only real topic I could come up with was the port music here is PT only instead of PT + SSRC. I'l start a separate thread on that. 

But lets ask what the proposal is for the question Plan A and Plan B are trying to resolve. 

Let's say browse A wants to say it can send two streams of video and here are the parameters for the video codecs for each to the streams. What does the SDP that createOffer generates look like? I see the draft says "strongly advises against the use of multiple m= lines for a single media type. " but I don't really know what you mean by that. Can you explain what you are actually proposing we do do instead of just saying what not to do ?

The above paragraph is the most important part of my email. Please, what is the proposal for what the SDP in the offer looks like. 

The idea of exposing a low level API to the media stack and having the all proposing to do FEC, RTX, SDP processing ect has been discussed many times across the various working groups. It' jokingly refereed to as comment 22 at this point. It's not that it does not have merits, but many people myself included see it as a much longer road to get done, a lot more work, and no clear gain. One of the other issues is we are trying to make this so you don't have to be a telephone expert to use it and that lots of developers can use it. I'm not going to try and summarize the low level API augments here but if you want to discus it webrtc is the right WG. 

I'll note there are many points in the draft that I disagree with but I'd rather try and sort through what the actually proposal is here before addressing any of them.

There is one point I would like to make that is the confusion introduced by "legacy endpoint". When I talk about legacy endpoints, I am talking about endpoints that use SIP or Jingle and both past ones and future endpoints. SIP will continue to evolve  and I expect WebRTC to continue being able to negotiate new features. For example, if a SIP phone added VP9 and a browser supported VP9, I would expect to be able to use it. The legacy refers to an older protocol, SIP, and not to the age of the endpoint. We do know that things can't work with all deployed endpoints and long ago we made the decision to give up on endpoints that don't do ICE. But we do try and have a reasonable experience with old and future endpoints.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 30 May 2013 11:10:09 -0600

On May 29, 2013, at 1:23 PM, Mary Barnes <[email-masked]> wrote:

> for CLUE. 

Mary, I'm really trying to get my head around all the CLUE stuff and make sure music can do something that, as much as possible, works for CLUE, WebRTC and other SIP users. Can you elaborate on what part of this draft you like and why that works for CLUE. I think that would help find good solutions.

---

From: Gunnar Hellstrom <[email-masked]>
Date: Thu, 30 May 2013 23:03:58 +0200

Interesting.

I find it to be good to have a specified ambition for legacy 
interoperability.
But I cannot see how we could specify it without RTP based real-time 
text on the SIP side.

It seems that you mean that support for sessions with media beyond the 
defined limited legacy session will be specified and implemented for 
each application where they appear.

I think that leaves real-time text usage with too high risk of not 
achieving harmonized interoperability and not being supported in an 
harmonized way. It needs to be included in the interoperability 
specification.

A very important driving force behind legacy interop will be emergency 
service access. We have touched that before, and there has been varying 
acceptance for that fact, but it will be needed. The emergency services 
cannot be expected to set up parallel systems for each call control 
environment, but will need to get calls converted to SIP. And video, 
audio, real-time text and text messaging are specified for the 
interface. I think it is best to accept to build that whole set of media 
into rtcweb from the beginning.

This set of media is of course not only used for emergency calling, but 
also for user-to-user sessions. It is just that the emergency service is 
a good harmonizing factor. What you need to do to interoperate with 
emergency services is convenient to also offer for interop with other 
providers.

This reasoning is not isolated to the No Plan, but it stood out so clear 
in your chapter about the limited interoperability plan.

The No Plan would just need to be extended with reasoning about m=text 
for RTP based real-time text.

(It possibly need some text about text messaging also if there is any 
interest in that. Someone else need to argue for that. Is it sdp - 
negotiated MSRP that would be the natural choice, requiring a discussion 
of data channel inclusion in the draft?)

/Gunnar

On 2013-05-29 20:59, Emil Ivov wrote:
> others that we've had offlist, it seemed like a good idea to 
> investigate a negotiation alternative that relies on SDP and 
> Offer/Answer just a little bit less.
>
> interoperability requirements that concerned them can still be met 
> with "no plan". Of course they would have to be addressed by

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 30 May 2013 23:33:39 +0200

2013/5/30 Gunnar Hellstrom <[email-masked]>:
> But I cannot see how we could specify it without RTP based real-time text on
> the SIP side.

> The No Plan would just need to be extended with reasoning about m=text for
> RTP based real-time text.
>
> negotiated MSRP that would be the natural choice, requiring a discussion of
> data channel inclusion in the draft?)

In the Web there are lot of ways for sending any kind of messages. In
WebRTC we are not limited to the "RTP" channel to communicate with
others (peers or servers). In WebRTC the destination of a "media
session" is not mandated to be a PSTN phone or PSTN server.

Here there is a "web context", something that does not exist in VoIP
protocols which are just limited to the signaling capabilities of the
protocol itself. Here the application using WebRTC (a JavaScript
application) is a custom app designed to work with a custom server
side (the web server), and each website will choose and design how
their client applications (the JS of their web pages) communicate with
their web servers and other clients. This includes usage of HTTP
requets, AJAX, WebSocket or whatever. We are not constrained to the
"media channel" anymore, this is not the PSTN with funny DTMFs for
all.

So honestly I don't understand why WebRTC should care about "text
messaging via RTP", and I really hope that "MSRP" word is never
included in any RTCWEB WG specification. IMHO it's already enough
having 3 proposals attempting to adapt SDP into WebRTC requirements.

Gateways are required, in any way, for connecting WebRTC and the world
outside (SIP, PSTN, etc), let's leave those gateways to do the "magic"
instead of proposing that a browser can send text messages via RTP to
a SIP phone.

Just my opinion.

Regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 31 May 2013 00:06:57 +0200

> having 3 proposals attempting to adapt SDP into WebRTC requirements. 

To be fair, only two proposals try to modify the SDP, the third about 
not adapting the SDP or change the O/A model.

> a SIP phone. Just my opinion.

Indeed. I understand Gunnar requirements for RTT, but as you say, to 
connect to legacy devices you would need a gateway in the middle anyway. 
If the gateway support datachannels, It would be fairly trivial to 
bridge the real time text data from T140 rtp packets from/to the browser.

Best regards
Sergio

---

From: Gunnar Hellstrom <[email-masked]>
Date: Fri, 31 May 2013 07:32:07 +0200

On 2013-05-31 00:06, Sergio Garcia Murillo wrote:
>>> text on
>> Gateways are required, in any way, for connecting WebRTC and the 
>> world outside (SIP, PSTN, etc), let's leave those gateways to do the 
>> "magic" instead of proposing that a browser can send text messages 
>> via RTP to a SIP phone. Just my opinion.
It is not about text messages, it is about the real-time text medium. 
Just like real-time audio and real-time video. Smoother than messaging. 
Its user requirements for real-time transmission are close to the needs 
for audio and video, so it is on the rim to need RTP, but well designed 
data channel can also do. I do not understand why modern communication 
users accept to see a chat state indication of "composing" instead of 
really seeing what text is composed. With real-time text you get rid of 
the frustration that "composing" creates.
Now, this was not meant to be a repetition of the motivations for 
real-time text, but a discussion on interoperability requirements and 
sdp handling.
> connect to legacy devices you would need a gateway in the middle 
> anyway. If the gateway support datachannels, It would be fairly 
> trivial to bridge the real time text data from T140 rtp packets 
> from/to the browser.
Yes, agreed, a data channel is one possible transport for real-time text 
and we need to get down to describing the alternatives and decide soon. 
What I am getting afraid of when I see the limited interperabillity 
discussion in "No Plan" is that we will not get a chance to specify the 
full view of the really needed interoperability. The mechanisms are tied 
to RTP characteristics, such as SSRCs, and it is said that interop 
beyond that limited scope will be an application concern. If this is the 
only place where we will discuss common specifications for SIP 
interoperability, then I want RTT to ride with this train and not be 
left alone on the station.

I also do not share Iñaki's view that rtcweb is all about communication 
between a server and a client delivered by that server, so that text 
communication is a local thing between that server and client. We have 
agreed that rtcweb must not be the continuation of building silos. Users 
of different providers and servers will want to have communication with 
each other, and that creates a need for explicit standards for session 
establishment and media stream establishment. Real-time text is one of 
the basic media together with audio and video which need to be fully 
defined for such interoperability.

Regards
Gunnar

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 31 May 2013 10:18:43 +0200

El 31/05/2013 7:32, Gunnar Hellstrom escribió:
> Yes, agreed, a data channel is one possible transport for real-time 
> text and we need to get down to describing the alternatives and decide 
> soon. What I am getting afraid of when I see the limited 
> interperabillity discussion in "No Plan" is that we will not get a 
> chance to specify the full view of the really needed interoperability. 
> The mechanisms are tied to RTP characteristics, such as SSRCs, and it 
> is said that interop beyond that limited scope will be an application 
> concern. If this is the only place where we will discuss common 
> specifications for SIP interoperability, then I want RTT to ride with 
> this train and not be left alone on the station.

How "No Plan" is limiting interoperability for RTT? Supporting RTT is an 
orthogonal topic to No Plan/Plan A/Plan B as they are about how to 
handle different multiple tracks of the already defined media types. If 
RTT media tracks are finally supported by webrtc, they will be handled 
by "No Plan" automatically, and will be in fact handled the same way as 
it is done today in RTT sip clients, so in fact "No Plan" makes 
interoperability easier, not harder.

Best regards
Sergio

---

From: Emil Ivov <[email-masked]>
Date: Fri, 31 May 2013 13:51:04 +0300

Hey Mary,

> application layer protocol as opposed to overloading SIP/SDP O/A.

Agreed!

Thanks,
Emil

> .

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Fri, 31 May 2013 13:51:19 +0300

Hey Paul,

> I think this *might* work for CLUE, but I want to be certain.

Sure!

> m-lines and/or bundle groups.

This is obviously open for debate but the general idea of No Plan is 
that: Offer/Answer is used for configuring media and RTP stacks and 
additional signalling is not the browser's concern.

Having extra m= lines, particularly when using BUNDLE, is in many ways 
just extra signalling. If you'd like for that signalling to be in SDP, I 
don't see any problem with it. However it would be best for this extra 
layer of SDP signalling to appear at either the application layer or in 
a signalling gateway (that is going to be there anyway).

Does this make sense?

Emil

-- 
https://jitsi.org

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 31 May 2013 14:35:35 +0200

> I do not understand why modern communication users accept to see a
> chat state indication of "composing" instead of really seeing what text is
> composed. With real-time text you get rid of the frustration that
> "composing" creates.
> Now, this was not meant to be a repetition of the motivations for real-time
> text, but a discussion on interoperability requirements and sdp handling.

That can be implemented on top of DataChannel anyway, I see no need
for mandating it as a new RTP media stream negotiated via SDP.

> agreed that rtcweb must not be the continuation of building silos. Users of
> different providers and servers will want to have communication with each
> other, and that creates a need for explicit standards for session
> establishment and media stream establishment.

Really? I don't think so.

I will share a secret: the famous SIP trapezoid will never take place
in WebRTC (it does not exist neither in SIP anyway).

Can you open a user session into Facebook and chat or share content
with a Google+ or Twitter use? for sure NOT. The same for RTC
communication. If you are logged into Facebook, how will you tell your
Facebook WebRTC user interface to "open a multimedia session" with a
Google+ user?

It seems that non-web people still think that Alice will be able to
log into her website www.atlanta.com and initiate an audio/video
"call" with Bob, logged into www.biloxi.com (two separate and
independent websites). That will never occur. This is the WWW, not the
PSTN in which the "media channel" is the communication base between
users of different "providers" (with the extra cool feature of DTMFs).
Not here, not in WWW.

Please, take a look to the current WWW scenario. The same will be true
when WebRTC is widely deployed.

Another secret: Alice and Bob use Skype to communicate one to each
other (when at least one of them is at home), and they both connect
via SIP to the same PBX at work, and when they work in remote places,
there is one or two SBC between them. The SIP trapezoid just exists in
RFC's and our imaginations and will never exist in WebRTC.

Same for WebRTC. I insist: a Facebook user cannot initiate a chat with
a Google+ user, so he won't be able to establish a media session with
him when both websites provide WebRTC capabilities. Really.

>  Real-time text is one of the
> basic media together with audio and video which need to be fully defined for
> such interoperability.

Facebook, Google+, Twitter and any other website use their own custom
mechanisms for providing chat capabilities to *their own* users
*between them*. I don't expect that they will be interested in a
peer-to-peer (user-to-user) realtime text because they want to log the
messages, inspect them, offer you advertisements based on the content
of your "private" chats, etc.

Really, WebRTC is not the new PSTN, and there is no need at all to
waste time thinking about "interoperability" between different WebRTC
islands. In fact there won't be WebRTC islands but Web islands (as
today), and WebRTC will be just a new "feature" provide by those web
islands for their users.

Probably some website (i.e. www.example-A.com) will let you sending an
"invitation URL" to any contact (i.e. via mail) so the receipt of the
invitation will open the URL and will get automatically "logged" or
"authorized" into www.example-A.com for having a multimedia session
with the first user (note that both users will use a WebRTC JavaScript
app provided by the same website www.example-A.com). That's all. But
Alice logged into www.example-A.com won't be able to make a "call" to
Bob logged into www.example-B.com. Saying the opposite goes against
the facts provided by the WWW during long years.

Best regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 31 May 2013 14:33:32 +0000

On May 31, 2013, at 4:51 AM, Emil Ivov <[email-masked]> wrote:

> Having extra m= lines, particularly when using BUNDLE, is in many ways just extra signalling. If you'd like for that signalling to be in SDP, I don't see any problem with it. However it would be best for this extra layer of SDP signalling to appear at either the application layer or in a signalling gateway (that is going to be there anyway).
> 
> Does this make sense?

No. That does no make sense. 

Can you please provide an specific example of what you think the SDP would look like going across the JS API in the browser and then what the SDP at the applications of signaling layer would look like and how this would work with CLUE.

---

From: Emil Ivov <[email-masked]>
Date: Fri, 31 May 2013 20:56:04 +0300

Hey Stefan,

> attached to a PeerConnection.

I believe Paul already commented on this but just to be clear: yes I 
agree that SSRCs would only make sense for tracks that are actually 
going on the network, so the API methods that give access to them would 
have to take this into account.

> MediaStreamTrack level.

I don't think this is any different with "No Plan". Is there a 
particular scenario that you think would not work?

> The application would simply add a MediaStream

Note that No Plan does not suggest that PT's be taken up to the 
application. As for SSRCs, those would just serve as identifiers and 
shouldn't bother developers that don't care about them.

> exchange and need not look into.

I was indeed hoping that we could push FEC and RTX down to the RTP layer 
for the applications that wouldn't want to be bothered. As for the SSRC, 
the point of making them available to applications would be so that they 
could use them so I don't think that putting them into blobs would 
change anything.

> If done that way, "No Plan" seems to me to be quite similar to Plan B,

It definitely has a lot in common with Plan B, and it's all about 
relaxing its constraints so that applications who want to handle 
signalling a bit differently could do so.

Cheers,
Emil

-- 
https://jitsi.org

---

From: Mark Rejhon <[email-masked]>
Date: Fri, 31 May 2013 14:19:40 -0400

> of your "private" chats, etc.

Objection, objection!
They are NOT mutually exclusive.

I have been in contact with Facebook as part of my XEP-0301 authorship
(XMPP real-time text).
See this animated GIF of Facebook real-time text concept:
http://www.realjabber.org/anim/facebook_chat_concept.gif

Go to http://tap.gallaudet.edu/rtt/ for an *WORKING WEB-BASED DEMO* of *GOOGLE
TALK REAL TIME TEXT* a seamless integration of real-time text into Google
Talk.  In fact, you can keep your GMAIL running simultaneously while you
use this RTT-compatible client, and your completed line-by-line messages
are still automatically logged.

Real-time text *CAN* be an add-on to existing line-by-line networks.

Sincerely,
Mark Rejhon

---

From: Emil Ivov <[email-masked]>
Date: Fri, 31 May 2013 21:23:51 +0300

On 31.05.13, 17:33, Cullen Jennings (fluffy) wrote:
>> Having extra m= lines, particularly when using BUNDLE, is in many
>> ways just extra signalling. If you'd like for that signalling to be
>> in SDP, I don't see any problem with it. However it would be best
>> for this extra layer of SDP signalling to appear at either the
>> application layer or in a signalling gateway (that is going to be
>> there anyway).
>>
>> Does this make sense?
>
> Can you please provide an specific example of what you think the SDP
> would look like going across the JS API in the browser and then what
> the SDP at the applications of signaling layer would look like and
> how this would work with CLUE.

Certainly. Could you please post the SDP that you would like to see 
translated in a way that's compatible with "No Plan"?

Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Fri, 31 May 2013 21:27:11 +0300

Hey Cullen,

On 30.05.13, 20:07, Cullen Jennings wrote:
> Interesting draft but it seemed to have more questions about how
> things would wok than answers. Let me try and ask you some specifics
> to help flesh out what this plan is and offer a few comments.
>
> 6) you have some API requirements

Yes, the above seem like an accurate summary.

> which, with the exception of 4
> about exposing the max number of incoming streams that can be
> decoded, I think are pretty much agreed to be put put in W3C API
> already.
> On the topic of #4, it's a big unclear what is really needed
> and ongoing discussion is happening around how do indicate what can
> be received but thats a webrtc issue

Then I suppose this is a good time for us to agree here on what we need 
the API to expose so that the underlying protocols would work.

> This is very close to Plan A.

I'd say it's actually closer to Plan B but Plan-A-style signalling 
should certainly be possible to implement by the app or a signalling 
gateway.

> So I read the whole draft and asked
> myself how is this different than plan A. What parts of this draft
> would not be abel to do if we did Plan A.

The part where one doesn't have to redo (and propagate) an Offer/Answer 
exchange every time a source is added or removed.

> The only real topic I could
> come up with was the port music here is PT only instead of PT + SSRC.
> I'l start a separate thread on that.

This is another difference indeed.

> Let's say browse A wants to say it can send two streams of video and
> here are the parameters for the video codecs for each to the streams.
> What does the SDP that createOffer generates look like?

There's an example in the draft. I assume the "parameters" you mention 
are not in there, so could you please be more specific?

> I see the
> draft says "strongly advises against the use of multiple m= lines for
> a single media type. " but I don't really know what you mean by that.

It means a browser should generate and offer that looks like this:

m=audio
m=video

rather than an offer that looks like this

m=audio
m=video
m=video
m=video

Also if one bundle is not enough to fit all payload types in the two 
media lines, then we split them in two.

> Can you explain what you are actually proposing we do do instead of
> just saying what not to do ?

We create an offer that would describe the media types and the bundle. 
We use that offer to also describe capabilities in terms of maximum 
resolutions, supported header extensions, potentially max-ssrc-s, etc.

It is up to the application how to handle the rest. If it needs to 
transmit additional signalling: let it. If it wants to encode that in 
SDP, great. If it wants to attach it in JSON next to the browser 
generated SDP, that also works.

> The above paragraph is the most important part of my email. Please,
> what is the proposal for what the SDP in the offer looks like.

You started another thread for this, so I'll respond there.

> The idea of exposing a low level API to the media stack and having
> the all proposing to do FEC, RTX, SDP processing ect has been
> discussed many times across the various working groups. It' jokingly
> refereed to as comment 22 at this point.

I appreciate you are trying to turn this into a joke (which I think is a 
pity provide your chairing role in this working group), but abandoning 
SDP really isn't what this is about. You might have noticed text about 
this as early as the abstract:

   This document does not question the use of SDP and the Offer/Answer
   model or the value they have in terms of interoperability with legacy
   or other non-WebRTC devices.

Emil

> It's not that it does not
> have merits, but many people myself included see it as a much longer
> road to get done, a lot more work, and no clear gain. One of the
> other issues is we are trying to make this so you don't have to be a
> telephone expert to use it and that lots of developers can use it.
> I'm not going to try and summarize the low level API augments here
> but if you want to discus it webrtc is the right WG.
>
> I'll note there are many points in the draft that I disagree
> with but
> I'd rather try and sort through what the actually proposal is here
> before addressing any of them.
>
> There is one point I would like to make that is the confusion
> introduced by "legacy endpoint". When I talk about legacy endpoints,
> I am talking about endpoints that use SIP or Jingle and both past
> ones and future endpoints. SIP will continue to evolve  and I expect
> WebRTC to continue being able to negotiate new features. For example,
> if a SIP phone added VP9 and a browser supported VP9, I would expect
> to be able to use it. The legacy refers to an older protocol, SIP,
> and not to the age of the endpoint. We do know that things can't work
> with all deployed endpoints and long ago we made the decision to give
> up on endpoints that don't do ICE. But we do try and have a
> reasonable experience with old and future endpoints.
>
>
>> Based on many of the discussions that we've had here, as well as
>> many others that we've had offlist, it seemed like a good idea to
>> Cheers, Emil
>> -- https://jitsi.org
>> _______________________________________________ rtcweb mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>
>

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 31 May 2013 15:03:11 -0400

> for mandating it as a new RTP media stream negotiated via SDP.

IIUC, Gunnar is expecting that virtually every app that provides real 
time voice communication should also provide RTT. (And this has a habit 
of showing up as a legal mandate.)

Leaving the decision about how to transport RTT to be reinvented by each 
application doesn't seem like a good way to achieve that.

If that is good enough for RTT, then why not voice and video too? Just 
send it over a data channel in any format you like. We don't need to 
standardize how to do it.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 31 May 2013 15:11:20 -0400

On 5/31/13 6:51 AM, Emil Ivov wrote:
> just extra signalling.

You may be able to argue that adding extra m-lines into an existing 
bundle is "just extra signaling". But introducing an additional 5-tuple 
is more substantial. It requires configuring a new RTP stack and media.

	Thanks,
	Paul

> If you'd like for that signalling to be in SDP, I

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 31 May 2013 19:19:29 +0000

On May 31, 2013, at 12:23 PM, Emil Ivov <[email-masked]>
 wrote:

> Certainly. Could you please post the SDP that you would like to see translated in a way that's compatible with "No Plan"?
> 
> Emil

We can start with the SDP in plan A

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 31 May 2013 13:27:46 -0700

On 5/30/2013 10:32 PM, Gunnar Hellstrom wrote:
> chat state indication of "composing" instead of really seeing what 
> text is composed. 

Perhaps because you haven't done user studies of SMS-style 
compose-and-send vs. real-time text.

I suggest you do that, and then you'll understand the several reasons 
why most users (perhaps interestingly, excluding those users who are 
hearing-impaired) prefer the former.

> With real-time text you get rid of the frustration that "composing" 
> creates.

And you add the sender's frustration of not being able to edit and 
rethink their message before sending it, and the expectation on both the 
sender and the receiver that they remain present for the duration of the 
conversation rather than using it as a completely asynchronous messaging 
modality, to reply when convenient. [this is just a subset of what the 
user studies show, but touches a couple of the most common points]

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 31 May 2013 13:30:37 -0700

> of your "private" chats, etc. 

Yes, among other things, text messaging has a completely different set 
of legal requirements (both for public service providers as well as 
within regulated industries such as securities trading) than voice 
communication in many countries, including the US. If real-time-text 
falls into those requirements, it will need to conform to those 
requirements... never mind the things like blocking URLs that point to 
virus downloads.

Matthew Kaufman

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 31 May 2013 17:15:07 -0400

I've been through this conversation before.
There are no winners. Different strokes for different folks.

IMO the texting UI should be as independent as possible of this 
stylistic difference, and the actual protocol. The session establishment 
should sort out the "best" compromise between the desires and 
capabilities of the two ends.

	Thanks,
	Paul

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sat, 1 Jun 2013 05:23:00 +0000

Hej Emil,

> have to take this into account.

Yes, I think we're in agreement.

> particular scenario that you think would not work?

No, it was only that when I read the proposal it was unclear to me if it 
would work this way. Let me put it this way: I like it to work in the 
way that the MediaStream's and MediaStreamTrack's on the sending side 
are reflected at the receiving side sort of automatically (i.e. apps 
should not have to deal with stuff like PTs, SSRCs to make it happen - 
just forward opaque blobs).

> shouldn't bother developers that don't care about them.

I probably misunderstood something here.

> signalling a bit differently could do so.

I have nothing against that!

Cheers,
Stefan

---

From: Emil Ivov <[email-masked]>
Date: Sat, 01 Jun 2013 08:40:04 +0300

> is more substantial. It requires configuring a new RTP stack and media.

Indeed, this would require BUNDLE to work.

Emil

-- 
https://jitsi.org