Transcript 11-Amir Zmora

SIP Challenges and
Opportunities
Name: Amir Zmora
Title: Product Marketing
Date: 17 Jan 2003
The transfer
Dogbert
Dilbert
wants
asks
answers
him
fails
to call
to
the
transfer
the
call
boss
to
the Boss
Why Did the Transfer Fail?
 REFER has gone through many changes in various
versions.
 Ver 02 - Refer-To = ("Refer-To" | "r") ":" URL

Refer-To: SIP:[email protected]?Replaces…
 Ver 04 - Refer-To = ("Refer-To" / "r") HCOLON ( nameaddr / addr-spec )

Refer-To: SIP:[email protected]?Replaces…
 Ver 06 - Refer-To = ("Refer-To" / "r") HCOLON ( nameaddr / addr-spec ) * (SEMI generic-param)

Refer-To: <SIP:[email protected]?Replaces…>a=b
 The <> are optional in ver 04. Sending the ver 04 example to UA
supporting ver 06 will cause the Replaces to be related to the
Header and not to the address.
Some changes are not backwards compatible
AGENDA
 The Challenges of VoIP Development
 Do it yourself vs. Commercial Toolkits
 Commercial Toolkit Requirements
 RADVISION SIP Development Solution
The Challenges of
VoIP Development
The Evolving SIP Protocol
SIP Development Challenges
Application
(Features, services, UI …)
REFER
SIP-T…
PRACK
INFO
SUBSCRIBE
NOTIFY
SIP
3GPP
Extensions
others…
REFER
SIP-T…
PRACK
INFO
State Machine
re-INVITE
Authentication
Loose Routing
Dialog, Registration,
REFER
State Machine
User Agent Behavior
Record Routing
Mapping
ID Mapping
branch
CANCEL
Timers
State
Machine
Transaction
UDP
fragmentation
SCTP
SCTP
DNS
SIP
Transport
IPv6
UDP
Conn Mgmt
TCP
Location DB
Registration
Proxy/Reg
Spirals
Loops
Reliability
Authentication
100Rel
Whitespaces SDP
Multipart
Encoding
SIP
Message
MIME
Parsing
compact form MIME
TCP/IP, OS
SIP is No Longer a Simple Protocol…
The “S” in SIP Doesn’t Stand for Simple
 Complex Dialog state machines
 PRACK, UPDATE…
 Client side Authentication
 Re-INVITE after receiving 401/407
 DNS SRV & NAPTR queries
 Sequence of 3 queries
 Different function for IPv6
 Different implementation on different OS
 Loop/Spiral detection
 Spiral – Legal
 Loop - Illegal
 Many more…
Example of Complexity- Routing
 Routing decision – Loose vs. strict routing
 Complex routing algorithm – Destination address should
be taken from: Request URI, Rout, Via, Received?
 Backwards compatibility with Strict-Routing
Proxy
Adds P2
and P3
to route
Without Loose Routing
INVITE
b@UA1
P1
Visited Network
P2
P3
Home Network
Example of Complexity - REFER
 REFER Method
 for Transfer services
 Specified in:

draft-ietf-sip-refer-05.txt

draft-ietf-sip-cc-transfer05.txt
 Full support

Automatic operation +
callbacks

Uses NOTIFY extension to
report result of Transfer
Transferor
Transferee
Transfer
|
|
Target
|
INVITE |
|
|<-------------------|
|
|
200 OK |
|
|------------------->|
|
|
ACK
|
|
|<-------------------|
|
|
|
|
|<< ”Please transfer |
|
|<<
me to bob”
|
|
|
|
|
| INVITE (hold)
|
|
|------------------->|
|
| 200 OK
|
|
|<-------------------|
|
| ACK
|
|
|------------------->|
|
| REFER
|
|
|------------------->|
|
| 202 Accepted
|
|
|<-------------------|
|
|
| INVITE
|
|
|------------------->|
|
| 200 OK
|
|
|<-------------------|
|
| ACK
|
|
|------------------->|
| NOTIFY (200 OK)
|
|
|<-------------------|
|
|
200 OK |
|
|------------------->|
|
| BYE
|
|
|------------------->|
|
| 200 OK
|
|
|<-------------------|
|
|
|
BYE
|
|
|<-------------------|
|
|
200 OK |
|
|------------------->|
SIP Standard Inconsistencies and
Interoperability Issues
•
Inconsistencies in REFER
•
Changes in retransmission timers
•
Changes in CANCEL
•
Response code for INVITE inside INVITE has changed
•
MaxForward has become mandatory
•
Transaction key identifier rules was changed
•
CallLeg identifier was changed
•
Prefix added to Via Branch
•
LR was added to Route for Loose Routing support
•
CANCEL became invalid for general transactions
The Evolving Baseline SIP
RFC 2543 Established – Aug 99
bis 00 – July 00
bis 00 – Aug 00
bis 01 – Aug 00
bis 02 – Sept 00
bis 02 – Nov 00
bis 03 – May 01
bis 04 – July 01
bis 05 – Oct 01
bis 06 – Jan 02
bis 07 – Feb 02
bis 09 – Feb 02
RFC3261 – June 02
Plus hundreds of Drafts that
constantly change
New Changes Are Not Always Backwards Compatible
Developers Need to Ensure Their Products Comply With New
Version of Standard
SIP Development Challenges
 Interoperability
 Many independent implementations of SIP with
varying degrees of maturity
 Good interoperability requires investment:

participation in SIPit events

tested with various equipment vendors
SIP Development Challenges
(cont.)
 Extensibility
 SIP is a highly extensible protocol
 Stack design must accommodate current and
future needs
 Modular design and multi-level API are a must
 Maintainability
 SIP is still a moving target
 Constant flow of changes in baseline protocol and
extensions
 Cost of keeping a SIP stack up-to-date is high
Do It Yourself vs. Commercial
Toolkits
The Move from In-House Development To
Commercial Toolkits/Solutions
Developers are Turning to Third Party Toolkits for
VoIP Development
 Similar to the evolution of H.323, move from in-house to
commercial toolkit as protocol takes hold
 Save cost in man years
 Provides already integrated SIP and SDP services

Encoding, sending, parsing, managing calls and transactions,
and reliability/redundancy
 Address continuing SIP interoperability issues
 Vendor provides upgrades and application notes

Crucial in modifying existing products to comply with standard
changes
 You don’t re-invent the wheel
Freeing Resources to Focus on
Applications
Application
code
Application
(Features, services, UI …)
STANDARD:
Dialog, Registration,
Proxy/Reg
User Agent Behavior
• RFC 3261 (SIP)
SIP
Extensions
Transaction
• SIP Extensions
SIP Transport
• RFC 2327
(SDP)
TCP/IP, OS
SIP Message
Platform
3rdParty
Commercial Toolkit Requirements
Building a SIP Endpoint Using a
Vendor SIP Stack
 Dialog Management
 Registration
Application
 Authentication
 Telephony (SIP-T,
DTMF)
 Call Control
SDP
Stack
SIP
Stack
 More …

Media Description
Network

Media Transport

RTCP Reports
RTP/RTCP
Stack
Building a SIP Endpoint Using a
Vendor SIP Stack
 Interoperability and standards compliance
 Toolkit must be tested in all SIPit events
 Vendor should be involved in standard evolution
 Extensibility
 Modular design and multi-level APIs are required to
provide flexibility
 APIs should provide interface for proprietary message
encoding and parsing
 Maintainability
 Version upgrades as part of maintenance agreement
 Toolkit must be upgraded as standard evolves
RADVISION’s SIP
Development Solutions
A Family of SIP Development Solutions
SIP
Toolkit
SIP
Server
Toolkit
IP
Phone
Toolkit
SIP
ProLabTM Test
Management
Suite
Development
Solutions
SIP Development Solution Characteristics
 Real-Time Performance
 Internally multithreaded (SIP Stack and Server)
 High call/transaction rate (calls per second)
 Low memory-per-call/transaction and low footprint
 Advanced Capabilities
 High Availability support
 Multi-Homed Host support
 IPv6 Support
 Interoperable
 Tested with dozens of 3rd party SIP implementations
 Customizable
 Highly Configurable
 Multiple compilation options
SIP Toolkit Architecture
Application
Dialog/Registration
Layer
SIP TK
Manager
Transaction
Layer
Transport
I/F Layer
OS Abstraction Layer
Message Syntax
Layer
SIP Server Toolkit
 Fully standard SIP
Server functionality
 Loop and spiral
detection authentication
 Proxy server
 Message validation
 Redirect server
 Layered, modular
architecture with multilevel API
 Registrar server
 B2BUA & Presence
server (next version)
 Stateless/Stateful
 Forking
 Loose routing
 SRV and NAPTR DNS
queries
 Customizable automatic
behavior
 Extensible architecture
 OS:
 Solaris, Windows, Linux
 Coming soon: VxWorks
SIP Server Toolkit Architecture
Application
Location
DB
Presence
Agent
Security
SIP Server High-Level
SIP Server
Manager
Proxy Core
SIP Stack
SIP Server
Low-Level
ProLab Test Management Suite
 Tests:
 SIP (with extensions)
 SDP
 RTP/RTCP (both voice
and video)
 Distributed architecture:
 Central Manager
console (with GUI)
 One or more test
agents
 Script Driven:
 Intuitive scripting
language
 Can generate high load
of calls/transactions per
second
 Statistics and message
trace collection and
display
 Fully configurable test
environment from
central console
 H.323 test agents can
be integrated
seamlessly
ProLab Test Management Suite
RTP Analyzer
ProLab Manager
SIP
SIP Server
Test Scheduler
H.323
SIP Test Agent H.323 Test Agent
GK Agent
Conclusion
 SIP deployment brings exciting new features
 SIP is still an evolving protocol
 Interoperability is one of the major barriers for
SIP deployment
 Commercial vendors address interoperability
issues
 “Buy vs. Make” issue requires serious
consideration
Thank You
www.radvision.com
[email protected]