Service Identification Jonathan Rosenberg Cisco

Agenda Service Identification Architecture draft (draft-rosenberg-sipping-service- identification) Media tag draft and URNs

Service ID Architecture Example Services –IPTV vs. Multimedia –Gaming vs. Voice Chat –Config vs. Pager messaging Uses of Service ID –App Invocation in UA –App Invocation in network –Network QoS Auth –Accounting and Billing –Service Negotiation –Dispatch to Devices Perils of Explicit identifiers –Fraud –Systemic Interop failures –Stifling of innovation Recommendations –Determine service by examining signaling –If you think signaling is not sufficient, its because you are doing implicit signaling for some feature –Caching of service ID is reasonable within a domain

Open Questions on Architecture What about offerless INVITE or 3pcc cases where INVITE doesn’t contain data needed for service ID? –Implicit signaling: put capabilities in INVITE body Need to consider the perils in the context of each specific use of service ID [more of a TODO]

Media Tag Document Callee caps today allows you to register capabilities for different streaming media types –Audio, video, application, message, data –All of the SDP m=values If you do ‘audio’, asking to reach a UA that also does ‘audio’ means you are likely to be able to do audio together –NOT true for ‘application’ – real semantic is in the next layer type Media tag document proposes media feature tag for contact header field that conveys application sub-type supported for streaming media –i.e., “Doom game move protocol”

What’s the Issue? Folks in 3gpp still want to dispatch on the entire service URN, and thought that is what the media feature tag was to contain Folks in 3gpp still want a ‘end-to-end’ service ID used solely for caller pref functionality –Rest of stuff covered by service ID

Current Proposal Move forward with media tag document, but its not a 3gpp dependency Move forward with P-Asserted-Service (for usage for things in sipping-service-id) 3gpp registers a media feature tag for ‘app-ref’ in vendor space and it contains a URN, JUST for dispatch ala RFC3841 Service-ID sipping draft have lots of words on the perils of relying entirely on the service ID for endpoint and proxy dispatch 3gpp utilize caller prefs for proxy dispatch to service ID, but not depend on it as described in sipping service ID draft

Questions Question 1: adopt draft-rosenberg-sipping- service-identification as WG item? Question 2: OK with proposed compromise on dispatch?