August 2005IETF63 - ECRIT1 Service URN draft-schulzrinne-sipping-service-00 Henning Schulzrinne Dept. of Computer Science Columbia University

August 2005IETF63 - ECRIT2 Motivation If resolution done by proxy, needs to identify call needing resolution May pass outbound proxy Also, needed for subsequent proxies Context-dependent resolution –context = location for now ECRIT SIP

August 2005IETF63 - ECRIT3 SIP request INVITE urn:service:sos To: urn:service:sos 123 Main, Paris, IA INVITE To: urn:service:sos 123 Main, Paris, IA 9-1-1

August 2005IETF63 - ECRIT4 Why a URN? Identifies a generic service, not a specific resource Uses mapping protocol: –{identifier, location}  URL(s) Can be used anywhere a URN/URL is allowed, e.g.: –web pages –result returned by mapping protocol –request and To URI in SIP

August 2005IETF63 - ECRIT5 URN structure urn:service:sname.subsname… urn:service:sname reaches any service of type ‘sname’

August 2005IETF63 - ECRIT6 Resolution Each top-level service type can define its own resolution mechanism –might try default protocol if unknown Might be operated by different entities Each sub-service can have its own tree –e.g., sos.fire may have different service boundaries than sos.police

August 2005IETF63 - ECRIT7 Registering services Same issue as for registering services in mapping protocol without URN Define set of initial sos.* services (fire, police, …) Other top-level services possible –e.g., urn:service:repair or urn:service:government.city

August 2005IETF63 - ECRIT8 Alternatives lump:sos or –specific to resolution protocol –does not fit SIP request URI tel:911;context=+1 –hundreds of such identifiers, possibly changing  hard to recognize reliably –how does end device determine context?  backward-compatible  safe: can test home proxy  violates proxy behavior rules: non-domain proxy may attempt mapping  assigns meaning to user part