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

From: "Chris Boulton" <[email-masked]>
Date: Fri, 13 Feb 2004 10:15:23 -0000

My inclination would be to have a specific emergency service parameter
to avoid any confusion in usage.  That way we explicitly define
emergency routing without confusion.

Chris.

>-----Original Message-----
>From: Henning Schulzrinne [mailto:[email-masked]]
>Sent: 13 February 2004 03:58
>To: Jonathan Rosenberg
>Cc: Drage, Keith (Keith); [email-masked]
>Subject: Re: [Sipping] Concern within sos ID - user addresses reserved
>
>
>> 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.
>
>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.
>
>_______________________________________________
>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

This message has been scanned for viruses by MailControl - www.mailcontrol.com

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Fri, 13 Feb 2004 08:37:14 -0500

Since SIP generally favors generality, I wonder if the more general 
service description wouldn't be better. I don't see a confusion problem 
if services are defined hierarchically, as in

sos.fire
automobile.towing
restaurant.italian

However, if this causes major delays in discussion, we should stick to 
the simple list of half a dozen sos.* items, I think.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Feb 2004 12:30:41 -0500

I like the callerprefs direction for this. I don't have a particular 
preference for class or a new service feature tag. (But that word 
service continues to cause problems.)

Whatever it is, I think it should work with non-emergency calls, rather 
than just with sos. For instance, often there is a separate number for 
non-emergency calls to the police etc. department. It would be nice to 
be able to use the same "service" callerpref parameter with a generic 
non-emergency public service number, together with the appropriate 
preference setting, to talk in a non-emergency context to the police, 
fire, ems, etc. organization.

	Paul