Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion

Harald Alvestrand <> Thu, 20 October 2011 11:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 009DC21F8AB8 for <>; Thu, 20 Oct 2011 04:13:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.574
X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bK522gnbw5wx for <>; Thu, 20 Oct 2011 04:13:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AAC5121F8A57 for <>; Thu, 20 Oct 2011 04:13:39 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C44939E0F3 for <>; Thu, 20 Oct 2011 13:13:37 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WQHyjYKZ03nc for <>; Thu, 20 Oct 2011 13:13:35 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTPS id ED00C39E072 for <>; Thu, 20 Oct 2011 13:13:34 +0200 (CEST)
Message-ID: <>
Date: Thu, 20 Oct 2011 13:13:34 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion
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, 20 Oct 2011 11:13:55 -0000

On 10/20/11 12:45, Iñaki Baz Castillo wrote:
> 2011/10/20 Magnus Westerlund<>:
>> The proposed agenda for Firday is as follows:
>> 10 min introduction from each signaling proposal:
>> - draft-jennings-rtcweb-signaling-00 (ROAP) Cullen
>> - draft-partha-rtcweb-signaling-00 (Standard signaling protocol) Partha
>> - ? (No Protocol) ?
>> In the above only clarifying questions may occur.
>> 20 min discussion of each proposal
>> 30 min concluding discussion
>>  From my perspective both draft-beck-rtcweb-alt-ic-00 and
>> draft-ibc-rtcweb-sip-websocket-00 are relevant documents to the
>> discussion as they provides useful proposals on how interconnect and SIP
>> interop respectively can be done. But as they aren't proposals for how
>> the actual signaling solution should work. Thus these are homework but
>> don't get presentation time.
> Hi Magnus. Honestly I don't consider that discussing about
> draft-ibc-rtcweb-sip-websocket-00 should take place. It's just a
> suggestion about a signaling protocol in RTCweb (in this case pure SIP
> over WebSocket). It's not my aim that the WG considers such spec as a
> standard signaling for RTCweb. Well, this is basically the same you
> have said :)
> In the other said, I'd really would like that, before the meeting, all
> the folks could take some time to read:
> and
> This means not wasting time if somebody proposes ROAP as a "default
> signaling protocol" because ROAP is not that and cannot do that (more
> info in the given links). Also, given the general confusion when the
> term "signaling" appears in this WG, I've tryied to clarify its
> meaning(s) in RTCweb context (first link).
> For those who advocate for a "default signaling protocol", I hope
> second link should make them to re-think about what such erroneous
> decision would entail in current and *existing* WWW world.
While I may quibble with Inaki about the terminology he proposes, I 
think I support what he's driving at in the "components" Web page.

In the -overview-02 draft section 7, the term "media negotiations" is 
used for what he calls "media signalling"; it is trying to get at the 
same distinction.

In his category of "info signalling", I would quibble a bit in that I 
see "channel-related signalling" (a term I just invented, describing 
which media is sent on which SSRC on which port) as distinct from 
"identity-related signalling", where the whole question of "who am I 
talking to" is relevant.

I believe "channel-related signalling" needs to be treated together with 
"media signalling".