dynamicsoft Inc. Proprietary VON Developers Conference 1/19/00 C O N N E C T I N G T H E W O R L D W I T H A P P L I C A T I O N S.

www.dynamicsoft.comdynamicsoft Inc. ProprietaryVON Developers’ Conference 1/19/00

C O N N E C T I N G T H E W O R L D W I T H A P P L I C A T I O N S

MGC to MGC Communications:

Leveraging the Value of SIPJonathan Rosenberg

Chief Scientist



Overview Requirements for MGC to MGC Communications

SIP As A Solution

SIP Extensions Required

Standards Update



What Is MGC To MGC Communications? Supports Scalable, Transparent, Multi-provider

Phone-to-phone Service Through SS7 Terminations

MGC Is a Single Component of the Solution Non-decomposed gateways can also be used

Functions Required NPA-NXX routing

Services

Inter-device signaling

Billing and settlements

OAM&P



Inter-MGC Architecture

MGC

MGMGProxy

Subscriber

Database

SGSG SS7

T1/3

SCTP

Megaco SIP Proxy

Location

Server

Proxy

Proxy

Proxy

Location

Server

Location

ServerLocation

Server

MGC

Complex

MGC

Complex

MGC

Location

Server

Proxy

SQL

TRIP



TRIP For NPA-NXX Routing Telephony Routing Over IP

Being specified in IPTEL working group in the IETF

Formerly known as GLP

Used to exchange routing information between service providers

TRIP Supports Numerous Models Bilateral agreements

Centralized settlements provider

Wholesaler service



TRIP For NPA-NXX Routing continued

TRIP Is Based on Scalable IP Routing Technology Uses BGP4 as a basis

Supports aggregation, multiple providers

Uses proven algorithms

TRIP Provides Routing Tables for SIP Servers and Gatekeepers Access mechanisms include

OSP

LDAP



Enabling Services Subscriber Database Is a Critical Component

Providing User identification

Current location

Features enabled

Feature parameters

Authorization information



Enabling Services continued

Proxies Provide an Execution Environment to Manage features for parties in the call

Access subscriber database for feature information

Interface to other service provider networks

Level of State Dependent on Features That Need to Be Executed Pre-call services enable proxy to drop out after call completes

Mid-call services require proxies to be involved in a call signaling



Requirements For Call Signaling Traditional Call Signaling Needed

Call setup, tear down

Capabilities exchange

Feature invocation

Service Transparency Want phone-to-phone service to work identically to non-IP

Requirement: ISUP transport



Three Solutions For Call Signaling Call States Derived from ISUP, ISUP Extended to

Convey IP Media Information (BICC)

Call States Derived From IP Signaling, ISUP Information Mapped to IP Signaling

Call States Derived from IP Signaling, ISUP Messages Carried as Opaque Payloads



SIP As A Solution For Third Approach MIME

MIME = Multipurpose Internet Mail Extensions

Allows arbitrary content to be carried in email

Also used for HTTP

SIP Uses MIME SIP can carry arbitrary payloads

Simple to define an ISUP MIME type

Map each ISUP message type to SIP method, encapsulate ISUP message in SIP body



SIP As A Solution For Third Approach continued

Multipart SIP messages already carry a body (usually SDP)

With ISUP, SIP must carry two bodies

MIME Multipart allows multiple bodies

Messages That Don’t Map Many ISUP message type don’t map to SIP

Mid-call messages: SUS, RES, INR, INF

Solution: SIP INFO method



INFO Method Semantics of INFO Method

Used for established calls

Has no SIP call state semantics

Presents information FYI, purpose depends on body type

Usage for ISUP Mid-call ISUP messages placed into body of INFO

Decapsulated at far side



ISUP Flavors Problem Many National Variants of ISUP

How Is This Handled in VoIP?

Several Approaches Agree on a single version of ISUP for the Internet

Ingress and egress gateways support several and negotiate a common one

ISUP translation at intermediate proxies



SIP As A Solution SIP Helps Solve All Three

MIME provides labeling and negotiation capabilities

Approach I: Universal ISUP Simple to support in SIP

Content labeled with the agreed variant



SIP As A Solution continued

Approach II: Negotiation Ingress gateway picks its favorite, sends it in a request

If egress gateway doesn’t support it, it returns a 415 “Media Unsupported”

Error response contains an Accept header, listing allowed MIME types (i.e., ISUP flavors) supported

Ingress gateway tries again, picking a flavor that is supported

Approach III: Translation Proxies can look at MIME type in ingress request

Based on the next hop, translate ISUP and attach new body

End-to-end authentication fails



Non-ISUP Termination Problem In a Multi-provider Network, It Is Not Clear Where the

Call Will Terminate On another ISUP gateway

On an analog gateway

On a PC terminal

On a standalone PC phone

On an IP PBX

Will Not Know Ahead of Call Setup

To Include ISUP or Not?



Non-ISUP Termination Problem continued

Solution I First check where the call terminates

SIP has an OPTIONS message for querying remote participant about capability

OPTIONS response contains the list of supported MIME types

Can determine if ISUP is supported

Solution II Always send ISUP

If gateway doesn’t understand the body, it discards it



Standardization Status International Softswitch Consortium Developed

Concept Initially called SIP+

Single provider only

Now called SIP for Telephony, (SIP-T) or SIP Best Current Practice for Telephony (SIP-BCP-T)

IETF SIP Working Group Has Now Adopted It As a Work Item



Standardization Status continued

Several Outputs From IETF INFO Method extension

ISUP to SIP message conversions

MIME payload type for ISUP

Umbrella specification

All Four Outputs Will Be Proposed Standard RFCs

Priority of Focus Ensure SIP-T works for general SIP operation; multi-provider, security,

etc.



Conclusions MGC to MGC Communications Require Several

Components

Signaling That Supports Transparent ISUP Operation Is Important

SIP Is A Good Basis For Such A Solution MIME support makes carrying ISUP easy

MIME negotiation helps ISUP national variant problem

Extensions underway in IETF and ISC



Information Resource Jonathan Rosenberg

[email protected]

+1 732.741.7244

dynamicsoft Inc. Proprietary VON Developers Conference 1/19/00 C O N N E C T I N G T H E W O R L D W I T H A P P L I C A T I O N S.

Documents

t i o n s sip

t i o n s mgc

t i o n s trip

t i o n s requirements

developers conference

sip body slide

mime sip

mgc communications sip