Re: [rtcweb] No Plan

Gunnar Hellstrom <> Thu, 30 May 2013 21:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF82021F9003 for <>; Thu, 30 May 2013 14:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id obQCoMHkhXK0 for <>; Thu, 30 May 2013 14:04:05 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 35E4B21F8FBA for <>; Thu, 30 May 2013 14:04:04 -0700 (PDT)
Received: from (unknown []) by (Halon Mail Gateway) with ESMTP for <>; Thu, 30 May 2013 23:03:56 +0200 (CEST)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPA id 374543A123 for <>; Thu, 30 May 2013 23:03:56 +0200 (CEST)
Message-ID: <>
Date: Thu, 30 May 2013 23:03:58 +0200
From: Gunnar Hellstrom <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] No Plan
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 May 2013 21:04:10 -0000


I find it to be good to have a specified ambition for legacy 
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 

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 

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


On 2013-05-29 20:59, Emil Ivov 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 following "no plan" draft attempts to present one such approach:
> 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