Re: [rtcweb] No Plan

[Iñaki Baz Castillo <[e-mail]>]

2013/5/30 Gunnar Hellstrom <[e-mail]>:
> 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.

> 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?)


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
<[e-mail]>