SIP Extensions and Service Creation

Transcription

1 Some SIP Extensions SIP Extensions and Service Creation!! Reliable provisional responses!! Session Timers!! Early Media!! Adjusting session state: UPDATE!! INFO method!! REFERing peers to third parties!! SIP for subscriptions and event notifications!! Instant messaging!! SIP for presence!!...!! Addressed later today where appropriate Jörg Ott Jörg Ott 3 Basic Extension Mechanisms!! Proxies forward unknown methods and headers!! UAS ignore unknown headers, reject methods!! Feature negotiation!! Headers: Require, Proxy-Require, Supported!! Option tags for feature naming (see below)!! Error responses:!! 405 Method not allowed!! 420 Unsupported!! 421 Extension Required!! Option tags!! Identified by unique token!! Prefix reverse domain name of creator!! IANA: implicit prefix org.ietf. UAC and UAS/proxy must agree on common feature subset 2010 Jörg Ott 2 Reliable Provisional Responses!! Some systems (signaling gatewats, ACDs), but also SIP protocol interactions may depend on provisional responses!! 180 Ringing!! 183 Session Progress! need optional reliability!! Option tag 100rel:!! End-to-end reliability of provisional responses > 100!! Retain order of reliable responses!! Implementation:!! Windowing: RSeq/RAck headers!! Explicit acknowledge: PR request 2010 Jörg Ott 4

2 Use of PR!! Insert RSeq:-header with random integer value!! new responses must increment RSeq: by 1!! Retransmit with exponential backoff!! No subsequent reliable provisional responses until first PR!! enables re-ordering at receiver side!! PR request!! RAck: contains RSeq: and CSeq: values to acknowledge!! May contain body with additional information 2010 Jörg Ott 5 Session Timers!! No keep-alive mechanism for SIP calls!! Proxies may preserve outdated state information!! Close dynamically created holes in firewalls!! Need timeout-mechanism to perform cleanup!! SIP Extension for Session timers!! Option tag timer!! Negotiation mechanism for expiry time and refresh responsibility!! Session-Expires: duration and role!! 422 response with Min-SE: lower bound for expiry interval!! Responsible UA s re- before timer expires!! Session is terminated if no re-/update arrives in time!! Responsible UA s BYE!! Proxies silently drop state information 2010 Jörg Ott 7 Example Call Flow: PR A A starts ing a reliable 182 response PR for previous 182 response arrived, transmit OK response 182 Queued RSeq: CSeq: 8972 PR sip: RAck: CSeq: 8988 PR CSeq: 8988 PR B receives 1xx with RSeq:-header B s PR B stops PR retransmissions 2010 Jörg Ott 6 B Supported: timer Session-Expires: 120 Session-Expires: 120 ;refresher=uac Media data Supported: timer Session-Expires: 120 ;refresher=uac Example: Keep-alive!! Caller indicates support of session timers in!! Propose initial timer value!! Called UA supports timers, accepts proposed value, asks the caller to refresh!! Setup complete, media streams are established!! After n/2 timer calling party s re-!! Call continues after and 2010 Jörg Ott 8

3 A Example: Interval Negotiation Supported: timer Session-Expires: Session Timer Too Small Min-SE: 30 Supported: timer Session-Expires: 40 Min-SE: 30 Proxy Supported: timer Session-Expires: 40 Min-SE: 30 Session-Expires: 30 ;refresher=uas Session-Expires: 30 ;refresher=uas Min-SE: 30 Min-SE: 30 B SIP Preconditions (RFC 3312)!! SDP extension handles negotiation of QoS parameters!! SDP attributes cribe to be met!! Current status (:) vs. ired status (:)!! Either party may request confirmation on ent state (conf:) 'a=:' type status direction 'a=:' type status strength direction 'a=conf:' type status direction!! Offer/answer to create common view on both UAs state!! Typically, UPDATE, PR!! Option tag precondition!! New response code 580 Precondition Failure!! Mark failed and unknown in SDP answer 2010 Jörg Ott Jörg Ott 11 Quality of Service!! Best-effort quality potentially too poor for IP telephony! need support for resource reservation in SIP!! Some applications need multi-phase call-setup!! Resource reservations to assure certain QoS!! Establish particular security relationships!! Extend security services to media channels!! Avoid fraud and theft-of-service! Establish call only if are met!! No charge for defect calls!! No inconsistent state of involved endpoints (alert user only if resource reservation succeeded, )!! Fallback options: e.g. use codecs with lower bandwith 2010 Jörg Ott 10 QoS Parameter Negotiation (Overview) # " # " # " 183 Session Progress confirmation request PR (PR) Resource reservation UPDATE (UPDATE) 180 Ringing # " Acknowledge answer 2010 Jörg Ott 12 #!# #!# Caller s state cription Update ired state. Need caller to reserve in direction " confirmation request Independent reservations made Confirmation from caller after successful resource reservation Callee signals successful reservation. User is being alerted.

4 Example Negotiation of QoS Parameters Confirmation request v=0 o=jo IN IP4 ruin.inf s=sip call t=0 0 c=in IP m=audio RTP/AVP a=rtpmap:98 L8/8000 a=rtpmap:99 L16/8000 a=:qos e2e none a=:qos mandatory e2e m=video RTP/AVP 31 a=rtpmap:31 H261/90000 a=:qos local a=:qos remote none a=:qos optional local a=:qos optional remote Confirmation response v=0 o=cabo IN IP4 dmn.inf s=sip call t=0 0 c=in IP m=audio RTP/AVP a=rtpmap:98 L8/8000 a=rtpmap:99 L16/8000 a=:qos e2e none a=:qos mandatory e2e a=conf:qos e2e m=video RTP/AVP 31 a=rtpmap:31 H261/90000 a=:qos local none a=:qos remote a=:qos failure local a=:qos optional remote confirmation request 183 Session Progress PR (PR) Resource reservation 580 Precondition Failure Failed Reservation! contains with confirmation request! Indicate support for reliable provisional responses! Turn off local user alerting! No reservation results! Reliable provisional response must be acknowledged! Callee s resource reservation fails! Send error response to caller! Failed call setup complete 2010 Jörg Ott Jörg Ott Session Progress confirmation request PR (PR) Successful Reservation! indicates support for reliable provisional responses! Turn off local user alerting! Choose appropriate subset of offered by er! Include confirmation request! Reliable provisional response must be acknowledged Other Preconditions!! Security ( sec )!! Users do not want to unprotected RTP over the wire!! Negotiate a (set of) crypto algorithm(s) for the media streams and exchange keying material (e.g., using MIKEY)!! DO NOT ring the phone before the security association is established and data can be encrypted and decrypted!! Precondition helps to avoid clipping (if one party answers the phone too quickly) Resource reservation UPDATE (UPDATE) 180 Ringing! Initiator of confirmation request awaits UPDATE message or CANCEL! Continue call setup!! Connectivity ( conn )!! Endpoints want to ensure mutual reachability for media streams!! UDP packets!! DO NOT ring the phone before ICE connectivity checks have passed!! TCP / SCTP connection establishment!! DO NOT ring the phone before 2010 Jörg Ott Jörg Ott 16

5 Event Notifications!! Need for flexible event notification!! Enable presence information!! Better support for mobile SIP applications!! Feedback about progress of other calls, conference state, etc.!! method, Event:-header!! Event subscription!!, Event:!! Events may be call-related or third-party generated!! Security issues: Sensitive Events!! Privacy!! Authentication!! Used for personal presence applications!! Used with PUBLISH method to update presence state!! Augmented by MESSAGE method for Instant Messaging 2010 Jörg Ott 17!! used to registered interest in a piece of state!! Event: identifies the state information to be retrieved!! 489 Bad Event!! Syntax reflects package concept: package ( '.' template )* $ e.g. Event: presence.winfo!! Allow-Events: used to indicate which event packages are supported!! Expires: how long to subscribe!! Subscriptions are soft-state; need to be refreshed periodically!! May be shortened or lenthened by server!! Expires: 0!! Poll the state information once; do not estabilish a subscription!! Terminate a subscription!! Body may indicate ired notification policy (filters)!! Each triggers at least one!! May contain no (useful) information if access not yet authorized 2010 Jörg Ott 19 Event Concept!! Piece of state information S!! Identified by some name ( package )!! SIP entities interested in S!! Query for the ent state!! polling!! Be notified about changes to S!!!! Subscriptions may be created implicitly!! By means of other (SIP or non-sip) protocol activity!! Information about S carried in message body!!!! Formats to be defined specific to S!! Protection of S!! Keep control of who gains access, who has access; for how long State State State State Notifier Subscriber 2010 Jörg Ott 18 Response!! Responses!! : Everything s fine: event understood, client authorized, etc.!! : Request received, working on a final result!! 401, 603, if applicable!! Acceptance or rejection to be reported in!! Accepting / rejecting subscription requests!! Automated e.g. through configured black / white list!! Ask user if acceptance cannot be determined automatically!! Watcher Info package used to monitor one s own presence!! Generates notifications for subscription requests!! User then needs to authorize subscription!! Through arbitrary means (e.g. web page) 2010 Jörg Ott 20

6 !! carries state information in message body!! Format depending on Accept: header from!! Full state vs. state deltas!! Subscription-State: active/pending/terminated!! indicates acceptance or rejection of!! If no immediate response could be supplied!! may be used to terminate subscriptions!! Initiated by the notifier!! Inclu reason code parameter!! may be sent without!! Implicit subscription!! Response to!! vs. 481 Subscription does not exist!! Notification rate: risk of network congestion!! Event throttling to be specified in event packages " Example: Unsuccessful Expires: 3600 Accept: text/plain 489 Bad Event Allow-Events: zompel? " Expires: 3600 Accept: text/plain Expires: 0 Subscr-State: terminated ;reason=rejected 2010 Jörg Ott Jörg Ott 23 Example: Successful Expires: 3600 Accept: text/plain! Expires: 1800 Expires: 1799 Subscr-State: active?! Expires: 3600 Accept: text/plain Expires: 1799 Subscr-State: active 2010 Jörg Ott 22 Sample Use of Watcher Information Watcher (w) Server Presentity (p) sip:p@tzi.de SIP/2.0 From: sip:p@tzi.de;tag=42 To: sip:p@tzi.de... Event: presence.winfo SUBSRIBE sip:p@tzi.de Subscr-State: Pending Subsc-State: Accepted Authorization sip:p@tzi.de SIP/2.0 From: sip:p@tzi.de;tag=99 To: sip:p@tzi.de;tag=42... Event: presence.winfo Subscription-State: active Content-Type: application/watcherinfo+xml <?xml version="1.0"?> <watcherinfo xmlns="..." version="0" state="full"> <watcherlist resource="sip:p@tzi.org" package="presence"> <watcher id="32" event="subscribe" status="pending"> sip:w@example.com </watcher> </watcherlist> </watcherinfo> 2010 Jörg Ott 24

7 REFER Method!! Original motivation: Call Transfer!! General idea: make a SIP entity contact a third party!! Originator s REFER method to peer!! indicates refer target in Refer-To: header!! Referred party accepts or declines immediately!! or uses some SIP error code!! Accepting establishes an implicit subscription on the new dialog!! Contacts refer target in an entirely independent dialog!! May indicate who caused the call in Referred-By: header!! New sequence, unrelated!! Reports outcome of new call to originator!! (exactly) one!! Message body contains SIP message fragments from new call, e.g.!! 486 Busy Here 503 Service unavailable 2010 Jörg Ott 25 Securing REFER!! Refer Target C receives a request from Referee B!! May be indistinguishable from any other request from B!! May be acceptable to C only if A is known as initiator!! Need to provide authentication information in the request!! Referred-By: header provi first indication!! But may be faked by B!! Extension to securely pass information from A to C!! Include signed S/MIME message body in REFER request!! Content-ID: <sip-message-id>!! To be copied by Referee into target request!! Optional cid= parameter of Referred-By: points to signed body!! Referred-By: <sip:referrer@example.com>;cid="<sip-message-id>!! Refer target may refuse message without proper Referred-By!! 429 Provide Referrer Identity 2010 Jörg Ott 27 Simple REFER Example Referrer A Referee B Active SIP dialog REFER Refer-To: sip:c@tzi.org Content-Type: message/sipfrag Content-Length: 6 BYE sip:c@tzi.org 100 Trying Refer target C 2010 Jörg Ott 26 Protected REFER Example Referrer A Referee B Active SIP dialog REFER Refer-To: sip:c@tzi.org Referred-By: <a@tzi.org> ;cid=mytoken@tzi.org Referred-By: <a@tzi.org> ;cid=mytoken@tzi.org Content-Type: message/sipfrag Content-ID: <mytoken@tzi.org> Content-Disposition: aib Date: Mon, 20 Dec :45:02 GMT Refer-To: <sip:c@tzi.org> Referred-By: <sip:a@tzi.org> [] ;cid=mytoken@tzi.org BYE signed 100 Trying Refer target C 2010 Jörg Ott 28

8 Enforcing Protected REFER Example Referrer A Referee B Active SIP dialog REFER Refer-To: sip:c@tzi.org [429] 429 Provide Identity Refer target C REFER Refer-To: sip:c@tzi.org Referred-By: <a@tzi.org> ;cid=mytoken@tzi.org Referred-By: <a@tzi.org> ;cid=mytoken@tzi.org [200] 2010 Jörg Ott 29 Caller Preferences / Callee Capabilities!! Caller may provide preferences for request routing!! URI-based Proxy or redirect!! Refuse particular URIs!! Forking!! Recursive search!! Parallel or sequential search!! SIP Extensions (RFC 3840, 3841)!! Request-Disposition: Request routing in SIP servers!! Accept-Contact: Change address ordering!! Parameters require and explicit to control matching process!! Reject-Contact: Reject particular URIs!! Implied predicates from SIP method, events!! Additional parameters for Contact: headers in REGISTER!! Modelled following RFC 2533, but with simplified syntax 2010 Jörg Ott 31 REFER Semantics?!! Refer-To: supports arbitrary parameters!! Including method= and response=!! May populate various headers of a message!! Enables remote control of a SIP UA!! Default: method for SIP URIs!! Inside dialog: call transfer!! Outside dialog: click-to-dial!! But generalized command: Apply <method> to <URI>!! Force a remote UA to do something!! In principle broad applicability but only little semantics defined!! Fetch the content at Subscribe to a certain resource!! Send a certain reply to a request!! Handle with care 2010 Jörg Ott 30 DB Preference/Capability Matching Registrar 3 SELECT * FROM WHERE REGISTER sip:acm.org SIP/2.0 To: <sip:jo@acm.org> Contact: ;audio ;mobility= mobile ;methods=,message, " Contact: <sip:jo@ > ;audio;video ;mobility= fixed sip:jo@ sip:jo@acm.org SIP/2.0 Reject-Contact: * ;mobility= mobile ;media=!audio Request-Disposition: proxy, parallel 2010 Jörg Ott 32

9 Call Control REFER SUBSCR. SIP Service Creation Model PUBLISH UDP IMPP Telephony 3G MESSAGE INFO PR UPDATE SIP Core Protocol IP/IP Multicast SIP Extensions TCP, SCTP, TLS 2010 Jörg Ott 33 Overlap Sess Timer Privacy SIP-based Services SIP Call Processing Language (CPL)!! Server provi information about incoming message!! Destination!! Originator!! Caller preferences!! Contents of several important header fields!! Media cription!! Security parameters!!!! CPL scripts can specify several actions to take!! Reject, redirect or proxy incoming message!! Set timeout values for actions!! Context-dependent choice of different actions!! Perform location lookups!! 2010 Jörg Ott 35 SIP Service Creation Example CPL Script!! Extensions to SIP!! Methods, headers, protocol handling (as just discussed for some examples) Proxy to !! Usages of SIP!! Combining existing methods, headers, etc. to create a service!! E.g., SIP for telephony, presence, instant messaging!! Tuning behavior of SIP entities!! Based upon information available from SIP!! Causing effects through SIP mechanisms!! Accessible by means of APIs: in UAs, proxies, and B2BUAs!! E.g., user location call addr-switch tination busy busy no answer Proxy to !! Interaction with application servers!! Stimulus signaling without semantic extensions to SIP!! E.g., using RTP or other protocols to carry signaling Proxy to Voic @ Jörg Ott Jörg Ott 36

10 <?xml version= 1.0?> <cpl> <subaction id= vm > <location url= > <proxy /> </location> </subaction> <incoming> <address-switch field= tination subfield= host > <address subdomain-of= tzi.org > <location url= tel: > <proxy timeout= 10 > <busy> <sub ref= vm /> </busy> <noanswer> <location url= tel: > [ ] </noanswer> </proxy> </location> </address> </address-switch> </incoming> </cpl> UAC Adaptation of CGI for HTTP Proxy SIP CGI!! Fork script on incoming messages!! Pass message on STDIN!! Provide additional information in environment vars!! Process commands from script s STDOUT!! Message forwarding!! Create new messages!! Add/delete message headers!! Use cookies to preserve state information Proxy CGI Script UAC Script is invoked for subsequent messages of same transaction only if explicitly requested Jörg Ott Jörg Ott 39 Service Creation!! Flexible processing of SIP messages in proxies!! Rapid development of supplementary services!! Pass incoming requests to external script for processing! SIP Common Gateway Interface (CGI)!! Adaptation of HTTP CGI!! Support SIP s idiosyncrasies:!! Transport protocols UDP, TCP!! Central role of proxy servers!! Persistent transaction state!! Registrations!! Request forking, recursive search, timeouts!! 2010 Jörg Ott 38 SIP Service APIs!! SIP Servlets!! Standardized model and API for Java-based service creation!! Built similar to HTTP servlets!! Vendor-specific APIs!! for SIP servers!! SDKs for SIP UAs!! JAIN (Java APIs for Intelligent Networks)!! Java-based API for service creation across SIP and circuit-switched networks!! JAIN SIP!! JAIN SIP Lite!! SIP Servlets (see above)!! Parlay!! Joint effort of ETSI, 3GPP, and Parlay group 2010 Jörg Ott 40

11 Interaction with Application Services!! Traditional PSTN / PBX services often controlled via DTMF!! Stimulus signaling with semantics defined by the application!! Assumes that signaling and media paths are identical!! Does not apply to SIP!! Media and signaling may go separate paths!! Application servers may be on neither path!! SIP defines Application Interaction Framework!! Taxonomy for interactions between users and application servers!! Focus on stimulus-based signaling!! KPML Approach!! to register interest of an application server in user input!! XML document to cribe input expected from user!! to inform server about key events 2010 Jörg Ott 41 Signaling-based Application Servers (IMS-inspired) AS 1 AS 2 AS 3 P1 Service Filters Service Filters P2 UA 1 UA Jörg Ott 42