Subject: RE: [Sipping] Concern within sos ID - user addresses reserved

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 12 Feb 2004 17:45:45 -0000

I guess if we did things the way 3GPP treats circuited switched emergency calls, it would be along the lines of caller preferences, with a Request-Disposition header parameter indicating route-emergency or some such like (and a Proxy-Require header as specified in callerprefs). Any Request-URI would then be totally ignored, and we would not need an sos* uri to be defined at all.

My wondering below was as to whether we could define a single sos* uri, and deal with different types of emergency service providers by a URI-parameter attached to the Request-URI.

SIPPING, you are welcome to pull either of these to bits.

regards

Keith

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: 12 February 2004 14:16
> To: Drage, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [Sipping] Concern within sos ID - user addresses reserved
> 
> 
> Interesting. The selection sounds like caller preferences to me. The 
> nice thing about that is that you might be able to use existing 
> techniques to match up services and destinations.
> 
> For example, this could be considered a sip.class value, extending 
> 'home' and 'business', or a new media feature tag, either specific to 
> emergency services or a more generic service identifier. (The latter 
> does invite the fashion emergency and roadside repair 
> services into the 
> same namespace.)
> 
> Drage, Keith (Keith) wrote:
> 
> > With a view of trying to borrow decisions from elsewhere.
> > 
> > In 3GPP when the phone recognises that it is an emergency 
> call, and needs to identify the type of emergency call, then 
> it has access to signal categories with the following names 
> (ref 3GPP TS 22.101):
> > 
> > ------------------------------
> > -	Police
> > -	Ambulance
> > -	Fire Brigade
> > -	Marine Guard
> > -	Mountain Rescue
> > -	Spare, at least [three] different types
> > -----------------------------
> > 
> > which results in a coding accompanying the call 
> establishment of (ref 3GPP TS 24.008 table 10.5.135d)
> > 
> > --------------------------
> > Emergency Service Category Value (octet 3)
> > The meaning of the Emergency Category Value is derived from 
> the following settings (Please see 3GPP TS 22.101 clause 8):
> > Bit 1	Police
> > Bit 2	Ambulance
> > Bit 3	Fire Brigade
> > Bit 4	Marine Guard
> > Bit 5	Mountain Rescue
> > Bits 6,7,8 are spare and set to "0"
> > 
> > Mobile station may set one or more bits to "1"
> > If more than one bit is set to "1", routing to a combined 
> Emergency centre (e.g. ambulance and fire brigade in Japan) 
> is required. If the MSC can not match the received service 
> category to any of the emergency centres, it shall route the 
> call to an operator defined default emergency centre.
> > 
> > If no bit is set to "1", the MSC shall route the Emergency 
> call to an operator defined default emergency centre
> > -------------------------
> > 
> > These terms are at least accepted by multiple SDOs in the 
> international community for transposition into their national 
> standards.
> > 
> > I also note that 3GPP does have the capability of 
> signalling multiple preferences - this left me wondering 
> whether we would be better off trying to follow that, 
> possibly with a single emergency uri, but with the 
> possibility of signalling category as a URI parameter with a 
> list of values. Any thoughts on this?
> > 
> > regards
> > 
> > Keith
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: Andrew Allen [mailto:[email-masked]]
> >>Sent: 11 February 2004 16:57
> >>To: [email-masked]; [email-masked]
> >>Subject: Re: [Sipping] Concern within sos ID - user 
> addresses reserved
> >>
> >>
> >>
> >>
> >>How about sos.medical then since that outlines the type of 
> >>emergency. I agree that rescue may be confused with the others.
> >>
> >>Andrew
> >>--------------------------
> >>Andrew Allen
> >>Manager Standards
> >>Research In Motion Ltd
> >>BlackBerry Mobile  +1 847 809 8636
> >>European Mobile    +358 50 467 5870
> >>http://www.rim.com/
> >>
> >>Sent from my BlackBerry Wireless Handheld
> >>
> >>
> >>-----Original Message-----
> >>From: Michael Hammer <[email-masked]>
> >>To: [email-masked] <[email-masked]>
> >>Sent: Wed Feb 11 10:45:29 2004
> >>Subject: Re: [Sipping] Concern within sos ID - user 
> addresses reserved
> >>
> >>At 03:55 PM 2/10/2004 -0600, James M. Polk wrote:
> >>
> >>>        sos.fire                fire brigade
> >>>        sos.rescue      ambulance (rescue)
> >>>        sos.marine      marine guard
> >>>        sos.police      police (law enforcement)
> >>>        sos.mountain    mountain rescue
> >>
> >>The second sub-address seems vague to me.  Rescue could mean many 
> >>things.  Perhaps, I need to be rescued from a fashion 
> >>emergency. :)  Would 
> >>something like:
> >>
> >>         sos.medic        medical (doctor, nurse, paramedic team)
> >>
> >>be more descriptive?
> >>
> >>Also, with respect to registrations, I could see commercial 
> interests 
> >>wanting to get into the act, such as an sos.fashion that I 
> hinted at 
> >>above.  Is there some guidance necessary to IANA?  Do we 
> >>expect that the 
> >>IETF WGs will act as arbiters for this?
> >>
> >>Second, wrt location information reporting, is there any need for a 
> >>convention for providing a URL to which a receiving ECC can 
> >>SUBSCRIBE to 
> >>get location updates from either the UA or a network element 
> >>that is doing 
> >>triangulation.  I am wondering if something like the 
> following can be 
> >>inserted into the emergency INVITE:
> >>
> >>Call-Info: <sips:[email-masked]> 
> >>;purpose=location
> >>
> >>Mike
> >>
> >>
> >>_______________________________________________
> >>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> >>This list is for NEW development of the application of SIP
> >>Use [email-masked] for questions on current sip
> >>Use [email-masked] for new developments of core SIP
> >>
> >>
> >>_______________________________________________
> >>Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> >>This list is for NEW development of the application of SIP
> >>Use [email-masked] for questions on current sip
> >>Use [email-masked] for new developments of core SIP
> >>
> > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 12 Feb 2004 22:37:47 -0500

Drage, Keith (Keith) wrote:

> I guess if we did things the way 3GPP treats circuited switched
> emergency calls, it would be along the lines of caller preferences,
> with a Request-Disposition header parameter indicating
> route-emergency or some such like (and a Proxy-Require header as
> specified in callerprefs). 

Request disposition is purposefully non-extensible, so that is not the 
place. This sounds like a routing problem to me, in which case the 
traditional Accept-Contact is the right place. The r-uri would remain 
plain old sos.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Feb 2004 22:57:52 -0500

> traditional Accept-Contact is the right place. The r-uri would remain 

That's what I had in mind. Question is whether there should be a generic 
new 'sip.service' parameter, a more specific emergency-service parameter 
or whether this should be folded as additional values into 'class'. My 
inclination would be the first, with a hiearchical scheme. I'm not sure 
whether there are other services, beyond emergency services, that would 
or should use this.