Subject: [Sipping] draft-ietf-sipping-sos vs. draft-schulzrinne-sipping-service

From: [email-masked]
Date: Mon, 3 Oct 2005 14:55:52 +0300

Hi,

I noticed that draft-sipping-sos, which proposed a universal emergency URI, sip:sos@domain, has expired a long time ago. Does this mean that this proposal has been abandoned in SIPPING? On the other hand I noticed that there is a new draft-schulzrinne-sipping-service, which proposes a bit more generic URN based method, i.e. the emergency calls would be identified as urn:service:sos. Is this considered as a replacement to the old sos-URI? 

I believe we need something to identify emergency calls (globally) and I would be happy to go ahead with the URN based model. But I since the URN mechanism is not SIP-specific, I'm not sure where it belongs in the IETF currently, e.g. is SIPPING WG taking it.

Regards,
	Markus 

_______________________________________________
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: Mon, 03 Oct 2005 09:32:18 -0400

Markus,

I was hoping this topic would get a bit more discussion than it has, so 
thanks for raising the issue.

As you correctly surmise, the 'service' draft is meant as the more 
generalized version, also solving some of the problems that the tel URI 
has in similar situations and avoiding the overloading of the user part 
of the SIP URI. The sos@ also has the disadvantage that either routing 
is "late" (at the 'home' proxy) or deviates from normal resolution 
practices (if done at the outbound proxy).

While motivated by 911/112 emergency services, the URN mechanism also 
works for the other N11 services (in the US), e.g., directory 
assistance, repair or general government services (311 in some cities). 
While I have not specified this to avoid getting too side-tracked, one 
can also imagine extending this to other commercial services, e.g., 
taxi, pizza or towing.

The disadvantage of the new scheme is deployability: Like tel URIs, the 
outbound proxy needs to understand the scheme.

Also, while the sos@ mechanism doesn't require any special client 
support, the service URN obviously does.

I obviously agree with you that we need something - and preferably 
before we replicate, on a global scale, the mess of the current 
emergency call identifier system.

Given that the IPTEL group is defunct, the number of venues to discuss 
this in is probably limited to SIPPING and ECRIT.

I would certainly value feedback, both on content and strategy.

Henning

[email-masked] wrote:
> Hi,
> 
> I noticed that draft-sipping-sos, which proposed a universal
> emergency URI, sip:sos@domain, has expired a long time ago. Does this
> mean that this proposal has been abandoned in SIPPING? On the other
> hand I noticed that there is a new draft-schulzrinne-sipping-service,
> which proposes a bit more generic URN based method, i.e. the
> emergency calls would be identified as urn:service:sos. Is this
> considered as a replacement to the old sos-URI?
> 
> I believe we need something to identify emergency calls (globally)
> and I would be happy to go ahead with the URN based model. But I
> since the URN mechanism is not SIP-specific, I'm not sure where it
> belongs in the IETF currently, e.g. is SIPPING WG taking it.
> 
> Regards, Markus

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Oct 2005 10:44:20 -0400

Henning,

> can also imagine extending this to other commercial services, e.g., 

I agree that it seems quite applicable to all of these.

There is one somewhat more problematic case that I would be interested 
in getting your opinion on: "operator" services.

These seem to fall into at least two categories:

- simply requesting an operator, e.g. by dialing "0" or "00".

   The service URN approach seems perfectly suitable for this

- dialing "0nnn..." to request operator assistance with the
   placing of a call to a specified target. In this case, either
   the operator assistance can be viewed as a modifier or route to a
   specified target, or else it may be viewed that the operator
   is the target and some extra digits are a parameter to the
   operator.

   The applicability of the service URN to this case seems less clear.
   Also, the generalization of the concept to environments where
   addresses are not represented as numbers is also unclear.

   I have a couple of candidate ways to represent this as a TEL
   URI, but of course those are rooted in numeric identifiers.

Do you have any thoughts on this?

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 03 Oct 2005 11:52:17 -0400

Paul:

The basic problem for service identifiers is that they essentially 
involve a mapping of

(identifier) + (context)

to a "real" (SIP) URI, where context can be "outbound proxy used", 
"geographic location of caller" or "service provider I'm with", among 
others.

I'm not quite sure that the second issue you raise is actually a service 
identifier as such. It seems much more closely related to the caller 
preferences work or possibly the service routing work, as it relates how 
a call is handled or routed, namely via an operator service. If that 
approach does work, it would obviously also work for non-numeric 
identifiers. Your "operator call for number N" does not seem to me 
fundamentally different from "call via a translation service" or "call 
via a telephone relay operator".

Henning

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Oct 2005 12:35:38 -0400

> via a telephone relay operator".

I think that depends on how you interpret and extrapolate the service.

If you view it as "apply operator services to the call to this target" 
then I agree with you.

But if you view it as "call the operator and provide this hint about an 
intended target, that might be ignored, adjusted, or reinterpretted by 
the operator", then that model doesn't fit.

I don't actually know which is the proper interpretation.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 03 Oct 2005 12:43:07 -0400

If it is a hint, then maybe this fit better into an informational header 
rather than trying to squeeze this into an identifier. The third model 
is that of a "domain of interpretation", which is the user identifier. 
In other words,

[email-masked]

allows local interpretation by a well-defined party.

As interesting as this problem is, I'd also appreciate comments on the 
problems the draft *is* trying to solve :-)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Oct 2005 01:46:25 -0400

inline.

Paul Kyzivat wrote:

>> I'm not quite sure that the second issue you raise is actually a 
>> service identifier as such. It seems much more closely related to the 
>> caller preferences work or possibly the service routing work, as it 
>> relates how a call is handled or routed, namely via an operator 
>> service. If that approach does work, it would obviously also work for 
>> non-numeric identifiers. Your "operator call for number N" does not 
>> seem to me fundamentally different from "call via a translation 
>> service" or "call via a telephone relay operator".
> 
> 

The call is definitely TO the operator though, in that the operator 
answers the call, not the target.

As such, I think it fits quite well into the urn framework henning has 
proposed, something like this:

urn:service:operator:<number>

where <number> is the number that is desired to be reached.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Oct 2005 08:57:49 -0400

Changing the subject to avoid continued hijacking of Henning's thread.

Comment inline.

	Paul

Jonathan Rosenberg wrote:
>> But if you view it as "call the operator and provide this hint about 
>> an intended target, that might be ignored, adjusted, or reinterpretted 
>> by the operator", then that model doesn't fit.
> 
> 

What if I want operator service (e.g. a collect call) on a call to 
sip:[email-masked]? Do I then use:

    urn:service:operator:sip:[email-masked] ???

It might be more consistent with other usage to do:

    urn:service:operator?sip:[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 06 Oct 2005 11:22:45 -0400

Maybe there's a generalization here. The service urn already supports 
sub-services, so service parameters, such as the number desired, aren't 
too far off. However, I think there needs to be a reasonably clear 
expectation which are meant strictly for the final recipient of the 
service, and should, for example, be copied to the SIP URI, and which 
are used to select the real URI corresponding to the service.