Application Scenario 1: Direct Call UA UA

Transcription

1 Application Scenario 1: Direct Call UA UA Internet Alice Bob Call signaling Media streams 2009 Jörg Ott 1 tzi.org INVITE sip:bob@foo.bar.com Direct Call bar.com Note: Three-way handshake is performed only for INVITE requests. alice@ruin 100 Trying 180 Ringing Media Streams BYE bob@foo Caller knows callee s hostname or address Called UA reports status changes After Bob accepted the call, OK is signaled Calling UA acknowledges, call is established Media data are exchanged (e. g. RTP) Call is terminated by one participant 2009 Jörg Ott 2

2 Callee Declines Call tzi.org INVITE bar.com 180 Ringing 603 Decline Calling UA acknowledges the transaction. Local user is contacted by called UA. User clicks on deny. UA returns error response Jörg Ott 3 Caller Gives Up tzi.org INVITE sip:bob@foo.bar.com bar.com Caller hangs up. Success. Destroy early dialog. alice@ruin Destroy transaction state and finish INVITE. 180 Ringing 180 Ringing CANCEL 487 Request Terminated bob@foo Local user is contacted by called UA. Called UA stops ringing, no call state created. Finish INVITE transaction Jörg Ott 4

3 Caller Gives Up While Call Established tzi.org INVITE bar.com Caller hangs up. Establish dialog. Finish INVITE and send BYE! Destroy dialog. 180 Ringing CANCEL BYE User answers. Transaction state for INVITE is destroyed. Create dialog, establish media session. Session teardown. Destroy dialog Jörg Ott 5 Caller Gives Up While Call Established tzi.org INVITE sip:bob@foo.bar.com bar.com Caller hangs up. Destroy state for CANCEL transaction alice@ruin 180 Ringing CANCEL 481 Transaction does does not exist BYE bob@foo No transaction to CANCEL Jörg Ott 6

4 How to Find The Callee? Direct calls require knowledge of callee s address provides abstract naming scheme: sip:user@domain Define mapping from URI to real locations: Explicit registration: UA registers user s name and current location Location service: Use other protocols to find potentially correct addresses Caller sends INVITE to any server knowing about the callee s location Receiving server may either redirect, refuse or proxy 2009 Jörg Ott 7 Finding the Next Hop UAC may use a (manually) configured outbound proxy Outbound proxy may also have be learned upon registration If request URI contains IP address and port, message can be sent directly UDP/TCP 5060 TLS 5061 Otherwise, determine next hop server via DNS Use NAPTR RR (+D2U/D2T/D2S, S+D2T/D2S) to obtain SRV records Query for SRV RR: _sip._udp, _sip._tcp, _sips._tcp for all supported transport protocols If entries found, try as specified in RFC 2782 If no entries found, use UDP for sip: URIs and TCP for sips: URIs Query A or AAAA records for IP address For specified domain name (Deprecated: For specified sip.domain ) 2009 Jörg Ott 8

5 Application Scenario 2: Redirected Call Calling Bob... Call him at address I am Bob, please redirect calls to my current address... 3 Internet Alice 4 Bob Call signaling Media streams 2009 Jörg Ott 9 Redirected Call tzi.org alice@ruin INVITE sip:bob@bar.com 100 Trying 302 Moved Temporarily Contact: sip:bob@foo.bar.com sip.bar.com User Lookup bar.com bob@foo INVITE sip:bob@foo.bar.com 2009 Jörg Ott 10

6 Application Scenario 3: Proxied Call Calling Bob... 2 Incoming call from Alice 3 1 I am Bob at address... Alice 4 Internet Bob Call signaling Media streams 2009 Jörg Ott 11 Proxied Call tzi.org alice@ruin sip.bar.com bar.com bob@foo INVITE sip:bob@bar.com 100 Trying INVITE sip:bob@foo.bar.com 100 Trying Media Streams Subsequent requests 2009 Jörg Ott 12

7 Application Scenario 4: Proxied Call (Real World) Requests typically Take different paths Are forked Form spirals Alice Call signaling Media streams Responses always Take the reverse path of the originating request Bob 2009 Jörg Ott 13 A Network 2009 Jörg Ott 14

8 IP-based Media Path 2009 Jörg Ott 15 Signaling Overlay 2009 Jörg Ott 16

9 Global Architecture backbone network Server Server Server Local domain Server Provider X domain Server signaling for initial call routing and setup Server Provider Y domain Server in-call signaling Server Endpoint Endpoint RTP media streams Endpoint Endpoint 2009 Jörg Ott 17 (Proxy) Server Functionality Stateless vs. stateful Stateless: efficient and scalable call routing (backbone) Stateful: service provisioning, firewall control,... Some roles for proxies Outbound proxy Perform address resolution and call routing for endpoints Pre-configured for endpoint (manually, DHCP,...) Backbone proxy Essentially call routing functionality Access proxy User authentication and authorization, accounting Hide network internals (topology, devices, users, etc.) Local IP telephony server (IP PBX) Service creation in general Jörg Ott 18

10 (Proxy) Server Functionality Stateless vs. stateful Stateless: efficient and scalable call routing (backbone) Stateful: service provisioning, firewall control,... Some roles for proxies Outbound proxy Perform address resolution and call routing for endpoints Pre-configured for endpoint (manually, DHCP,...) Backbone proxy Essentially call routing functionality Access proxy More elaborate functions provided by Back-to-Back User Agents (B2BUAs) User authentication and authorization, accounting Hide network internals (topology, devices, users, etc.) Local IP telephony server (IP PBX) Service creation in general Jörg Ott 19 Proxy vs. B2BUA UA 1 Dialog X Proxy (stateful or Stateless) Dialog X UA 2 Proxies only route and forward requests on behalf of UAs, they do not get active by themselves. They may generate responses and react to responses as part of processing a request. U Dialog X Dialog Y A B2B UA 1 UA 2 1 (stateful) U 2 B2BUAs terminate dialogs. They may create the illusion of an end-to-end dialog by coupling two dialogs and forwarding messages transparently between UAs. But they are a party to both dialogs Jörg Ott 20

11 Application Scenario 4: Proxied Call (Real World) Requests typically Take different paths Are forked Form spirals Alice Call signaling Media streams Responses always Take the reverse path of the originating request Bob 2009 Jörg Ott 21 Request Routing P1 P2 UA B P3 u4@c UA C Every server determines next hop Several destinations may be tried in parallel Mark outgoing messages with branch tag Use z9hg4bk + unique id to indicate unique branch tag Multiple requests can arrive at a single UAS UAS tags To: header to identify user presence RFC3261: From: tags mandatory for request merging at UAS 2009 Jörg Ott 22

12 Loops vs. Spirals P1 P2 UA B u1@p1 u3@b u1@p1 u3@p1 P1 u2@p2 P2 UA B 2009 Jörg Ott 23 Response Path Proxies may collect state for pending transactions TCP connections Accounting information Parallel search need response to clean up Insert Via: header when forwarding request Send response along reverse path of originating request Subsequent requests may take different path! Unless record routing is used 2009 Jörg Ott 24

13 Creation of Via-path Via: A P1 Via: P1 Via: A Via: P1 Via: A P2 P3 Via: P2 Via: P1 Via: A Via: P3, P1, A Via: P3 Via: P1 Via: A UA B UA C Send outgoing responses to first Via-entry UAS drops responses with different first Via entry Add branch-tag to distinguish different search paths 2009 Jörg Ott 25 Response Merging Via: A P1 Via: P1, A 408 Timeout Via: P1, A Proxy gathers incoming responses until No requests are pending, or Request timers have expired A user-initiated final response arrives (6xx or 2xx) Best response is returned to caller, others may be discarded or aggregated ( repairable errors ) OK-responses are returned whenever received INVITE requests may get multiple responses, others just one P2 P3 Via: P2,P1,A 486 Busy Via: P3,P1,A 408 Timeout Via: P3,P1,A UA B UA C 2009 Jörg Ott 26

14 Cancelling requests P1 CANCEL P2 P3 CANCEL CANCEL UA B UA C Cancel a previous request Does not affect complete transactions UAS sends 487 Transaction does not exist Otherwise no impact on UAS state Used by forking proxies to prune search tree if OK response arrived (see P1) 2009 Jörg Ott 27 Heterogeneous Error Response Forking Problem (HERFP) 1 INV 180 P1 INV 401 INV UA B 180 UA C P1 forks INVITE request UA B stays silent and solicits 401 Unauthorized UA C begins Ringing (180) Provisional response 180 is forwarded upstream UAC sees ringing indication No handling for 401 response possible at this time 2009 Jörg Ott 28

15 Heterogeneous Error Response Forking Problem (HERFP) 2 CANCEL P1 401 CANCEL 200 UA B UA C No answer from C hence A hangs up CANCEL 2009 Jörg Ott 29 Heterogeneous Error Response Forking Problem (HERFP) P1 forwards best response (401) to A Resubmit INVITE with appropriate credentials for B Drawbacks: C will ring again large call-setup delay Forked non-invite must be idempotent for sequential search P UA B UA C 2009 Jörg Ott Heterogeneous error responses cause problems

16 Solutions to HERFP? (1) UAC INVITE Proxy UAS A UAS B INVITE Proxy forks, UAS A INVITE requests authentication 130 INVITE (INVITE) 401 INVITE (INVITE) 180 CANCEL 200 (CANCEL) 487 (INVITE) / Repairable Err... Contact: UAC <sip:branchuri...> sends credentials Content-Type: message/sip Content-Length:... UAS A alerts user / Unauthorized... WWW-Authenticate:... INVITE <sip:branchuri...> /2.0 Authorization:... Proxy cancels second branch draft-mahy-sipping-herfp-fix-00.txt 2009 Jörg Ott 31 Solutions to HERFP? (2) Use 130 Repairable Errors response UAC issues a DECLINE method if the error cannot be fixed draft-mahy-sipping-herfp-fix-01.txt Use FIX request back to UAC (instead of 130) draft-jbemmel-sipping-herfp-solution-00.txt Alternative: avoid complexity Problems comes from forking -> avoid forking If multiple targets are found, return 300 class response Redirect the client to multiple targets Protect targets by means of internal mapping draft-roach-sip-herfp-avoidance-00.txt 2009 Jörg Ott 32

17 Record-Route Proxies may depend on seeing every request of established dialog Update state information for accounting, call distribution, Firewalls and NATs Record-Route and Route headers for request routing Prepend globally reachable request URI with proxy s address to Record- Route entries Receiving UAS copies contents into response Route header may be initialized with pre-existing route set Subsequent requests for this call will contain source route created from initial Record-Route header Route only created during dialog establishment (e.g., INVITE) Unchanged throughout dialog duration (only target URI may change) 2009 Jörg Ott 33 Constructing the Route RR: r1 RR: r2, r1 P1 P2 UA B sends request for UA B to P1 P1 and P2 add request URIs to Record-Route header UA B stores recorded route for later use RR: r2,r1 RR: r2,r1 RR: r2, r1 P1 P2 UA B UA B literally copies record route of request into response 2009 Jörg Ott 34

18 Using a Recorded Route R: r1,r2,rb R: r2,rb R: rb P1 P2 UA B creates new request to B with reversed contents of Record-Route from received response in Route-header appends B s contact from former response Every proxy forwards request according to Route Significant change from RFC 2543 R: ra R: r1,ra R: r2,r1,ra P1 P2 UA B UA B does not reverse ordering Request URIs for proxies are changed to s contact 2009 Jörg Ott 35 Pre-loaded Routes Requests may contain pre-existing Route set default outbound proxy, CSCFs in 3GPP Configured manually or learned automatically For transactions within a dialog, pre-pended to Record-Route set Loose source routing: Forwarding proxy may ignore topmost Route entry Route entry rewriting: In a response Proxy may rewrite its own Route URI Deal with forked routes (due to DNS lookups): R: r1,r2,rb P1 P2 UA B P2 UA B 2009 Jörg Ott 36

19 Media Negotiation During Call Setup Normal operation Delayed description UA B UA B INVITE Caps(A) INVITE Caps(A) Caps(B) Caps(B) Caps(A) Caps(B) 2009 Jörg Ott 43 SDP in Applications alice@ bob@ Additional Audio session media session with a set of alternatives INVITE sip:bob@ v=0 o=alice IN IP s=hello again e=alice@example.com t=0 0 c=in IP m=audio RTP/AVP a=rtpmap:96 G729/8000 a=rtpmap:97 GSM-EFR/8000 a=rtpmap:98 PCMU/8000 m=audio RTP/AVP 99 a=rtpmap:99 telephone-events 2009 Jörg Ott 44

20 SDP in Applications Only Second one audio media format session supported not supported INVITE v=0 o=bob IN IP s=hello again e=bob@example.com t=0 0 c=in IP m=audio RTP/AVP 98 a=rtpmap:98 PCMU/8000 m=audio 0 RTP/AVP 99 a=rtpmap:99 telephone-events 2009 Jörg Ott 45 SDP in Applications alice@ bob@ INVITE sip:bob@ v=0 v=0 o=alice IN IP o=bob s=hello 5160 again 1 IN IP s=hello e=alice@example.com again e=bob@example.com t=0 0 t=0 c=in 0 IP c=in m=audio IP RTP/AVP m=audio a=rtpmap: G729/8000 RTP/AVP 98 a=rtpmap:98 a=rtpmap:97 PCMU/8000 GSM-EFR/8000 m=audio a=rtpmap:98 0 RTP/AVP PCMU/ a=rtpmap:99 m=audio telephone-events RTP/AVP 99 a=rtpmap:99 telephone-events No SDP content 2009 Jörg Ott 46

21 Changing Session Parameters Either party of a call may send a re-invite that contains a new session description Use other connection address, port Add/remove codecs Append new media streams at the message s end Recipient re-aligns session description with current values Change media parameters Delete media streams (port has zero-value) Add new streams Gateways may use re-invite when session parameters are unknown during call setup 2009 Jörg Ott 47 UPDATEs for Session State (RFC 3311) UPDATE as generic mechanism to modify session state Dialog state vs. session state Prequisite: Early dialog established i.e. first non-100 response with To-tag received Allows updating session state before Negotiation and redirection of early media, putting media on hold Requesting and informing about resource reservation, security associations, connectivity Implemented via session state changes without dialog state changes UPDATE and the Offer/Answer-Model Multiple O/A cycles possible No overlapping offers allowed Race conditions signaled by 491 error response O/A in 183, PR, etc. allowed 2009 Jörg Ott 48

22 Use of UPDATE in Offer/Answer Model A INVITE Caps(A) 183 Session Progress Caps(A) Caps(B) PR UPDATE Caps(A') B Offerer sends session description Answerer must match against local capabilities Provides temporary answer in 183 E.g. for ringback tone Acknowledge by PR for reliability Caps(A') Caps(B') UPDATE request during early dialog: establish dialog state first (final or reliable provisional response) UPDATE Caps(B'') No effect on dialog state Caps(A'') Caps(B'') No offer allowed as long as pending offers exist Any party may send offer 2009 Jörg Ott 49