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

 

> -----Original Message-----
> From: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de
> Sent: 27 January 2011 15:21
> To: pkyzivat@cisco.com; sipcore@ietf.org
> Subject: Re: [sipcore] Draft new version: 
> draft-holmberg-sipcore-proxy-feature
> 
> 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.
[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.)?

John


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