Re: [Speermint] AD review: draft-ietf-speermint-architecture-16.txt

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Tue, 11 January 2011 15:35 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: speermint@core3.amsl.com
Delivered-To: speermint@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646163A67A8 for <speermint@core3.amsl.com>; Tue, 11 Jan 2011 07:35:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.607
X-Spam-Level:
X-Spam-Status: No, score=-106.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCl-hAt9+svB for <speermint@core3.amsl.com>; Tue, 11 Jan 2011 07:35:41 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 451A93A6809 for <speermint@ietf.org>; Tue, 11 Jan 2011 07:35:41 -0800 (PST)
X-AuditID: c1b4fb3d-b7b89ae0000036a3-6a-4d2c79552b6d
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 89.B6.13987.5597C2D4; Tue, 11 Jan 2011 16:37:57 +0100 (CET)
Received: from [131.160.126.193] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Tue, 11 Jan 2011 16:37:56 +0100
Message-ID: <4D2C7953.2080903@ericsson.com>
Date: Tue, 11 Jan 2011 17:37:55 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
References: <C9300A7F.1109C%jason_livingood@cable.comcast.com>
In-Reply-To: <C9300A7F.1109C%jason_livingood@cable.comcast.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: "speermint@ietf.org" <speermint@ietf.org>
Subject: Re: [Speermint] AD review: draft-ietf-speermint-architecture-16.txt
X-BeenThere: speermint@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list for the speermint working group <speermint.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/speermint>
List-Post: <mailto:speermint@ietf.org>
List-Help: <mailto:speermint-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jan 2011 15:35:42 -0000

Hi Jason,

thanks. I have just requested an IETF LC for this draft. I will start
shortly.

Cheers,

Gonzalo

On 20/12/2010 11:55 PM, Livingood, Jason wrote:
> The new updated draft (-17) has now been published (notification should
> hit the list shortly).
> 
> BTW, I also updated section 3 to note that parties are equally likely to
> perform the BYE.
> 
> Regards
> Jason
> 
> 
> 
> On 12/16/10 4:05 AM, "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>
> wrote:
> 
>> Hi Jason,
>>
>> thanks for addressing my comments. When you submit the new revision I
>> will take care of starting its IETF LC.
>>
>>>> Section 3. Why is the sending of the BYE (step 5) more likely to be
>>>> performed by the target SSP than by the originating SSP?
>>>
>>> It just seemed logical as we envisioned the call flow between two people
>>> in our head. 
>>>
>>> QUESTION: Would you like a modification there?
>>
>> well, this is a small detail, so I leave it up to you whether or not you
>> want to state that step 5 is likely to be performed by the target SSP or
>> that it can be performed by either of them.
>>
>> I have not seen any statistics about who is more likely to hang up when
>> involved in a call, the callee or the caller. However, in the PSTN, the
>> terminating switch will not send a REL even if the callee hangs up. This
>> allows the callee to hang up, move to another telephone, and pick up
>> there in order to continue the conversation (i.e., the single line
>> extension service). So, at least in the PSTN, you are much more likely
>> to see REL messages in the caller to callee direction.
>>
>> In any case, as I said before, this is a minor point. We have probably
>> already spent to much time on it :o)
>>
>> Thanks,
>>
>> Gonzalo
>