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

Hi, 

>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.

According to RFC 5626, a UAC can use the "ob" parameter - present in the Path header field - at least to determine whether to send keep-alives.

But, in networks that support emergency calls, and the feature tag, the registrar can also use the Path to generate the Service-Route (which means the feature tag will be inserted in the Service-Route).

>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.

You asked for non-IMS use-cases, and you got a proposal. I think we could do some brainstorming around it, and see whether it could result in something useful.

Regards,

Christer

> 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
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 