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

Adam Roach <adam@nostrum.com> Thu, 27 January 2011 15:30 UTC

Return-Path: <adam@nostrum.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 AD2683A67B6 for <sipcore@core3.amsl.com>; Thu, 27 Jan 2011 07:30:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.214
X-Spam-Level:
X-Spam-Status: No, score=-102.214 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, SPF_PASS=-0.001, 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 MJSe0KfiOhfZ for <sipcore@core3.amsl.com>; Thu, 27 Jan 2011 07:30:41 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 3C50B3A67B2 for <sipcore@ietf.org>; Thu, 27 Jan 2011 07:30:41 -0800 (PST)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p0RFXgEr036774 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 27 Jan 2011 09:33:43 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <4D419056.8080502@nostrum.com>
Date: Thu, 27 Jan 2011 09:33:42 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: R.Jesske@telekom.de
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> <4D405B30.8020503@cisco.com> <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com>
In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67DFAAEA1E2@HE111648.emea1.cds.t-internal.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: sipcore@ietf.org
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: Thu, 27 Jan 2011 15:30:42 -0000

I think what Paul is saying is that the "emergency" capability would 
have to be in the service route, not the path -- since the Path has 
zero, zilch, nada, nothing to do with calls *made* by the handset.

For my own part, I have some serious concerns about this kind of 
example, as it relies on named services, not capabilities. I suggest you 
very carefully read sections 5 and 6 of RFC5897.

/a

On 1/27/11 9:20 AM, R.Jesske@telekom.de wrote:
> Hi Paul,
> I tried to express a possible use case more in general.
> So "emergency" means that the Call is passed through an Server that assures that a INVITE with a URI addressing a emergency number e.g. 110@domain or 999@domain or it could also use sos@domain will be handled correctly by the AS and will be forwarded to the next emergency centre.
>
> My example was pointing to a use-case that could be happen within the internet, when service provider will support emergency. Und the user will be informed that he is sure that the emergency call will be passed through with the first INVITE. And not waiting for certain responses if the call will not succeed.
>
> My intension was to try to point to possible internet applications that could use Christers draft.
>
> Best Regards
>
> Roland
>
>> -----Ursprüngliche Nachricht-----
>> Von: sipcore-bounces@ietf.org
>> [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat
>> Gesendet: Mittwoch, 26. Januar 2011 18:35
>> An: sipcore@ietf.org
>> Betreff: Re: [sipcore] Draft new version:
>> draft-holmberg-sipcore-proxy-feature
>>
>> 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
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore