Subject: [Ecrit] draft-ietf-ecrit-urn

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 28 Feb 2006 14:26:05 -0000

I understood that the predecessor of this document 

draft-ietf-sipping-sos-02: Emergency Services URI for the Session Initiation Protocol
                       
implicitly carried the implementation of the following requirement from draft-ietf-ecrit-requirements-05, i.e. the presence of the emergency URI was also the emergency marking.

  Id3.  Emergency Marking: Any device in the signaling path that
      recognizes by some means that the signaling is associated with an
      emergency call MUST add a specific emergency indication, if it
      doesn't already exist, to the signaling before forwarding it.
      This marking mechanism must be different than QoS marking.

      Motivation: Marking ensures proper handling as an emergency call
      by downstream elements that may not recognize, for example, a
      local variant of a logical emergency address.

So my question is as to whether the presence of the service type "sos" defined in the new draft is sufficient indication of this marking, or whether ecrit expects some other SIP indication to give this emergency marking.

regards

Keith

Keith Drage
Lucent Technologies
[email-masked]
tel: +44 1793 776249

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Feb 2006 15:31:47 -0500

I'm hoping that the use of the service URN in the SIP To header field is 
sufficient marking. In the sipping-sos case, I had split this into two 
since there was the perception that overloading the user field of the 
URI with lots of different services would be a bad idea. This isn't 
really a problem here.

See http://www.cs.columbia.edu/~hgs/papers/2006/ecrit-arch.ppt for an 
attempt to go through the various cases of who determines that a call is 
an emergency call.

The one issue that arises is if the UA doesn't recognize emergency calls 
and just routes the SIP or tel URI to the proxy. The proxy can't replace 
the To header field, so there's no place to put a service indication. I 
don't know if that is important since the same entity will also have to 
do the mapping and thus insert a PSAP URI in the request URI field. The 
request will then visit that PSAP URI on the next hop. Unless a PSAP 
were to use the same URI for both the general business address and the 
emergency contact address, there is no confusion and no additional 
routing in the "public" SIP server space. (Commingling emergency and 
non-emergency calls on the same SIP URI seems both ill-advised and 
unnecessary.)

Do you think we need the additional marker? (My general inclination is 
to keep things as simple as possible, i.e., to avoid adding SIP header 
fields if we can help it.)

It would be easy to keep the same media feature tag as in sipping-sos:

Accept-Contact: *;sip.service="urn:service:sos.marine"

Opinions?

Henning