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

2. 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 2005
IETF63 - ECRIT

3. SIP request 9-1-1 INVITE sip:fire@paris.ia.state.us
To: urn:service:sos
123 Main, Paris, IA
INVITE urn:service:sos
To: urn:service:sos
123 Main, Paris, IA
August 2005
IETF63 - ECRIT

4. 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 2005
IETF63 - ECRIT

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

6. 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 2005
IETF63 - ECRIT

7. 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 2005
IETF63 - ECRIT

8. Alternatives lump:sos or lump:sos@example.com tel:911;context=+1
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
August 2005
IETF63 - ECRIT