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

Harald Alvestrand <harald@alvestrand.no> Thu, 20 October 2011 14:44 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D33021F8B75 for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 07:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.425
X-Spam-Level:
X-Spam-Status: No, score=-110.425 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9sO1qDOk7t5 for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 07:44:46 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 769B421F8A7E for <rtcweb@ietf.org>; Thu, 20 Oct 2011 07:44:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C560B39E0F3; Thu, 20 Oct 2011 16:44:45 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l92CZqOMXfQ; Thu, 20 Oct 2011 16:44:43 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 26CAF39E072; Thu, 20 Oct 2011 16:44:43 +0200 (CEST)
Message-ID: <4EA033DA.5030409@alvestrand.no>
Date: Thu, 20 Oct 2011 16:44:42 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>
References: <CA+9kkMBQDne_p7LmH_e38NQWqjjNh0jKjuLMZrtNh10db90hYg@mail.gmail.com> <4E9E9794.8000901@alvestrand.no> <4E9FD139.2010406@ericsson.com> <CALiegfkbdXLf2E38i8ELSCsD6JOUJnWMasQuYK13BhzBwji2_Q@mail.gmail.com> <4EA0025E.6080604@alvestrand.no> <CALiegfk3Zicoi+K2BNs=2AVOQ3mLzfNk7+LSWkRxRzd+Sgox0Q@mail.gmail.com>
In-Reply-To: <CALiegfk3Zicoi+K2BNs=2AVOQ3mLzfNk7+LSWkRxRzd+Sgox0Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Friday Agenda: Re: Friday Call details for signaling discussion
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Oct 2011 14:44:47 -0000

On 10/20/11 15:31, Iñaki Baz Castillo wrote:
> 2011/10/20 Harald Alvestrand<harald@alvestrand.no>;:
>> 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".
> Hi Harald, after re-reading this mail from you I've realized that I
> don't fully understand it.
>
> For example, a SIP INVITE has:
>
> 1) Request URI and headers, which contain the identity information,
> the destination of the request, and so. This is what I called
> "JS-Server Information Signaling".
>
> 2) An SDP, which contains media description. This is what I've called
> "JS-Server Media Signaling".
>
> Of course both are carried together (the "JS-Server Information
> Signaling" carries the "JS-Server Media Signaling").
>
> Initially I understood that your "channel-related signalling" is the
> same concept as my "JS-Server Information Signaling" (bullet 1), but
> then you said:
>
>> "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.
> What do you mean with "channel-related signalling"?

"which media is sent on which SSRC on which port".

This is usually sent as part of SDP, but some of Neil Stratford's 
messages have indicated a desire to separate the codec negotiation from 
the channel negotiation, so I thought it was worth pointing out that I 
think they both need to be considered in the group that you called 
"media signaling".

Hope this helps!

                    Harald