SIP: Advanced Topics

indexadjustmentInternet και Εφαρμογές Web

13 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

94 εμφανίσεις



1


Multimedia Communication in the Internet


SIP: Advanced Topics

Dorgham Sisalem

Mobile Integrated Services

FhG Fokus





2

SIP Service Space



3

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 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
-
forward

integration with web, email, instant messaging, etc.



5

Call 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:

Call Transfer Call Flow

A

B

C

timeline

REFER

B

To: B

Refer
-
To: C

Referred
-
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

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 flow

A

Controller C (e.g., co
-
located

With 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

#5

INV SDP B

#6

200 SDP A2

#7

200 ACK w/A2’

#8

ACK

#9

media



9

Answering 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 Services



11

Programming 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

Goals


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 Layering

SIP

Java

Servlets

SIP
-
CGI

CPL

SIP Messages

SIP Actions

Protocol stack

Interpreters

User Code

Servlets

CGI Scripts

(Perl, Python,
C, …)

CPL scripts



14

Call Processing Logic Example

#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 invitation

to call processing

logic

#3 return an

action

#4a INVITE jku@cell

#4b INVITE voicemail@trash

Jku’s call processing
logic:


If ($caller ==Jane)


play Mozart

else


play Smetana

#5

The call processing
logic may be designed
using various
mechanisms: CPL, SIP
-
CGI, servlet,
proprietary ones.



15

Where May Signaling 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 Examples

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 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/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 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 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 Scripts

iptel.org: CPL Composer



22

JAIN: SIP Servlets and API


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 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 Methods


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 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 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 Work


There seems to be a huge interest in creating call
control APIs. Other efforts include:


Parlay


TAPI


JTAPI


CTI


...



28

SIP and Mobility



29

SIP 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 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 Mobility


Home Network

HP

Visited Network

FP

Signalling

Cell 2

Cell 1

REGISTER

#1

REGISTER

#2



32

SIP and Terminal Mobility


Home Network

HP

Visited Network

FP

Signalling

Data

Cell 2

Cell 1

INVITE

#1

INVITE

#2

INVITE

#3

#4



33

SIP and Terminal Mobility


Home Network

HP

Visited Network

FP

Signalling

Data

Cell 2

Cell 1

REGISTER

#3

REGISTER

#2

#1

reINVITE

#3

#4



34

SIP and Terminal Mobility


Home Network

Visited Network

FP

Signalling

Data

Cell 2

Cell 1

REGISTER

#3

REGISTER

#2

reINVITE

#3

#4

HP



35

SIP 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 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


S
ervices need to be device independent: standardised service
description (CPL) ..


User recognition and authentication





37

SIP 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)

Home Network

HA

Visited Network

FA

Cell 1

Cell 2

Registration

#2

Registration

#1



39

Mobile
-
IP (Communication
)

Home Network

HA

Visited Network

FA

Signalling

Data

Cell 1

Cell 2

#1

#2

#3

#4

#5

#6

#7



40

SIP 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 Robustness



42

Robust 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 &
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 Methods


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 Control



46

QoS: 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 Control

Caller@sip.com

Callee@support.example.com

Proxy

INVITE sip:Callee@support.example.com

m=audio 49170 RTP/AVP 0
a=qos:mandatory sendrecv confirm

#2

183 Progress

m=audio 49170 RTP/AVP 0

a=qos:mandatory send confirm


#3

PRACK

#5

Media stream

#11

#1

INVITE sip:Callee@example.com

m=audio 49170 RTP/AVP 0

a=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