MGC to MGC Communications with SIP

1
(No Transcript)
2
MGC to MGC Communications Leveraging the Value
of SIP

• Jonathan Rosenberg
• Chief Scientist

3
Overview

• Requirements for MGC to MGC Communications
• SIP As A Solution
• SIP Extensions Required
• Standards Update

4
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
• OAMP

5
Inter-MGC Architecture
Proxy
MGC Complex
Proxy
MG
T1/3
Proxy
SIP
Megaco
Location Server
MGC
Location Server
Location Server
SCTP
MGC
MGC Complex
TRIP
SS7
SG
Proxy
Proxy
Proxy
Location Server
SQL
Subscriber Database
Location Server
6
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

7
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

8
Enabling Services

• Subscriber Database Is a Critical Component
  Providing
• User identification
• Current location
• Features enabled
• Feature parameters
• Authorization information

9
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

10
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

11
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

12
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

13
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 Dont Map
• Many ISUP message type dont map to SIP
• Mid-call messages SUS, RES, INR, INF
• Solution SIP INFO method

14
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

15
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

16
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

17
SIP As A Solution continued

• Approach II Negotiation
• Ingress gateway picks its favorite, sends it in a
  request
• If egress gateway doesnt 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

18
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?

19
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 doesnt understand the body, it
  discards it

20
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

21
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.

22
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

23
Information Resource

• Jonathan Rosenberg
• jdrosen_at_dynamicsoft.com
• 1 732.741.7244