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

["Elwell, John" <[e-mail]>]

> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]] 
> Sent: 31 January 2011 10:41
> To: Elwell, John; [e-mail]; [e-mail]; 
> [e-mail]
> Subject: RE: [sipcore] Draft new version: 
> draft-holmberg-sipcore-proxy-feature
> 
> 
> Hi, 
> 
> >>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.
> >[JRE] This doesn't make sense to me. How can a single 
> feature tag indicating support for emergency tell me how to 
> code the URI (with 110@domain or 999@domain or sos@domain, etc.)?
> 
> Feature tags can have values, which could be used to indicate 
> that. For example: emergency="999@domain".
> 
> However, I am not sure that the use-case was about informing 
> what the emergency number is, but to indicate that the proxy 
> can handle emergency calls - whatever the URI to indicate 
> emergency calls within that network is.
[JRE] I too am not sure we should bend the feature tag mechanism to use it for informing a UA what dial string to use. I guess the point behind my comment was why are we talking about dial strings here, why not the SOS URN? Also, are we talking about the case where the UA has identified a call as an emergency call but has not resolved the SOS URN (by doing a LOST look-up and populating the Route header field)? Or the case where the UA does not have access to location information? If the UA has performed all these functions, I don't see what special support is needed from the proxy. In other words, to understand Roland's use case, I really need more information about what function the proxy is expected to perform and how the UA knows that it needs the proxy to do this.

John

> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> > 
> > 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: [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
>