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

From: [email-masked]
Date: Wed, 12 Oct 2005 19:29:13 +0300

Henning,

In my opinion the IETF should go ahead with both of the drafts. 

The service URN solution is clearly the preferred option in the long run. As you say, it could be used for resolving other location/context dependent contact addresses, so emergency calls would be just a special case.

However, as a short term solution, the sos URI might still be valuable. SIP/VoIP emergency calling is currently an active topic in various places outside IETF, ranging from real deployment discussions to standards organizations such as ETSI and 3GPP. I think it would be good to have a common IETF baseline for all these to refer to, otherwise these will start doing diverging solutions on their own. 

Would there be some harm going forward with the sos URI? To me it seems pretty simple, so it seems hard to do any more "work" on it rather than going for WGLC.

Markus

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: 03 October, 2005 16:32
> To: Isomaki Markus (Nokia-TP/Espoo)
> Cc: [email-masked]
> Subject: Re: draft-ietf-sipping-sos vs.
> draft-schulzrinne-sipping-service
> 
> 
> 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
> 
> 

_______________________________________________
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: Wed, 12 Oct 2005 14:20:49 -0400

I'm happy with your proposal. I agree that the -sos- document is 
unlikely to be much improved by having it gather dust in the I-D 
repository for a few more IETF meetings. I fully agree with your 
assessment that if we don't do something soon, we'll have exactly a 
replica of the 60+ three-digit dialing codes, with usages conflicting 
with non-emergency applications, in the IP world.

I would appreciate chair guidance on this issue.

Henning