multimedia communication in the internet sip: advanced topics
Post on 03-Jan-2016
27 Views
Preview:
DESCRIPTION
TRANSCRIPT
1
Multimedia Communication in Multimedia Communication in the Internetthe Internet
SIP: Advanced TopicsSIP: Advanced Topics
Multimedia Communication in Multimedia Communication in the Internetthe Internet
SIP: Advanced TopicsSIP: Advanced Topics
Dorgham SisalemMobile Integrated Services
FhG Fokus
2
SIP Service SpaceSIP Service SpaceSIP Service SpaceSIP Service Space
3
What’s the Killer App?What’s the Killer App?What’s the Killer App?What’s the Killer App?
• Q: Added-value services expected to be major source of revenues. So what is the killer app?
• A: If I saw raw gold on the street I would not tell you either.
• It is believed that the convenience of integrated services will be the killer.
• Couple of examples follow...
4
IN-like Services with SIPIN-like Services with SIPIN-like Services with SIPIN-like Services with SIP
• Most of IN services may be easily implemented with SIP in proxies/redirect servers/UAs: – (Un)conditional call forwarding– abbreviated dialing– Screening– distinctive ringing– call distribution– call transfer– etc.
• Sometimes, implementation logic may completely differ.– Televoting and IVRs likely to be
replaced by Web in the long run.– Call-waiting is end-device
implementation issue with no protocol support.
– Music-on-hold may be played localy.
The real benefit is those services beyond IN: straight-forwardintegration with web, email, instant messaging, etc.
5
Call TransferCall TransferCall TransferCall Transfer
• Accomplished using the REFER method.• The REFER method indicates that the recipient (identified by the
Request-URI) should contact a third party using the contact information provided in the method.
• New header fields: Refer-To, Refer-By.• NOTIFY method used to report on result of referral.• Note: No changes to proxy behavior required.• Variants:
– With Consultation Hold (SIP Hold and unattended transfer)– Attended Transfer, I.e., with a short conference
draft-ietf-sip-cc-transfer
6
Example: Example: Call Transfer Call FlowCall Transfer Call Flow
Example: Example: Call Transfer Call FlowCall Transfer Call Flow
A
B
C
timeline
REFER BTo: BRefer-To: CReferred-By: A
#1
202 Accept#2#3 INVITE C
Referred-By: A
#4 200 OK
NOTIFY (OK)#6
200 OK#7
200 ACK#5
media
A is having a call with B. A decides to transfer B to C. It sends a “REFER” to B with C’s address. Eventually, A is notified on successful transfer using NOTIFY (#6).
7
3rd Party Call 3rd Party Call Control (3pcc)Control (3pcc)3rd Party Call 3rd Party Call Control (3pcc)Control (3pcc)
• 3pcc = Ability of a party to establish a session between other parties.
• Examples of use: – a click-to-dial service within a web phone-book– Operator services– Scheduled calls
• Design objective: use SIP “as is”• Solution: send “empty INVITES”, and swap replies with SDP ACKs• Controller may issue either its own or other’s party “forged” From
address. (Its real identity may be still verified using authentication.)• Controller often called back-2-back user agent
– Act as two user agents acting back-2-back– Manipulate messages coming from one agent before sending to
the other– Main state information about the two sessions
draft-rosenberg-sip-3pcc
8
Example: 3pcc call flowExample: 3pcc call flowExample: 3pcc call flowExample: 3pcc call flow
A
Controller C (e.g., co-locatedWith a web server)
B
draft-rosenberg-sip-3pcc
INV w/o SDP#1
timeline
200 SDP A1#2
ACK on-hold#3#4
INV w/o SDP
200 SDP B#5INV SDP B#6
200 SDP A2#7
200 ACK w/A2’#8
ACK#9
media
9
Answering MachineAnswering MachineAnswering MachineAnswering Machine
• Old-times behavior: set-up number of rings, plug-in, if you do not answer the machine will
• Easy to mimic with SIP: AM acts as a SIP UA; you need to set-up an answer timer, let the answering machine register using your credentials; when an invitation arrives it is forked both to your phone and your answering machine
• Added value examples: – Unified messaging: SIP answering machine can turn voice messages into email
messages that follow you or comprehensive web-pages (cf. voice navigation)– Programmability allows to play variety of customized prompt messages:
• If (caller friends) then play (“You can reach me at Venice beach or leave a message”) else play (“leave a message please”);
#1 INVITE
#2 Trying
#3 INVITE
#4 Ringing
#5 CANCEL
#6 OK#7 INVITE AM
10
Programming SIP ServicesProgramming SIP ServicesProgramming SIP ServicesProgramming SIP Services
11
Programming SIPProgramming SIPProgramming SIPProgramming SIP
• Examples– “discard all calls from Monica during my business hours”– “redirect authenticated friends to my cell phone, anyone else
to my secretary”– “if busy, return my homepage and redirect to recorder”
• Users and third parties may program• SIP follows HTTP programming model• Mechanisms suggested in IETF: CGI, Call Processing
Language (CPL), Servlets
12
GoalsGoalsGoalsGoals
• Minimize Time To Market– Implement SIP applications without detailed SIP
knowledge– Reduce Lines Of Code by using abstraction
functions
• Improve Quality Of Service– Avoid software bugs by using abstraction
programming interface• E.g.: call.forward (“sip:aa@iptel.org”) works independent
of caller’s and callee’s actual state
13
Service Execution Service Execution LayeringLayering
Service Execution Service Execution LayeringLayering
SIP
JavaServlets
SIP-CGI CPL
SIP Messages SIP Actions
Protocol stack
Interpreters
User Code
Servlets CGI Scripts(Perl, Python, C, …)
CPL scripts
14
Call Processing Logic Call Processing Logic ExampleExample
Call Processing Logic Call Processing Logic ExampleExample
#1 INVITE jku
Jku’s call processing logic:
If ($caller is in {Jane, Bob})proxy to jku@cell.com
else proxy to voicemail@trash.com
#2 pass invitationto call processinglogic
#3 return anaction
#4a INVITE jku@cell
#4b INVITE voicemail@trash
Jku’s call processing logic:
If ($caller ==Jane) play Mozartelse play Smetana
#5
The call processing logic may be
designed using various
mechanisms: CPL, SIP-CGI, servlet, proprietary ones.
15
Where May Signaling Where May Signaling Services Live?Services Live?
Where May Signaling Where May Signaling Services Live?Services Live?
• Some services have to live in the network:– call distribution– services for dial-up users without always-on IP connectivity– network servers may be located on users’ premises (PBX-like) or
operator’s premises (Web-hosting-like, NetCentrex-like)
• Some services can be implemented in both places:– forward on busy
• Some services work best in end-devices:– distinctive ringing
16
Service Location Service Location ExamplesExamples
Service Location Service Location ExamplesExamples
Feature End-device Proxy Distinctive Ringing Yes Can assist Visual call id Yes Can assist Call Waiting Yes No CF Busy Yes Yes CF No Answer Yes Yes CF No Device No Yes Location hiding No Yes Transfer Yes No Conference Bridge Yes No Gateway to PSTN Yes No Firewall Control No No Voicemail Yes No
Source: H. Schulzrinne: “Industrial Strength IP Telephony”
17
SIP Common Gateway SIP Common Gateway Interface (CGI)Interface (CGI)
SIP Common Gateway SIP Common Gateway Interface (CGI)Interface (CGI)
• Follows Web-CGI. Unlike Web-CGI, SIP-CGI supports proxying and processes responses as well.
• Language-indpendent (Perl, C, ...)• Communicates through input/output and environment variables.• CGI programs unlimited in their power. Drawback: Buggy scripts
may affect server behavior easily.• Persistency token (cookie) is passed between SIP server and CGI
to keep state across requests and related responses.
RFC 3050
18
SIP-CGI I/OSIP-CGI I/OSIP-CGI I/OSIP-CGI I/O
• Script input: environment variables (AUTH_TYPE, CONTENT_LENGTH, REQUEST_URI, etc.) and SIP message on stdin
• Script output: set of messages consisting of action lines, CGI header fields and SIP header fields on stdout
• Action lines:– Generating a response: status line– Proxying:
• CGI-PROXY-REQUEST <dest-url> <sip-version>• Additional header fields may be followed – they will be merged with the original
request.– Forward response: CGI-FORWARD-RESPONSE <token> <sip-version>– Set cookie for subsequent messages: CGI-SET-COOKIE <token> <sip-
version>– Determine if the script should be called for the next message belonging to
the same transaction: CGI-AGAIN ("yes" | "no") <sip-version>
19
Call Processing LanguageCall Processing LanguageCall Processing LanguageCall Processing Language
• Special-purpose call processing language. • CPL scripts define a decision tree which may result in signaling (proxy,
redirect, reject) or non-signaling (mail, log) action.• CPL scripts triggered by SIP messages.• May be used by both SIP and H.323 servers.• Target scenario: users determine call processing logic executed at a
server. • Limited languages scope makes sure server’s security will not get
compromised.• Portability allows users to move CPL scripts across servers.• Scripts may be manually written, generated using convenient GUI tools,
supplied by 3rd parties, ... draft-ietf-iptel-cpl
20
CPL ExampleCPL ExampleCPL ExampleCPL Example
<incoming> <address-switch field="origin" subfield="host"> <address subdomain-of="example.com"> <location url="sip:jones@example.com"> <proxy timeout="10"> <busy> <sub ref="voicemail" /> </busy> <noanswer> <sub ref="voicemail" /> </noanswer> <failure> <sub ref="voicemail" /> </failure> </proxy> </location> </address> <otherwise> <sub ref="voicemail" /> </otherwise> </address-switch> </incoming>
21
Example: Creating CPL Example: Creating CPL ScriptsScripts
Example: Creating CPL Example: Creating CPL ScriptsScripts
iptel.org: CPL Composer
22
JAIN: SIP Servlets and JAIN: SIP Servlets and APIAPI
JAIN: SIP Servlets and JAIN: SIP Servlets and APIAPI
• JAIN: Java APIs for Integrated Network Framework• Compromise between security and power: still a powerful
generic language but security provided by Java “sand-box”.• JAIN is a protocol independent API applicable to almost any
signaling (SIP, H.323, PSTN, etc.)– Java servlets are a high-level API building on top of HTTP servlet
API (package javax.servlet.sip)– JAIN SIP is a low-level API for complete control over a SIP stack.
(package jain.protocol.ip.sip)– Further JAIN Protocol API Specifications: ISUP, MGCP, H.323, etc.– JAIN App API Specs: Call Control– Technology Compatibility Kit (TCK) tests an implementation of
the JAIN SIP interfaces for compliance with the JAIN SIP Specification
• http://java.sun.com/products/jain/index.html
http://java.sun.com/products/jain/
23
JAIN ComponentsJAIN ComponentsJAIN ComponentsJAIN Components
• JAIN SIP Events: Within the API, SIP messages are encapsulated as Message objects that are passed between the JAIN SIP Provider and the JAIN SIP Listener.
• JAIN SIP Provider: Within the API, the JAIN SIP Provider is defined as the entity that provides an application access to the services of the SIP stack.
• JAIN SIP Listener: Within the API, the JAIN SIP Listener is defined as the entity that uses the services provided by the JAIN SIP Provider.
24
JAIN Classes and JAIN Classes and MethodsMethods
JAIN Classes and JAIN Classes and MethodsMethods
• SipListener– processRequest– processResponse– Process Timeout
• SipProvider– sendResponse– sendRequest– addSIPListener
• SipURL• Message
– addHeader– getBodyAsBytes– removeViaHeaders
• Request– setRouteHeaders
• Response– setStatusCode
Note: methods shown here are only subsets of all available method!
25
Call Processing TradeoffsCall Processing TradeoffsCall Processing TradeoffsCall Processing Tradeoffs
• Generality versus security– multipurpose programming languages provide a huge
service space– but also a huge vulnerability space
• Performance versus portability– portable languages (CPL) need to be interpreted
• higher processing delay
– portability needed if services deployed at multiple servers or end-devices (e.g. if stored at USIMs)
26
Which Service Creation Which Service Creation Method Should I Use?Method Should I Use?
Which Service Creation Which Service Creation Method Should I Use?Method Should I Use?
• choice of appropriate service creation mechanism depends on deployment scenario– where the service is executed (operator’s proxy vs. user’s end-device)– by whom the service is maintained (user vs. administrator)– demanded service logic
• Scenario #1: A SIP site administrator wants to allow customers to define their personalized call forwarding preferences– CPL is chosen for best security– Web CPL editor is provided for user convenience
• Scenario #2: A SIP site administrator wants to define an access control list for protecting a PSTN gateway pool– Call processing logic depends on authentication data and call destinations
-> CPL is not sufficient (no authentication switch) -> CGI or Servlets• Scenario #3: An enterprise SIP proxy used for 3-rd party apps
– Servlets used for generality and portability
27
Other WorkOther WorkOther WorkOther Work
• There seems to be a huge interest in creating call control APIs. Other efforts include:– Parlay– TAPI– JTAPI– CTI– ...
28
SIP and MobilitySIP and MobilitySIP and MobilitySIP and Mobility
29
SIP and MobilitySIP and Mobility
• Solutions space by layers– Application layer: SIP-based mobility support
• drawback: application specific, needs to be re-implemented for every application
– IP layer: Mobile-IP• drawback: IPv4 triangle routing, nobody knows when IPv6
happens
– lower layers• current cell phone networks• wireless IP (WaveLANs ?)
30
SIP and Terminal MobilitySIP and Terminal Mobility
• Terminal can move between subnetworks• Realised today with GSM and wireless LAN• Issues to consider:
– Handoff performance– Redirection authentication
• Mobile hosts (MH) inform their home proxy about their new locations using REGISTER
• Mid-call mobility (Session mobility) is dealt with using reINVITE
31
SIP and Terminal MobilitySIP and Terminal Mobility
Home Network
HP
Visited Network
FPSignalling
Cell 2
Cell 1REGISTER
#1
REGISTER #2
32
SIP and Terminal MobilitySIP and Terminal Mobility
Home Network
HP
Visited Network
FPSignallingData
Cell 2
Cell 1
INVITE#1
INVITE#2
INVITE#3
#4
33
SIP and Terminal MobilitySIP and Terminal Mobility
Home Network
HP
Visited Network
FPSignallingData
Cell 2
Cell 1
REGISTER#3
REGISTER
#2
#1
reINVITE #3
#4
34
SIP and Terminal MobilitySIP and Terminal Mobility
Home Network
Visited Network
FPSignallingData
Cell 2
Cell 1
REGISTER#3
REGISTER
#2
reINVITE #3
#4
HP
35
SIP and Personal MobilitySIP and Personal Mobility
• Person uses different Devices and possibly address• REGISTER binds a person to a device • Proxy and redirect translate address to location and
device• Issues to consider:
– Authentication: finger print, IR, password ..– Binding different addresses to single person:
LDAP ..
36
SIP and Service MobilitySIP and Service Mobility
• Use same services from different locations and devices– Speed dial, address book, media preferences, call handling
• Services located at home server – RECORD-ROUTE home proxy to force calls to be processed by
home servers– Services located at end systems– retrieve with REGISTER
• Issues to consider– Services need to be device independent: standardised
service description (CPL) ..– User recognition and authentication
37
SIP and Mobile-IPSIP and Mobile-IP
• Mobile-IP is a well established standard for mobile communication in the Internet
• Allow hosts to be reached under the same address regardless of location
• Mobile hosts register a care-of-address with home agent• Correspondent nodes (CN) send data to home agent• Home agent tunnels traffic to care-of-address• MH sends traffic directly to CN • Triangular routing increases delay• Tunnelling increases bandwidth consumption
38
Mobile-IP (Registration)Mobile-IP (Registration)
Home Network
HA
Visited Network
FA
Cell 1
Cell 2
Registration #2
Registration
#1
39
Mobile-IP Mobile-IP (Communication(Communication))
Home Network
HA
Visited Network
FASignallingData
Cell 1
Cell 2
#1
#2
#3
#4
#5
#6
#7
40
SIP and Mobile-IPv6SIP and Mobile-IPv6
• IPv6 is especially interesting for mobile Internet• Mobile-IPv6 uses Binding updates similar to SIP
registration and reinvitations to avoids triangular routing
• Use routing header option to avoid tunnelling• Could be a solution for providing a unified protocol for
mobile data and voice communication??
41
SIP RobustnessSIP RobustnessSIP RobustnessSIP Robustness
42
Robust Protocol DesignRobust Protocol DesignRobust Protocol DesignRobust Protocol Design
• Robustness determined by state maintenance model• Amount of state in SIP Servers minimized
– servers may be stateless (SL) or maintain transaction state (TS) or session state (SS)
– The less state the more robustness; failure of a SL or TS proxy does not affect existing sessions
– transactional state is needed to enable services such as forking/forward-on-busy or if SIP runs over TCP
– session state may be needed for maintaining firewalls or generating failure-resistant CDRs; keep-alive possible using re-INVITEs and session timer
• SIP INVITEs convey full signaling state• Subsequent messages may take different path
43
DNS for Failure Recovery DNS for Failure Recovery & Load Balancing& Load Balancing
DNS for Failure Recovery DNS for Failure Recovery & Load Balancing& Load Balancing
• Unavailable SIP servers can be dealt with using DNS in the same way as mail servers are:– DNS servers maintain multiple prioritized SRV entries– callers initiate calls to high-priority server; if unavailable, they proceed to
lower-priority server
• Load balancing can be accomplished similarly– DNS servers maintain multiple SRV entries with equal priority
• Phone do not support this very often these days
– a random pick is chosen out of the server list
• Notes on DNS– it’s good do have multiple DNS servers for each zone of authority;– DNS may be a pain ...
44
Other Load Balancing Other Load Balancing MethodsMethods
Other Load Balancing Other Load Balancing MethodsMethods
• A front-end proxy may dispatch calls to a proxy farm• Load-balancing NAT may be used• Call processing logic may be off-loaded to end-devices
45
SIP and QoS ControlSIP and QoS ControlSIP and QoS ControlSIP and QoS Control
46
QoS: SIP and QoS ControlQoS: SIP and QoS ControlQoS: SIP and QoS ControlQoS: SIP and QoS Control
• SIP DOES NOT provide QoS support.• QoS is coupled with SIP through the notion of preconditions.• Objective is to ensure that resources are made available
before the phone rings.• Invitations might indicate in SDP that QoS assurance is
mandatory.– Call setup should only proceed after satisfying the preconditions
• SIP extended method (UPDATE) indicates the success or failure of the preconditions.
• “confirm” attribute in SDP tells the other party to indicate met preconditions. If both parties send “confirm”, session originator sends UPDATE last.
draft-ietf-sip-manyfolks-resource
47
SIP and QoS ControlSIP and QoS ControlSIP and QoS ControlSIP and QoS ControlCaller@sip.com Callee@support.example.com
Proxy
INVITE sip:Callee@support.example.comm=audio 49170 RTP/AVP 0 a=qos:mandatory sendrecv confirm
#2
183 Progressm=audio 49170 RTP/AVP 0 a=qos:mandatory send confirm
#3
PRACK#5
Media stream#11
#1INVITE sip:Callee@example.comm=audio 49170 RTP/AVP 0a=qos:mandatory sendrecv confirm
#4 183 Progress m=audio 49170 RTP/AVP 0 a=qos:mandatory send confirm
#6 Reserve
#7 UPDATE
#8 200 OK (UPDATE)
#10 ACK
200 OK (INVITE)#9
top related