Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature

Paul Kyzivat <pkyzivat@cisco.com> Wed, 26 January 2011 17:31 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE0E3A6845 for <sipcore@core3.amsl.com>; Wed, 26 Jan 2011 09:31:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.19
X-Spam-Level:
X-Spam-Status: No, score=-110.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, 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 KdQBdbl+g3v1 for <sipcore@core3.amsl.com>; Wed, 26 Jan 2011 09:31:39 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B7DAC3A693B for <sipcore@ietf.org>; Wed, 26 Jan 2011 09:31:39 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AosFAE7qP01AZnwN/2dsb2JhbACWWI4gc6EtjV2NfoVPBIUXhxKDRg
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Jan 2011 17:34:40 +0000
Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0QHYeRQ005918 for <sipcore@ietf.org>; Wed, 26 Jan 2011 17:34:40 GMT
Message-ID: <4D405B30.8020503@cisco.com>
Date: Wed, 26 Jan 2011 12:34:40 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: sipcore@ietf.org
References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> <BDBFB6CE314EDF4CB80404CACAEFF5DE07C6C68C@XCH02DFW.rim.net>, <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com>
In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2011 17:31:40 -0000

inline

On 1/26/2011 8:07 AM, R.Jesske@telekom.de wrote:
> Hi,
> there is an scenario which I would see also within the Internet approach. Perhaps others too.
>
> When you register it would be useful to know if the proper emergency service is served by the provider you are connected to.
> Such an explicit indication would help.
>
>
>     Alice                             P1                     REGISTRAR
>            |                           |                           |
>            |--- REGISTER-------------->|                           |
>            |                           |                           |
>            |                           |--- REGISTER-------------->|
>            |                           |    Path: P1;emergency     |
>            |                           |                           |
>            |                           |                           |
>            |                           |<-- 200 OK ----------------|
>            |                           |    Path: P1;emergency     |
>            |                           |    Service-Route: REG     |
>            |<-- 200 OK ----------------|                           |
>            |    Path: P1;emergency     |                           |
>            |    Service-Route: REG     |                           |
>            |                           |                           |
>
> So that Alice is now sure that an emergency call will get thought and the correct emergency centre will be reached. Which is not even guaranteed in an pure internet environment depended which service provider is chosen.

Why is presence of this parameter on *Path* appropriate? Path has 
nothing to do with new calls originated by Alice. If anything were 
relevant, it would be Service-Route, which Alice would include in Route 
when making a new call.

And, what does the "emergency" capability *mean*? Does it mean that it 
can route requests with urn:sos as the R-URI? Or that it recognizes URIs 
containing dial strings that contain emergency numbers? Or what? (If the 
latter, emergency numbers for what locale(s)?, and encoded in what manner?)

But, why is this needed? Why not just send the request and cope with 
failure to route if/when it happens?

	Thanks,
	Paul