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

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 27 January 2011 16:29 UTC

Return-Path: <christer.holmberg@ericsson.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 39F123A6914 for <sipcore@core3.amsl.com>; Thu, 27 Jan 2011 08:29:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.169
X-Spam-Level:
X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4]
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 uPkOnGzJu3+L for <sipcore@core3.amsl.com>; Thu, 27 Jan 2011 08:29:15 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 912103A6903 for <sipcore@ietf.org>; Thu, 27 Jan 2011 08:29:14 -0800 (PST)
X-AuditID: c1b4fb39-b7cfbae000005c8e-5a-4d419e11b18b
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C2.35.23694.11E914D4; Thu, 27 Jan 2011 17:32:17 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 27 Jan 2011 17:32:17 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@cisco.com>, Adam Roach <adam@nostrum.com>
Date: Thu, 27 Jan 2011 17:32:16 +0100
Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature
Thread-Index: Acu+PVjgbKUefA7hTNOIl2RGFu0SjAAAOlNg
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194427B1AA@ESESSCMS0356.eemea.ericsson.se>
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> <4D419056.8080502@nostrum.com> <4D4199EB.5050705@cisco.com>
In-Reply-To: <4D4199EB.5050705@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "sipcore@ietf.org" <sipcore@ietf.org>, "R.Jesske@telekom.de" <R.Jesske@telekom.de>
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 16:29:16 -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.
> 
>Yep. This is a key reason for the importance of use cases. 
>Without this case, would we have had a hint that these 
>features should go into Service-Route?
> 
>Worse, would we be having UAs checking Record-Route in order 
>to make decisions about what will happen when the UA 
>originates requests?
> 
>>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.
> 
>+1

I am not sure what the difference between a feature and a service is...

For example, RFC 5897 seems to call things like call forwarding and call screening as features, while I am sure others would call them services. 

I also see the IMS use-cases in the draft as features provided in IMS networks. Being able to handle emergency calls could also be seen as a feature. 

So, I think it would be a waste of time to argue about whether something is a service or a feature.

Again, the important thing, which I think was also raised many times during the good old days of service-id discussions, is that indicating support of a capability is just that - indicating support of a capability. Others may choose to enable that capability, or they may not. But, in order to execute the capability, one must of course implement the associated feature specification (whether it's an RFC or some other specification).

Regards,

Christer






> 
> > /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.
> 
> This is where it gets dicy. How would the UAC know that 
> something advertising support for "emergency" was compatible 
> with the UAC?
> 
> For instance, does the UAC encode a dial string like "110" 
> into a URI in a way that the "emergency" service will 
> recognize as a dial string, and will the emergency service 
> recognize the emergency dial strings that the user of the 
> device is likely to use?
> 
> One answer to that is that it isn't "emergency" that is 
> reported as a capability, its "IMS-Vx.y-emergency", and there 
> is an external spec somewhere that spells out in detail what 
> behavior that implies.
> 
> But that presents a very difficult model for interoperation.
> 
> >> 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.
> 
> We have a solution for emergency calls - its the sos urn. And 
> IIRC there has been some discussion of ways that a UAC could 
> "test the path" to that URN when it connects to a network so 
> it could inform the user if that will work or not.
> 
> I'm pretty sure ecrit would have something to say about this example.
> 
> >> My intension was to try to point to possible internet applications 
> >> that could use Christers draft.
> 
> Thank you for trying. So far what it has done is act as a 
> counter example.
> 
> 	Thanks,
> 	Paul
> 
> >> 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
> >
> >
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>