Re: [sipcore] "emergency" via draft-holmberg-sipcore-proxy-feature

[Paul Kyzivat <[e-mail]>]

We are well into speculation for this hypothetical (I think) emergency 
service. I've changed the title to protect the innocent.

To summarize a bit, I guess you are saying:

- a proxy that somehow got brought in while an initial REGISTER message 
was being processed could mark the Path header indicating that it 
supports this "emergency" service.

- the registrar might then take the information from that Path header to 
construct a Service-Route header for the UAC. This could still contain 
that indication of support for the "emergency" service.

- the UAC, upon receiving the response to REGISTER, with a 
Service-Route, *could* analyze the Service-Route for service 
"advertisements", for services such as this emergency service.

- The UAC would then have to analyze those service advertisements for 
ones that are applicable to it.

- in the case of emergency services, the UAC might have to use the value 
of the emergency feature tag to decideeee one or more of the following:
   * this service treats calls addressed to 999@domain as emergencies.
     I had better encode my emergency calls that way. (Even if my user
     usually types 911 for an emergency.)

   * this service treats calls addressed to 999@domain as emergencies.
     My user usually types 911 for emergency, so this service does me
     no good. I should find another way to handle my emergency calls.

   * this service treats calls addressed to 999@domain as emergencies.
     999 is not an emergency number for my user. In fact it is a valid
     non-emergency number. So I had better encode calls to 999 using
     something other that sip:999@domain.

Note, I don't think we want to debate which of these is the "right" 
answer - we are way too far into the hypothetical.

A more interesting thing to take from this is that its about "service 
discovery". That's especially true when used with REGISTER and 
Service-Route. But I think it may also be true with Record-Route for 
dialog establishment - to the extent that there is such a thing as 
services within a dialog. (And I think we do have examples of such things.)

Then draft-holmberg-sipcore-proxy-feature can be seen as a proposed 
mechanism in support of service discovery. As usual, I think we would be 
better off backing up and defining *requirements* for service discovery 
in sip. Certainly there exist service discovery mechanisms for other 
environments. I can see how one might like to query for available 
Music-on-Hold services, conference mixers, etc. (AFAIK this is typically 
done via configuration or proprietary mechanisms right now.)

While I want to discuss it further, I think I could get on board to an 
activity to define how to query for SIP URIs that one could send 
requests to in order to get specific kinds of behavior. This is at a 
higher level than "supports audio", "supports video" kinds of things. 
Its more about "once connected, what's in the audio and video?" E.g. "a 
music-on-hold server near me that plays pop oldies and supports wideband 
audio".

	Thanks,
	Paul

On 1/31/2011 5:40 AM, Christer Holmberg wrote:
>
> 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.
>
> 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
>