Multimedia & Protocols in the Internet - Introduction to SIP

Transcription

1 Information and Communication Networks Multimedia & Protocols in the Internet - Introduction to Siemens AG 2004 Bernard Hammer Siemens AG, München Presentation Outline Basics architecture Syntax Call flows examples Routing Media Negotiation Standardization issues 6/24/2004 page 2

2 : Basic Idea = Session Description Protocol Proposed IETF Standard RFC 3261 Peer-to-peer application layer protocol where endpoints (User Agents) initiate, modify and terminate sessions. uses existing IETF protocols to provide media negotiation (SDP), media transport (RTP), name resolution and mobility (DHCP, DNS), and application encoding (MIME) Users are known by URIs. Text-based encoding based on a HTTP-like request/ response transaction model. Simple extensions by introducing new Methods and Headers` No relation between () signaling path and data stream path. does not provide services, rather primitives that can be used to implement different services in conjunction with other protocols Source: User Agent A Home of B: Proxy / Registrar INVITE Data Stream Target: User Agent B 6/24/2004 page 3 Entities in the Network 3 proxy 2 proxy/ registrar 4 Redirect User database e.g., LDAP Application Servers Non- RTP -T MGC with sign. Gateway RTP Switch H.248 SS7 H.323 H.248 (POTS, ISDN, VoDSL) 1 User Agents RTP IP Backbone RTP 1 User Agents 6/24/2004 page 4

3 Functional Entities 1 User Agent (UA) Intelligent endpoint entity capable of managing its own sessions Paradigm: Intelligence to the edge! Initiates and terminates requests; Always call stateful Is an application, containing both UA client (UAC) and UA server (UAS) 2 Registrar Register current physical address of user agent Provide location information based on the registrations Essential for reachability 3 Proxy Server Intermediate node ( router ) Routes requests towards their target Accesses location and routing information to do its job Proxies can be: stateless, transaction stateful or call stateful Additional jobs: e.g. access control, NAT / Firewall control 4 Redirect Server Find location information and return it to user agent No forwarding of requests, usually search intensive 6/24/2004 page 5 messages is a Client-Server protocol similar to HTTP. Most components can act as client and as server. A transaction is composed of a request of a client to a server and its response. Message parts are: Start Line: conveys message type & protocol version Headers: to convey message attributes and to modify message meaning Body: to describe the session to be initiated or to transport opaque textual or binary data. Body types: SDP, MIME, others) 6/24/2004 page 6

4 Basic Request Methods Method INVITE ACK BYE CANCEL OPTIONS REGISTER INFO Function Invites a user to a call Used to facilitate reliable message exchange for INVITEs Terminates a connection between users or decline a call Terminates a request, or search for a user Solicits information about a Server s capabilities Registers a users current location Used for mid-session signaling 6/24/2004 page 7 Responses Similar to HTTP Response Codes (e.g. 404 Not Found ) 1xx Informational ( e.g. 100 Trying, 180 Ringing ) 2xx Successful ( e.g 200 OK, 202 Accepted ) 3xx Redirection ( e.g. 302 Moved Temporarily ) 4xx Request Failure ( e.g 404 Not Found, 482 Loop Detected ) 5xx Server Failure ( e.g 501 Not Implemented ) 6xx Global Failure ( 603 Decline ) 6/24/2004 page 8

5 Call Flow with direct invitation 1 INVITE sip:aj@delta.swh.sk /2.0 2 / OK 3 ACK sip: aj@delta.swh.sk /2.0 siemens.at delta.swh.sk 6/24/2004 page 9 Call Flow with Proxy Server swh.sk location server siemens.at 2 anton.janetka 1 INVITE sip: anton.janetka@swh.sk /2.0 7 / OK 8 ACK sip: anton.janetka@swh.sk /2.0 3 aj@delta 4 INVITE sip:aj@delta /2.0 6 / OK 5 ring delta 9 ACK sip:aj@delta /2.0 6/24/2004 page 10

6 Call Flow with Redirect Server siemens.at 1 INVITE sip: anton.janetka@swh.sk /2.0 4 / Moved temporarily 5 ACK sip: anton.janetka@swh.sk /2.0 6 INVITE sip: aj@delta.swh.sk /2.0 8 / OK 9 ACK sip: aj@delta.swh.sk /2.0 swh.sk 2 anton.janetka 3 aj@delta 7 ring location server delta 6/24/2004 page 11 A Request in Detail INVITE sip:bob@biloxi.com /2.0 Via: /2.0/UDP pc33.atlanta.com ;branch=z9hg4bk776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 154 <CRLF> v=0 o=alice IN IP4 pc33.atlanta.com s= c=in IP4 pc33.atlanta.com t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 G711/8000 a=sendrecv Method Type, Request URI, Vers. Address of previous hop Max. number of hops User being invited User originating the call Globally unique call Identifier Command sequence number & type URI of Alice to receive requests Body type here SDP payload Length of body in characters SDP version Owner/ creator & session identifier Subject of session (here empty) Connection information Media & transport information 6/24/2004 page 12

7 Example Request/Response INVITE /2.0 Via: /2.0/UDP pc33.atlanta.com ;branch=z9hg4bk776asdhds Max-Forwards: 70 To: Bob From: Alice Call-ID: CSeq: INVITE Contact: Content-Type: application/sdp Content-Length: 154 v=0 o=alice IN IP4 pc33.atlanta.com s= c=in IP4 pc33.atlanta.com t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 G711/8000 a=sendrecv / OK Via: /2.0/UDP pc33.atlanta.com ;branch=z9hg4bk776asdhds ;received= To: Bob <sip:bob@biloxi.com>;tag= From: Alice <sip:alice@atlanta.com>;tag= Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: INVITE Contact: <sip:bob@pc.bobshouse.com> Content-Type: application/sdp Content-Length: 154 v=0 o=bob IN IP4 pc.bobshouse.com s= c=in IP4 pc.bobshouse.com t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 G711/8000 a=sendrecv 6/24/2004 page 13 Via Operation Responses take same path as requests The Via header field acts like a stack Each proxy pushes its address in requests Pops its address in responses Information placed in the request comes back in the response UAC Via: A Via: B Via: A Via: C Via: B Via: A UAS Via: A Address: B Via: B Via: C Via: A Address: C Via: B Address: D Via: A Request Response 6/24/2004 page 14

8 Routing of Subsequent Requests Initial request may be sent through many proxies It is frequently unnecessary for subsequent requests to go through all of them Each proxy can decide whether it wants to receive subsequent requests Inserts Record-Route header containing its address For subsequent requests, endpoints insert Route header Contains sequence of proxies that should receive request Route is fixed for the duration of the dialog. INVITE BYE 6/24/2004 page 15 Forking Search user s location A proxy may have more than one address for a user Happens when more than one URL is registered for a user Can happen based on static routing configuration In this case, proxy may fork Forking is when proxy sends request to more than one destination at once First 200 OK that is received is forwarded upstream All other unanswered requests cancelled INVITE user@domain INVITE user3@domain3 INVITE user2@domain2 6/24/2004 page 16

9 Forking ctnd Main benefits Allows rapid search for user at many locations Phone rings more than one place at a time Two variations Sequential Search: Try first address, only if that fails try second address Parallel Search: Try all addresses at once (as in previous slide) Hybrid approaches possible Many proxies can fork, resulting in tree of proxies Best response to forked request is chosen and forwarded upstream First 200 OK received First 600 received if no 200 OK Lowest numbered response after all responses are received, given none was 200 or 600 Note usually only one response is forwarded upstream 6/24/2004 page 17 Offer/Answer Negotiating Media Range of options for a session are advertised in an Offer using SDP Multiple media streams Multiple codecs offered for each stream Offer can constrain media direction and codec parameters like bandwidth and framesize The Answer contains selections from options listed in the Offer Individual streams are accepted or rejected At least one codec is selected for each offered stream An Offer is typically carried in an INVITE, and the Answer in its 200 OK Variations: Early media, 200/ACK, UPDATE A Session established when an Offer/Answer exchange completes Dialogs are established with specific messages Sessions can be modified using subsequent Offer/Answer exchanges reinvite, UPDATE 6/24/2004 page 18

10 Example of Offer/Answer Exchange ALICE s Offer v=0 o=alice IN IP4 host.anywhere.com s= c=in IP4 host.anywhere.com t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video RTP/AVP 31 a=rtpmap:31 H261/90000 m=video RTP/AVP 32 a=rtpmap:32 MPV/90000 BOB s Answer v=0 o=bob IN IP4 host.example.com s= c=in IP4 host.example.com t=0 0 m=audio RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 31 m=video RTP/AVP 32 a=rtpmap:32 MPV/ /24/2004 page 19 On the Relationship of Standards Compatibility Frameworks & Interworking Extensions Services & Applications Interoperability 6/24/2004 page 20

11 Extension vs Application Extension Requires new protocol primitives (methods, headers) a toolkit for building applications Requires more than one entity in an exchange to do processing not specified in RFC3261 Needs to be defined based on extension guidelines in IETF E.g. REFER, SUBSCRIBE, replaces Application No new protocol primitives needed Generally requires only one entity in an exchange to know about the application Informational RFC can be generated in the PING working group E.g. -T, Call Transfer, 6/24/2004 page 21 Who does related Standardization Work? International Fora & Consortia Int. & Regional Standard. Orgs S I P Standard 6/24/2004 page 22

12 Key Areas of Interest in Org. Area New Features/ Extensions Frameworks/ Interworking Services/ Applications Compliance/ Interop Tests 3GPP ECMA () ETSI IETF IMTC ITU-T PacketCable Softswitch C Forum TIA 6/24/2004 page 23 Who does related Standardization Work? 3GPP decided to use in the CSCF of the IP Multimedia Subsystem (IMS) of its 3G mobile network. ECMA TC32 Usage of for Enterprise Networks ETSI TISPAN Control Layer for Next Generation Networks NGN IMTC Interoperability testing of IP-based communication products ITU-T SG13 Specification of -ISUP interworking PacketCable Specification of cable-based communication, e.g. DCS Softswitch Consortium Softswitch architecture for IP-telecommunication (-> -T) Forum Promotion of usage and interoperability tests (SipIt) TIA Specification of IP-Phones 6/24/2004 page 24

13 Many IETF Working Groups have -related Activities MMUSIC WG: provides SDP as an supplement to for session description. Currently working on new versions (SDPnew, SDPng) WG Guardian of the standard incl. maintenance, extensions, changes or new features PING WG documents the usage of and filters out need for extensions, new features.or changes IPTEL WG is on IP Telephony issues, contributes e.g. CPL for ease of service creation with SIMPLE WG: provides Instant Messaging and Presence Leveraging Extensions to, SPIRITS WG: specifies framework for accessing IN services from -networks AAA WG addresses access and billing issues ENUM WG: provides mapping of E.164 phone numbers to URLs using DNS SPEECHSC WG, develops protocols for distributed media processing of audio streams supporting ASR, TTS, SI and SV using XCON WG takes care for centralized conferences, including floor ctrl, and conference and media policy control 6/24/2004 page 25 Closing Thank You Contact Address Dr. Bernard Hammer Dept.: Siemens AG, ICN M SR 3, Munich Germany Tel.: +49 (89) bernard.hammer@siemens.com 6/24/2004 page 26