SIP-I & SIP-T Introduction and Overview Webinar

This document is for informational purposes only, and Tekelec reserves the right to change any aspect of the products, features or functionality described in this document without notice. Please contact Tekelec for additional information and updates. Tekelec. For What's Next.

Adam RoachPrincipal Engineer

October 27, 2009

SIP-I & SIP-TIntroduction and Overview

2 |

Tekelec. For What's Next. Tekelec Confidential

Mike Sies (Moderator)Global Marketing

Tekelec

Adam RoachPrincipal Engineer

Tekelec

Speakers

About Tekelec

Global STP leader with 40% market share Number Portability leadership with over 91

customers in 32 countries Comprehensive SIGTRAN experience SIP experts Chair 3 IETF SIP Working Groups Over 150 IAS customers Unique end-to-end network visibility with

integrated signaling and performance management solutions

Leading next-gen messaging provider: SMS routing, offload, security and advertising

49 new customers in the last ten quarters worldwide

More than one BILLION mobile, mobile Internet and telephone subscribers around the world make calls, send text messages, make mobile payments, and enjoy social networking because of Tekelec

Tekelecs solutions are in 8 of 10 of the worlds largest wireless operators and in 6 of 10 of the worlds largest wireline operators

Tekelec Confidential

Agenda

What are SIP-I and SIP-T?

Architectures for mixed-protocol networks

How ISUP parameters are carried through SIP networks

How ISUP parameters are mapped to and from SIP header field values

Challenges specific to mixed-protocol networks (overlapped dialing, call forking)

4 |


Survey Question

What is your current level of knowledge about these technologies?

1.No or very little SIP knowledge

2.Some SIP, but dont know about SIP-I or SIP-T

3.Already have some knowledge about SIP-I and/or SIP-T

5 |


What is SIP-T?

IETF-defined specification for mixed- protocol SIP/ISUP networks

Defined in RFC 3372, RFC 3398, RFC 3578, and RFC 3204

Developed roughly in parallel with last major revision of SIP (mid-2002)

6 |


What is SIP-I?

ITU-defined specification for transiting ISUP and/or BICC between gateways using SIP

networks

Defined as part of ITU-T Q.1912.5

Developed in 2004, re-using many of the components developed as part of the IETF SIP-T effort

7 |


How Does SIP-I Relate to SIP-T?

Very similar in purpose, almost compatible

Difference in styles, reflecting different approaches between IETF and ITU standardization: SIP-I specifies rigid architectures, profiles, and services; cannot

make use of new SIP features as they are developed SIP-T focuses on the tools for mapping core protocol constructs,

leaves feature mapping at the discretion of equipment manufacturers

SIP-I includes mapping for BICC and ISUP; SIP-T considers only ISUP

SIP-T allows calls to originate and terminate at SIP endpoints, not just gateways

8 |


Supported Use Cases

9 |


Survey Question

What level of interoperability have you experienced with SIP-I and/or SIP-T products?

1.No problems2.Some minor issues, but

things basically work3.Major issues, but still

deploying4.Interop is enough of an

issue that were delaying or canceling deployments

5.No experience yet

10 |


SIP-T Only

Basic Mixed Protocol Architecture

SIP Network

SIP Network PSTNPSTNPSTNPSTN

PSTN Phone

SIP Phone

PSTN Phone

PSTN Gateway PSTN Gateway

SIP Application Servers

SIP PhoneSIP Phone

11 |


Overview of Operation: PSTN to PSTN

SIP Network


PSTN Phone

SIP Phone

PSTN Phone



SIP PhoneSIP Phone

ISUP

Message

SIP Message

With Original

ISUP Message

Attached

Performs service-

related SIP

message

Modifications

Maps from ISUP

parameters to

SIP Header

Modifies attached

ISUP message

to match changes

made to SIP

message

Modified

ISUP

Message

12 |


Overview of Operation: PSTN to SIP

SIP Network


PSTN Phone

SIP Phone

PSTN Phone



SIP PhoneSIP Phone

ISUP

Message

SIP Message

With Original

ISUP Message

Attached

Performs service-

related SIP

message

Modifications

Maps from ISUP

parameters to

SIP Header Ignores

attached ISUP

Message

13 |


Overview of Operation: SIP to PSTN

SIP Network


PSTN Phone

SIP Phone

PSTN Phone



SIP PhoneSIP Phone

SIP Message

(No ISUP

Attachment)

Performs service-

related SIP

message

ModificationsCreates new ISUP

message, based on

content of SIP

message

ISUP

Message

14 |


Survey Question

What have you deployed or do you plan to deploy?

1.Neither SIP-I nor SIP-T2.SIP-I only3.SIP-T only4.Both SIP-I and SIP-T5.One or both, but not

certain which

15 |


HeaderBody

Anatomy of a SIP Message

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 172.17.1.247:2078;branch=z9hG4bK-6vi6sa58smfx;rport

To: "Robert Sparks"

From: "Adam Roach" ;tag=4at3wehz8c

Call-ID: 3c58339ed1f6-lvfoul2ixa8h

CSeq: 1 INVITE

Max-Forwards: 70

Contact:

Accept: application/sdp

Content-Type: application/sdp

Content-Length: 168

v=0

o=-

1411917766 1411917766 IN IP4 172.17.1.247

c=IN IP4 172.17.1.247

t=0 0

m=audio 61586 RTP/AVP 0 101

a=rtpmap:0 pcmu/8000

a=rtpmap:101 telephone-event/8000

Header Fields

16 |


Anatomy of an ISUP Message

17 |


HeaderBody

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 172.17.1.247:2078;branch=z9hG4bK-6vi6sa58smfx;rport To: "Robert Sparks" From: "Adam Roach" ;tag=4at3wehz8c Call-ID: 3c58339ed1f6-lvfoul2ixa8h CSeq: 1 INVITE Max-Forwards: 70 Contact: Accept: multipart/mixed, application/sdp Content-Type: multipart/mixed; boundary=sdlitskeiut-x Content-Length: 307

--sdlitskeiut-x Content-Type: application/sdp

v=0 o=- 1411917766 1411917766 IN IP4 172.17.1.247 c=IN IP4 172.17.1.247 t=0 0 m=audio 61586 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000

--sdlitskeiut-x Content-Type: application/isup; version=nxv3; base=etsi121 Content-Disposition: signal; handling=optional

--sdlitskeiut-x--

ISUP Message Tunneling (Ingress)

PSTN Gateway

18 |


HeaderBody

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 172.17.1.247:2078;branch=z9hG4bK-6vi6sa58smfx;rport To: "Robert Sparks" From: "Adam Roach" ;tag=4at3wehz8c Call-ID: 3c58339ed1f6-lvfoul2ixa8h CSeq: 1 INVITE Max-Forwards: 70 Contact: Accept: multipart/mixed, application/sdp Content-Type: multipart/mixed; boundary=sdlitskeiut-x Content-Length: 307

--sdlitskeiut-x Content-Type: application/sdp

v=0 o=- 1411917766 1411917766 IN IP4 172.17.1.247 c=IN IP4 172.17.1.247 t=0 0 m=audio 61586 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:101 telephone-event/8000

--sdlitskeiut-x Content-Type: application/isup; version=nxv3; base=etsi121 Content-Disposition: signal; handling=optional

--sdlitskeiut-x--

ISUP Message Tunneling (Egress)

PSTN Gateway

Note: SIP Service Execution has changed destination

19 |


Three Main Mappings

Mapping between message types

Mapping between SIP header fields and ISUP parameters

Mapping between ISUP cause codes and SIP response codes

20 |


Message Type Mapping

Driven by call state

SIP-T defines formal state machine for mapping

Semantics of message types should be very similar

Several messages have no mapping (e.g., SIP OPTIONS, ISUP CCR)

21 |


High-Level Message Mapping

INFO can also be used for SUS and RES under certain circumstances.

SIP-I uses INFO for all SUS and RES messages, since interworking

with native SIP terminals is out of scope.

22 |


Message Mapping: Example Call Setup

23 |


Message Mapping: Mid-Call Interaction

Note: SIP-I uses

INFO instead of

INVITE

24 |


Header/Parameter Mapping

Focused predominately on mapping in IAM/INVITE translation

In practice, most mapping relates to calling and called party identity

Limited support for SIP indication of number portability, carrier selection

Requires several mandatory parameters to be provisioned with default values in gateways (e.g., Nature of Connection, Transmission Media Requirement)

25 |


High-Level IAM Parameter Mapping

The P-Asserted-Identity:

and Identity:

header fields will be used for this purpose under certain circumstances.

Mapping specified by SIP-I only; requires a priori knowledge of network topology

26 |


Response Code / Cause Code Mapping

Convey reason for call setup failure when error is at called party end

SIP-I and SIP-T take radically different approaches SIP-T attempts to map to semantically similar code SIP-I maps almost all ISUP codes to SIP 500 Server Error,

almost all SIP codes to ISUP 127 Interworking, Unspecified

Mapping is not necessarily reversible (e.g., ISUP 34 SIP 503 ISUP 41)

In practice, many products make this mapping configurable, using either SIP-I or SIP-T table as default

27 |


Representative Mapping: SIP to ISUP

28 |


Representative Mapping: ISUP to SIP

If no new number is provided by the ISUP diagnostic code, SIP-T will use 410 gone

the use of 301 allows automatic recovery in the SIP network.

29 |


Response Code Mapping: Call Flow

30 |


Challenges in SIP/ISUP Networks

Overlapped Dialing

Early Media

Call Forking

Service Parity

31 |


Overlapped Dialing

In locations with variable-length numbering plans, called party number may be sent in multiple ISUP messages (IAM followed by one or more SAM)

SIP generally expects complete addresses in INVITE messages

No problem for SIP-originated calls

SIP-T and SIP-I define complicated procedures for handling overlapped dialing in ISUP-to-ISUP and ISUP-to-SIP calls

Generally, requires that SIP service proxies understand overlapped dialing procedures

Problem can be bypassed, with degraded user experience, by using digit collection timers

32 |


Overlapped Dialing: Very Simple Example

33 |


Early Media

SIP generally expects that the session will be established before media is passed Tones and errors are indicated by the calling party device SIP does specify that clients should receive and play out media prior to

call establishment to avoid clipping

ISUP generally anticipates the ability to send media down a circuit as soon as it is seized Call progress tones are often sent by the called party end office Many legacy IVRs take advantage of this by not sending an ACM until

(and unless) the call reaches a human

In other words, SIP provides a best effort

attempt at passing media prior to the call, while ISUP has an absolute requirement

This leads to additional signaling in SIP to establish more reliable early media channel This additional signaling is not supported by all clients

34 |


Call Forking

One feature inherent in SIP is the idea of forking

a single INVITE message to multiple destinations simultaneously

ISUP has no analog to this behavior

such services require servers which effectively terminate and re-originate the call

Forked calls that reach multiple gateways will result in two disparate sets of ISUP messages, which cannot simply be merged

Forked calls can also result in multiple early media sessions

SIP/ISUP gateways must recognize such situations and provide sensible behavior to the PSTN side

Neither SIP-I nor SIP-T provide explicit guidance here; equipment providers need to handle on a case-by-case basis

35 |


Service Parity

Many services already enabled by current mapping (e.g., Calling Party Identification, Anonymous Call Rejection)

More advanced services need further definition (e.g., Automatic Call Completion)

Ongoing work to define and document interworking of services between SIP and ISUP/TCAP networks: IETF BLISS Relatively new working group formed to formalize

specific SIP mechanisms for services already deployed in the PSTN

ETSI TISPAN Interfaces with IETF to provide requirements for specified services; ensures BLISS-specified SIP services work with PSTN

36 |


Summary

SIP-I and SIP-T are two similar approaches that define interworking between SIP and ISUP networks Support different use cases (SIP-T interworks with native SIP

terminals; SIP-I includes mapping for BICC)

Designed to allow ISUP to pass transparently through a SIP network if both endpoints are ISUP

Allow deployment of SIP services for use in both SIP/IMS and PSTN/PLMN networks

Fully defined and widely deployed for basic calling, some class services

Ongoing work to add remaining class services for mixed- network interworking

37 |


Follow-up email Webinar slide deck Recording archive

Visit

www.tekelec.com:

Archived webinars

Whitepaper downloads

SSR Application Handbook

SIP and SS7 Pocket Guides

SIP Sessions blog blog.tekelec.com

Next Steps

38 |


Q&A and Contact Information

Adam RoachPrincipal EngineerOffice: +1.214.329.0491Mobile: [email protected]

39 |


SIP-I & SIP-TSlide Number 2About TekelecAgendaSurvey QuestionWhat is SIP-T?What is SIP-I?How Does SIP-I Relate to SIP-T?Supported Use CasesSurvey QuestionBasic Mixed Protocol ArchitectureOverview of Operation: PSTN to PSTNOverview of Operation: PSTN to SIPOverview of Operation: SIP to PSTNSurvey QuestionAnatomy of a SIP MessageAnatomy of an ISUP MessageISUP Message Tunneling (Ingress)ISUP Message Tunneling (Egress)Three Main MappingsMessage Type MappingHigh-Level Message MappingMessage Mapping: Example Call SetupMessage Mapping: Mid-Call InteractionHeader/Parameter MappingHigh-Level IAM Parameter MappingResponse Code / Cause Code MappingRepresentative Mapping: SIP to ISUPRepresentative Mapping: ISUP to SIPResponse Code Mapping: Call FlowChallenges in SIP/ISUP NetworksOverlapped DialingOverlapped Dialing: Very Simple ExampleEarly MediaCall ForkingService ParitySummaryNext StepsQ&A and Contact Information

Documents

SIP-I & SIP-T Introduction and Overview Webinar