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

[Christer Holmberg <[e-mail]>]

Hi, 

>IMO the key differences are:
> 
>- the definition must be publicly available
>- capabilities/feature-tags should be orthogonal
> 
>(And of course it is impossible to verify orthogonality 
>without the definitions being available.)

As far as I know, all 3GPP specifications are publicly available.

Regards,

Christer




> 
> > 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, [e-mail] 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: [e-mail]
> >>>>> [mailto:[e-mail]] Im Auftrag von Paul Kyzivat
> >>>>> Gesendet: Mittwoch, 26. Januar 2011 18:35
> >>>>> An: [e-mail]
> >>>>> Betreff: Re: [sipcore] Draft new version:
> >>>>> draft-holmberg-sipcore-proxy-feature
> >>>>>
> >>>>> inline
> >>>>>
> >>>>> On 1/26/2011 8:07 AM, [e-mail] 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
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>>>
> >>>> _______________________________________________
> >>>> sipcore mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>
> >>>
> >> _______________________________________________
> >> sipcore mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/sipcore
> >>
>