Lucent Technologies 5ESS User Manual

®

5ESS

Switch

Session Initiation Protocol (SIP) - OA&M Manual

5E16.2 and Later Software Releases

235-200-118

Issue 3.02B March 2007

This material is protected by the copyright laws of the United States and other countries. It may not be reproduced, distributed, or altered in any fashion by any entity (either internal or external to Lucent Technologies), except in accordance with applicable agreements, contracts or licensing, without the express written consent of Lucent Technologies and the business management owner of the material.

Notice

Every effort was made to ensure that the information in this information product was complete and accurate at the time of publishing; However, information is subject to change.

Mandatory customer information

Lucent Technologies 5ESS®switch equipment meets the applicable Network Equipment Building System (NEBS) Requirements as defined by Telcordia Technologies, Inc.

Trademarks

5ESS is a registered trademark of Lucent Technologies, Inc. in the United States and other countries.

Ordering information

This information product is distributed by the Lucent Technologies Learning Organization in Indianapolis, Indiana. To order, call: 1 888 LUCENT8 (1 888 582-3688) or fax to 1 800 566-9568 (from inside the continental United States) 1 317 322-6416 or fax to 1 317 322-6699 (from outside the continental United States).

Support

Information product support

To report errors or ask nontechnical questions about this or other information products produced by Lucent Technologies, contact the Lucent Technologies Learning Organization by sending email to comments@lucent.com.

Please include with your comments the title, ordering number, issue number, and issue date of the information product, your complete mailing address, and your telephone number.

Technical support

For technical assistance, call Lucent Technologies Technical Support Services: 1 866 LUCENT8 (1 866 582-3688) (from inside the continental United States) 1 630 224-4672 (from outside the continental United States) Technical Support Services is staffed 24 hours a day, 7 days a week.

Lucent Technologies

List of Figures

2 Architecture

2-1 IP Backbone 2-3

2-2 SIP Signaling Network, Hardware Perspective 2-4

2-3 SIP Signaling Network, Provisioning Perspective 2-5

2-4 Bearer Network 2-6

2-5 Packet Trunking 2-7

2-6 PSTN Gateway 2-8

2-7 SIP Architecture 2-9

2-8 SIP on DRM Architecture 2-11

2-9 Sample Configurations 2-15

2-10 SIP Protocol Stack 2-17

2-11 SCTP Endpoints 2-19

2-12 Multiple SCTP Associations 2-21

2-13 Paths Between Endpoints 2-22

2-14 Pack Faceplates 2-26

2-15 PSU2 Shelf Arrangement 2-27

2-16 Connecting circuits 2-29

2-17 SIP PH Functionality 2-31

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

FIGURES

xi

2-18 Cookie Mechanism 2-36

.....................................................................................................................................................................................................................................

3 Call Flow

3-1 Packet Trunking 3-3

3-2 PSTN Gateway 3-4

3-3 Network Elements 3-6

3-4 Network Connections 3-8

3-5 Successful Call Completion Message Flow 3-15

3-6 5ESS®Switch OPS - 5ESS®Switch TPS Message Flow 3-17

3-7 5ESS®Switch PSTN Gateway TPS and TAS OPS Message

Flow 3-21

3-8 SIP INVITE 3-40

3-9 SIP 183 SESSION PROGRESS 3-43

3-10 SIP UPDATE 3-44

3-11 SIP 200 OK (UPDATE) 3-45

3-12 SIP 180 RINGING 3-46

3-13 SIP 200 OK (INVITE) 3-47

3-14 SIP BYE 3-47

3-15 SIP 200 OK (BYE) 3-48

3-16 SIP without Encapsulated ISUP Successful Call 3-49

3-17 High-level Call Flow (without Encapsulated ISUP) 3-50

3-18 Call Setup at OPS - Steps 1-9 3-51

3-19 Call Setup at OPS - Steps 10-17 3-53

3-20 Call Setup at OPS - Steps 18-21 3-54

3-21 Call Setup at OPS - Steps 22-25 3-55

3-22 Call Setup at TPS - Steps 1-6 3-56

....................................................................................................................................................................................................................................

FIGURES xii

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

3-23 Call Setup at TPS - Steps 7-12 3-58

3-24 Call Setup at TPS - Steps 13-18 3-59

3-25 Call Setup at TPS - Steps 19-23 3-60

3-26 Call Tear Down at OPS 3-61

3-27 Call Tear Down at TPS 3-63

3-28 SIP INVITE {SDP} 3-65

3-29 SIP 183 SESSION PROGRESS {SDP} 3-66

3-30 SIP UPDATE {SDP} 3-67

3-31 SIP 200 OK (UPDATE) {SDP} 3-68

3-32 SIP 180 RINGING 3-69

3-33 200 OK (INVITE) 3-70

3-34 SIP ACK 3-70

3-35 SIP BYE 3-70

3-36 200 OK (BYE) 3-71

.....................................................................................................................................................................................................................................

4 Engineering Considerations

4-1 Two shelf PSU2 4-7

4-2 Engineering Association Sets 4-15

.....................................................................................................................................................................................................................................

5 Provisioning

5-1 SM Connectivity Provisioning Flowchart 5-3

5-2 Signaling Provisioning Flowchart for SIP with SCTP Transport 5-5

5-3 Signaling Provisioning Flowchart for SIP with UDP Transport 5-7

.....................................................................................................................................................................................................................................

6 Deprovisioning

6-1 Deprovisioning Flowchart 6-4

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

FIGURES

xiii

.....................................................................................................................................................................................................................................

7 Maintenance Considerations

7-1 “Autonomous Reports Flowchart” 7-32

7-2 “Resolve Protocol Handler Problems Flowchart” 7-35

7-3 “Resolve GQPH QPipe Problems Flowchart” 7-44

7-4 “Resolve SCTP Near Endpoint Problems Flowchart” 7-71

....................................................................................................................................................................................................................................

FIGURES xiv

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

List of Tables

2 Architecture

2-1 TCP/UDP/SCTP Comparison 2-17

2-2 SIP PH Characteristics 2-24

2-3 GQPH Characteristics 2-24

2-4 PSU2 shelf power terminations 2-27

2-5 Service Selection State 2-33

2-6 Service Selection State Combinations 2-34

.....................................................................................................................................................................................................................................

4 Engineering Considerations

4-1 IOST model BHC capacities 4-4

4-2 IOSE model BHC capacities 4-4

4-3 PSTNGW-LT model BHC capacities 4-4

4-4 PH equipage - one shelf 4-7

4-5 PH equipage - two shelves 4-8

4-6 SIP PH Configuration 4-9

4-7 SIP PH Equipage 4-10

4-8 GQPH Configuration 4-11

4-9 Control - messaging timeslots 4-12

4-10 GQPH Equipage 4-12

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

TABLES

xv

.....................................................................................................................................................................................................................................

5 Provisioning

5-1 SIP to PSTN Mapping Reference 5-77

5-2 PSTN to SIP Mapping Reference 5-78

....................................................................................................................................................................................................................................

TABLES xvi

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

About this information product

...............................................................................................................................................................................................................................................................

Purpose

The 5ESS®Switch Session Initiation Protocol (SIP) - OA&M Manual, 5E16.2 and Later, 235-200-118, information product enables users,

planners, maintenance personnel, engineers, installers, administrators, and provisioners to perform the necessary tasks required to support configuration, installation, monitoring, and repair of SIP signaling for packet trunking (including packet groups, SIP, SCTP, UDP, IP, QLPS connectivity, processor groups, and signaling-related hardware). OA&M procedures related to the OIU-IP bearer for SIP-signaled calls are covered in Optical Interface Unit - Internet Protocol (OIU-IP)

Interface Specification [5E16.2 and Later Software Releases],

235-900-316. This information product should be used as the source of complete

details on this protocol to clarify the implementation on the switch and the interpretation of technical reference (TR) requirements. These

®

details describe the 5ESS

switch offerings in terms of the support of Session Initiation Protocol (SIP). SIP is an evolving platform in which new features will be introduced continuously for new revenue opportunities, for improved operational efficiencies, and for support of specific applications. Beginning with the 5E16.2 software release, the

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

,

Lucent Technologies

xvii

5E16.2 and Later Software Releases

5ESS®switch supports the protocols and services defined by Telcordia Technologies, Inc.

This information product is expected to change as requirements and standards evolve. Therefore, Lucent Technologies reserves the right to change or delete any portion of the document, or to add information in future issues.

Reason for reissue

This information product is being reissued to support feature 99-5E-8645, “DRM IP Trunking”

About this information product

®

Safety labels

Typical safety labels are contained in this information product. The safety labels include warnings, cautions, and dangers and are accompanied by icons that indicate the type and level of safety hazard involved.

CAUTION

Caution indicates the presence of a hazard that can or will cause minor injury or property damage.

WARNING

Warning indicates the presence of a hazard that can cause death or severe injury.

DANGER

Danger indicates the presence of a hazard that will cause death or severe injury.

Intended audience

....................................................................................................................................................................................................................................

xviii

The 5ESS®Switch Session Initiation Protocol for Packet Trunking OA&M Manual describes the architecture, engineering, provisioning,

®

and maintenance of SIP on the 5ESS

switch. It is published as a guide for the users, planners, maintenance personnel, engineers, installers, administrators, and provisioners to perform their SIP-related

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

,

5E16.2 and Later Software Releases

tasks. Responsible personnel should have a working knowledge of telephony, switching, routing, and networking technologies.

About this information product

How to use this

information product

Each chapter in this information product groups related information about the SIP application.

Chapter Content

1. Overview Overview of SIP from an industry perspective and Lucent Technologies’ perspective.

2. Architecture Overview of the SIP architecture, starting at the Network view, then narrowing down to the System view, and finally, focusing on the hardware view.

3. Call Flow Overview of SIP call flows through the network (office-to-office), and through the

®

5ESS

4. Engineering

Considerations

Things to keep in mind when engineering SIP into your switch and network (for example, capacity, configuration, constraints, IP addressing schemes, network management, performance monitoring, and OS impact).

5. Provisioning Procedures required for provisioning all aspects of the SIP platform on your switch and in your network.

switch hardware.

6. Deprovisioning Procedures required to remove the SIP

®

switch.

7. Maintenance

Considerations

application from the 5ESS Overview of troubleshooting and maintenance

specific to SIP.

8. Glossary List of acronyms used within this IP and their expansions.

9. Index Index of subjects covered within this IP.

Conventions used

No special or unusual conventions are used in this information product.

Systems supported

This information product supports software releases 5E16.2, Feature Release 3, and later.

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

,

Lucent Technologies

xix

5E16.2 and Later Software Releases

About this information product

How to comment

How to order

• Hardware Change - Degrowth Procedures, 235-105-331

• Recent Change Reference 5E16.2 Software Release, 235-118-258

• Translations Data Reference, 235-600-126

• Translations & Dynamic Data Reference, 235-600-228

• Dynamic Data Reference, 235-600-237

• Translations & Dynamic Data Domain Description, 235-600-248

• Audits Manual, 235-600-400

• Asserts Manual, 235-600-500

• Input Messages Manuals, 235-600-700

• Output Messages Manuals, 235-600-750

To comment on this information product, go to the Online Comment Form (http://www.lucent-info.com/comments/enus/) or email your comments to the Comments Hotline (comments@lucent.com).

The Lucent Technologies Learning Organization in Indianapolis, Indiana, distributes this information product. It can be ordered by phone, fax, mail, or on line. Specific ordering information is listed below. When ordering, refer to information product number

....................................................................................................................................................................................................................................

xx

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

,

5E16.2 and Later Software Releases

235-200-118, 5ESS®Switch Session Initiation Protocol (SIP) - OA&M Manual, 5E16.2 and Later. Proper billing information must be

provided. To order this information product by phone, call:

To order this information product online, logon to http://www. lucentdocs.com.

To order this information product by mail, write to the following address:

Lucent Technologies Learning Organization 2855 N. Franklin Road

About this information product

1 888 LUCENT8 (1 888 582-3688) or fax to 1 800 566-9568 (from inside the continental United States)

1 317 322-6416 or fax to 1 317 322-6699 (from outside the continental United States).

Indianapolis, IN 46219

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

,

Lucent Technologies

xxi

1 Overview

Overview

....................................................................................................................................................................................................................................

Purpose

The purpose of this chapter is to provide an overview of the following Session Initiation Protocol (SIP) features on the 5E-XC and 5E DRM:

• “SIP for Packet Trunking” (1-2) (99-5E-8382),

• “UDP Transport Layer for SIP” (1-3) (99-5E-8581),

• “Support for SIP without Preconditions” (1-3) (99-5E-8582),

• “SIP Support for Line to Packet Trunk Calls” (1-3) (99-5E-8583),

• “SIP without Encapsulated ISUP” (1-3) (99-5E-8587), and

• “SIP Enhancements to Support PSTN Gateway Phase 1” (1-3)

(99-5E-8658).

• “DRM IP Trunking” (1-4) (99-5E-8645),

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

1-1

Overview

SIP for Packet Trunking

....................................................................................................................................................................................................................................

Platform definition

Feature descriptions

Session Initiation Protocol (SIP) is a method of establishing, maintaining, and terminating internet sessions. These sessions interactively exchange real-time multimedia data (voice, text, and video) between multiple participants. SIP is based on a client-server model with intelligent end-points. End servers respond to session initiation requests and locate the called parties. SIP is an application layer protocol that can run on top of different transport protocols.

The SIP for Packet Trunking - NAR (99-5E-8382) feature adds a SIP

®

packet trunking interface to the 5ESS

®

5ESS

switch to operate as a gateway for interworking between the

switch. This feature allows the

time division multiplexing (TDM)-based public switched telephone network (PSTN) trunks and the next-generation internet protocol (IP) network virtual trunks. It interworks current circuit signaling protocols, such as Signaling System 7 (SS7) integrated services user part (ISUP), multifrequency (MF), or dual tone multifrequency (DTMF), with SIP trunk signaling over IP networks.

The SIP signaling protocol for telephony is the packet signaling protocol used to establish calls using the Optical Interface Unit Internet Protocol (OIU-IP).

The SIP for Packet Trunking feature contains:

• two new PSU2 protocol handlers (SIP-PH and the GQPH) for

setting up the SIP signaling connection,

• a new lower layer transport protocol, Stream Control

Transmission Protocol (SCTP), and

• integrated operations, administration, maintenance and

®

provisioning (OAM&P) using the conventional 5ESS

switch

interfaces.

Automatic ACM Timer - is a modification to the 99-5E-8382 feature

being implemented in software release 5E16.2 FR6. The Automatic address complete message (ACM) timer is a new field on RC/V 5.82. The timer value ranges from 4-14 seconds, with 14 seconds as the default. This timer is started at the originating packet switch (OPS) by the SIP terminal process when an INVITE message is sent to a terminating packet switch (TPS). If the timer expires, the SIP Terminal Process generates a default ISUP ACM that is sent to the

....................................................................................................................................................................................................................................

1-2

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

SIP for Packet Trunking

Overview

ISUP originating terminal process (OTP). The ISUP OTP will send an ACM message out to the ISUP network. This prevents the call from being terminated by the ISUP office because the TPS response was too slow.

The features that follow enhance the capabilities provided by the SIP for Packet Trunking feature (99-5E-8382). Feature descriptions for these features can be found in the Feature Descriptions, 235-190-400 document.

UDP Transport Layer for SIP

The UDP Transport Layer for SIP (99-5E-8581) feature allows the

™

5E-XC

allowing the 5E-XC

to support SIP with a UDP transport layer instead of SCTP,

™

to connect to SIP network elements that do not

support SCTP.

Support for SIP without Preconditions

The Support for SIP without Preconditions (99-5E-8582) feature allows SIP calls to be established without the precondition procedures that were initially required by the SIP for Packet Trunking feature. For additional information about SIP signaling procedures, with or without preconditions, see the Session Initiation Protocol (SIP) - Interface Specification, 235-900-344 document.

SIP Support for Line to Packet Trunk Calls

The SIP Support for Line to Packet Trunk Calls (99-5E-8583) feature allows analog and ISDN line originations and terminations to be routed to and from SIP packet groups, in addition to the circuit trunk originations and terminations initially supported by the SIP for Packet Trunking feature.

SIP without Encapsulated ISUP

The SIP without Encapsulated ISUP (99-5E-8587) feature allows the

™

5E-XC

to interwork with elements that do not generate and process

ISUP messages and to generate appropriate interworking messages to

™

pass through the network. The 5E-XC

supports SIP without

Encapsulated ISUP on a per packet group basis.

SIP Enhancements to Support PSTN Gateway Phase 1

The SIP Enhancements to Support PSTN Gateway Phase 1 (99-5E-8658) feature provides a series of enhancements that allow phone calls to be setup between PSTN subscribers and IP subscribers that terminate to a Telephone Application Server (TAS). The PSTN

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

1-3

SIP for Packet Trunking

Overview

Gateway sits between the IP network (using SIP signaling) and PSTN network (using ISUP signaling). The PSTN Gateway performs the interworking between SIP and ISUP protocols.

DRM IP Trunking

The DRM IP Trunking (99-5E-8645) feature extends SIP-T signaling and OIU-IP packet trunking to the DRM.

Feature descriptions for the features listed above can be found in the Feature Descriptions, 235-190-400 document.

Benefits

SIP is an emerging IP-based protocol that is critical for deploying converged and next generation real-time voice, data and video communication services. SIP for Packet Trunking gives the 5ESS

®

switch direct access to more efficient IP transport networks. It allows for the utilization of more cost-effective revenue-generating services. It also can be used to expand trunking capacity or to replace existing circuit trunks.

SIP for Packet Trunking:

• reuses the embedded network equipment to migrate to an all IP

multimedia network,

• provides high quality service with 99.999% hardware and

software reliability,

®

• reuses existing integrated 5ESS

switch OAM&P interfaces,

• supports inter-operability with other vendors equipment through

development based on industry standards,

• reuses existing switch hardware and software infrastructure,

• interfaces with the TDM-based PSTN trunks or next generation

IP network virtual trunks, and

• can use SCTP to provide additional network security.

Differences

The existing TDM network contains dedicated circuits between two end-points. IP calls have no fixed connections. Calls are dynamically routed through the packet network based on available bandwidth. The connection information is exchanged using SIP signaling.

The migration from an expansive SS7-based signaling transfer point (STP) network to an IP-based signaling network will be ongoing. As SIP evolves, more capabilities will be defined and added.

....................................................................................................................................................................................................................................

1-4

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

SIP for Packet Trunking

Overview

Secured features

Availability

The features that follow are secured features listed with the associated secured feature IDs (SFIDs). Recent Change view 8.22 is used to activate these features. Refer to “Feature Activation (RC/V 8.22)”

(5-13) for the procedure.

• SIP for Packet Trunking (SFID 684)

• SIP without Encapsulated ISUP (SFID 769)

The following list provides the availability for SIP related features:

• SIP for Packet Trunking (feature 99-5E-8382) is available with

the 5E16.2 FR3 software release or later.

• UDP Transport Layer for SIP (feature 99-5E-8581) and Support

for SIP without Preconditions (feature 99-5E-8582) are available with 5E16.2 FR5 software release or later.

• SIP without Encapsulated ISUP (feature 99-5E-8587) and SIP

Enhancements to Support PSTN Gateway Phase 1 (feature 99-5E-8658) are available with the 5E16.2 FR6 software release or later.

Deployment

Background knowledge

• The DRM IP Trunking (99-5E-8645) feature is available with the

5E16.2 FR 9 software release or later.

This platform is provided on a per office basis.

When SIP is used in media gateway controllers for call establishment, there are many cases where it must bridge the PSTN network with IP networks. To do this, SIP must be extended to transport all of the PSTN signaling information transparently. By extending SIP messaging and adding PSTN signaling encapsulation functionality, the SIP protocol can be used for media gateway to media gateway communication.

Interfacing with a IP network requires an understanding of the following IP concepts and equipment:

• routers and Layer 2 (L2) switches,

• Ethernet,

• internet protocol and internet control message protocol (ICMP),

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

1-5

SIP for Packet Trunking

Overview

• transport protocols like SCTP and user datagram protocol (UDP),

and

• SIP standards and protocols.

Hardware Dependencies

Software Dependencies

The Optical Interface Unit - Internet Protocol (OIU-IP) hardware (feature 99-5E-8308) needs to be installed and active.

Other hardware required to support this feature includes two types of protocol handlers (PHs); the PHE2 to support the SIP PH functionality, and the PH33 to support the General Quad-link Package Switch (QLPS) PH (GQPH), as well as the following:

• SM2000 switching modules,

• QLPS,

• Packet Switch Unit - Model 2 (PSU2), and

• Data Fanout - Model 2 (DF2).

Note: This QLPS and PH33 are not required on the DRM/VCDX. Refer to Chapter 4, “Engineering Considerations” for a list of the

required hardware.

The following software components are needed:

• new SIP signaling software supported by SCTP or UDP for

transport,

• software to support the optical facility interface (OFI) circuit

pack hardware delivered with the Optical Interface Unit for NAR Market feature (99-5E-7140),

• software to support the optical facility interface internet protocol

(OFI-IP) circuit pack hardware delivered with the Optical Interface Unit - Internet Protocol feature (99-5E-8308), and

• operational support system (OSS) enhancements.

Incompatibilities

Feature Interactions

There are no incompatibilities with other features.

SIP for Packet trunking defines the signaling protocol to control the bearer transport delivered with the Optical Interface Unit - Internet Protocol (OIU-IP) feature (99-5E-8308).

SIP for Packet Trunking that uses UDP Transport Layer for SIP (99-5E-8581) requires Support for SIP without Preconditions

....................................................................................................................................................................................................................................

1-6

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

SIP for Packet Trunking

Overview

(99-5E-8582). Both features are dependent on the base SIP feature (99-5E-8382).

The SIP without Encapsulated ISUP feature (99-5E-8587) is dependent on the base SIP feature (99-5E-8382). The SIP without Encapsulated ISUP feature is transport independent.

The SIP Enhancements to Support PSTN Gateway Phase 1 (99-5E-8658) is dependent on the base SIP feature (99-5E-8382).

The DRM IP Trunking (99-5E-8645) is dependent on the base SIP feature (99-5E-8382).

Inter-operability

One of the main objectives of SIP is to provide call signaling and call control independent of the IP network technology.

Inter-operability with IP equipment

The IP router or Layer 2 (L2) switch to which the 5ESS®switch protocol handlers (PHs) interface can be from any vendor, provided that it meets the requirements of the Session Initiation Protocol (SIP)

- Interface Specification, 235-900-344 document.

®

The IP network components and the 5ESS

switch can be configured many different ways. The different configurations are described in “IP

Router & Layer 2 Switch Interoperability” (2-15).

Inter-operability with other Switching Systems

SIP for Packet Trunking is based on standards for the protocol layers including SIP, SCTP, and/or UDP, IP, and ICMP, and the software is intended to operate with other vendors. However, this feature works

®

best when used with other 5ESS

switches. If another vendor’s switch adheres to the standards in the same way, the products should be compatible. No assumptions are made about inter-operability with other vendor’s equipment.

The Session Initiation Protocol (SIP) - Interface Specification, 235-900-344 document explains the interface implementation in greater detail.

Customer Security

It is the customer’s responsibility to ensure the security of the IP backbone network. It is assumed that the IP layer security is

®

performed by the edge router and that the 5ESS

switch is in a trusted

network.

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

1-7

SIP for Packet Trunking

Overview

Industry standards

SIP for Packet Trunking is based on standards by the Internet

™

Engineering Task Force (IETF) and Telecordia

Technologies.

SIP standards continue to be defined and extended. Some standards are in draft form and, in some cases, incomplete or not well defined. In some instances, standards could not be followed simply because no standard exists.

IETF RFC Title

RFC 3261 SIP: Session Initiation Protocol RFC 2960 Stream Control Transmission Protocol RFC 768 User Datagram Protocol RFC 791 Internet Protocol RFC 792 Internet Control Message Protocol RFC 1122 Requirements for Internet Hosts -- Communication

Layers RFC 1332 The PPP Internet Protocol Control Protocol (IPCP) RFC 1661 The Point-to-Point Protocol (PPP) RFC 1662 PPP in HDLC-like Framing RFC 2474 Definition of the Differentiated Services Field (DS

Field) in the IPv4 and IPv6 Headers RFC 2615 PPP over SONET/SDH RFC 1878 Variable Length Subnet Table for IPv4 RFC 1918 Address Allocation for Private Internets RFC 917 Internet Subnets RFC 1519 Classless Inter-Domain Routing (CIDR): an Address

Assignment and Aggregation Strategy RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1 RFC 2665 Definitions of Managed Objects for the Ethernet-like

Interface Types RFC 2011 SNMPv2 Management Information Base for the Internet

Protocol using SMIv2 RFC 2013 SNMPv2 Management Information Base for the User

Datagram Protocol using SMIv2 RFC 3372 Session Initiation Protocol for Telephones (SIP-T):

Context and Architectures

....................................................................................................................................................................................................................................

1-8

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

SIP for Packet Trunking

Overview

IETF RFC Title

RFC 3204 MIME Media Types for ISUP and QSIG Objects RFC 2327 SDP: Session Description Protocol DRAFT

The Session Initiation Protocol (SIP) Refer Method

RFC 3515 DRAFT Redirection Service Capability in the Session Initiation

Protocol (SIP)

DRAFT The Stream Control Transmission Protocol as a

Transport for the Session Initiation Protocol

RFC 3312 Integration of Resource Management and Session

Initiation Protocol (SIP)

RFC 3262 Reliability of Provisional Responses in the Session

Initiation Protocol (SIP) DRAFT Session Initiation Protocol Service Examples DRAFT Using ENUM for SIP Applications RFC 3398 ISUP to SIP Mapping

Telcordia Technologies

Title

GRs

GR-253-CORE Synchronous Optical Network (SONET)

Transport Systems: Common Generic Criteria

GR-474-CORE Network Maintenance: Alarm and

Control for Network Elements

GR-782-CORE SONET Digital Switch Trunk Interface

Criteria

GR-3053-CORE Voice over Packet (VoP): Next

Generation Network (NGN) Signaling Gateway Generic Requirements

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

1-9

2 Architecture

Overview

....................................................................................................................................................................................................................................

Purpose

This chapter contains information about the Session Initiation Protocol

®

(SIP) architecture and how it is integrated within the 5ESS

switch.

This chapter describes the SIP architecture from a:

• network view,

• system view,

• signaling view,

• hardware view, and

• security view.

Network View

The network view describes the SIP architecture at a network level between network elements.

System View

The system view contains SIP architecture information within a

®

5ESS

Signaling View

switch.

The signaling view explains the following SIP signaling transports

• Stream Control Transmission Protocol (SCTP)

• User Datagram Protocol (UDP)

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-1

Overview

Architecture

Hardware View

The hardware view provides information about the various hardware components that are required to implement SIP for Packet Trunking.

Security View

The security view describes the cookie mechanism implemented in

®

SCTP and how it protects the 5ESS

switch.

....................................................................................................................................................................................................................................

2-2

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Architecture

Network View

....................................................................................................................................................................................................................................

Overview

IP Backbone

The 5ESS®switch interfaces to internet protocol (IP) packet networks using integrated packet trunking. SIP is a packet call signaling protocol that offers a means to inter-operate with packet trunking interfaces between network elements. SIP signaling uses the packet switch unit model 2 (PSU2) to establish calls on the optical interface unit-internet protocol (OIU-IP) integrated gateway.

Figure 2-1 IP Backbone

PSTN

®

5ESS Switch

IP Network

®

5ESS Switch

®

5ESS Switch

Signaling Path Bearer Path

POTS Subscriber ISDN Subscriber IP Subscriber

Telephone Application

Server (TAS)

SIP for packet trunking and its related features provide the

®

functionality that allows the 5ESS

switch to interface to an IP network. The signaling network, which uses session initiation protocol (SIP), and bearer network can be located on distinct physical networks, on one common network, or on distinct logical networks

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-3

Network View

Architecture

over a single physical network. Figure 2-1, “IP Backbone” (2-3) illustrates one common network. Figure 2-5, “Packet Trunking” (2-7) illustrates distinct networks.

Signaling Network

From a hardware perspective, each network element, such as end offices (EO), EO-local tandems (LT), and EO-access tandems (AT), in the SIP signaling network is connected to the IP network. Signaling messages between network element are dynamically routed by the IP network.

Figure 2-2 SIP Signaling Network, Hardware Perspective

AT

EO

TAS

IP Network

EO

EO = End Office AT = Access Tandem LT = Local Tandem TAS = TelephoneApplication

Server

EO

LT

TAS

Figure 2-2, “SIP Signaling Network, Hardware Perspective” (2-4)

shows the signaling network for an IP network using SIP from a

....................................................................................................................................................................................................................................

2-4

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Network View

Architecture

hardware perspective. The IP network fully interconnects all of the network elements.

Figure 2-3 SIP Signaling Network, Provisioning Perspective

AT

EO

Bearer Network

EO

IP Network

LT

TAS

EO

EO = End Office AT = Access Tandem LT = Local Tandem TAS = TelephoneApplication

Server

Figure 2-3, “SIP Signaling Network, Provisioning Perspective” (2-5)

shows the signaling network from a provisioning perspective. Each network element must know about all other network elements to which it is interconnected.

The bearer network looks the same from both a hardware and provisioning perspective. Each termination is defined but there are no

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-5

Network View

Architecture

fixed paths. The path between two network elements is allocated dynamically on a call by call basis.

Figure 2-4 Bearer Network

AT

EO

TAS

IP Network

EO

LT

TAS

EO

EO = End Office AT = Access Tandem LT = Local Tandem TAS = TelephoneApplication

Server

Figure 2-4, “Bearer Network” (2-6) shows that the bearer trunks are

connected to the central IP hub. For a packet call between two network elements, an IP association is created between two endpoints, but no fixed paths through the IP network are provisioned.

....................................................................................................................................................................................................................................

2-6

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Network View

Packet Trunking

Figure 2-5 Packet Trunking

Originating Switch

Architecture

Terminating Switch

PSTN

IP Signaling Network

Edge RouterEdge Router

Ethernet Ethernet

DNU-S DNU-S

OPS

PSU2

OIU-IP

Edge Router Edge Router

PSU2

OIU-IP

OC-3cOC-3c

TPS

IP Bearer Network

Figure 2-5, “Packet Trunking” (2-7) illustrates a packet trunking

network. In this network, 5ESS®switches connect to IP switches and IP routers connected in order to provide end-to-end routing of

®

information. An end office (EO), the 5ESS

switch, connects to an

edge router to access the IP network. The two packet offices shown

®

are 5ESS

switches; however, either can be other vendor switches as long as they support IP packet trunking with SIP signaling. An Ethernet link connects the PSU2 to an edge router to provide the signaling path. A Synchronous Optical Network (SONET) optical carrier - level 3 concatenated (OC-3c) link connects the OIU-IP and the router for the voice path.

Calls using packet trunking are dynamically allocated to available packet network interface bandwidth each time a call is established, whereas calls using time division multiplexing (TDM) trunking are assigned to circuits or connections dedicated to two endpoints. In packet trunking, call and connection information is exchanged using SIP signaling and voice packets are transmitted, routed and received

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-7

Network View

Public Switched

Telephone Network (PSTN)

Gateway

Architecture

between two switches using the pair of dynamically allocated packet interfaces that acts as a virtual trunk.

Figure 2-6 PSTN Gateway

PSTN

®

5ESS Switch

IP Network

5ESS Switch

PSTN Gateway

Telephone Application

Signaling Path Bearer Path

POTS Subscriber ISDN Subscriber IP Subscriber

Server (TAS)

The PSTN Gateway application allows phone calls to be setup

®

between PSTN subscribers that terminate to a 5ESS

switch and IP subscribers that terminate to a Telephone Application Server (TAS). The PSTN Gateway sits between the IP network (using SIP signaling) and PSTN network (using ISUP signaling). Figure 2-6, “PSTN

Gateway” (2-8) illustrates how the PSTN gateway fits into the

network. The PSTN Gateway performs the interworking between SIP and ISUP protocols.

....................................................................................................................................................................................................................................

2-8

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Architecture

System View

....................................................................................................................................................................................................................................

Overview

Architecture

This section identifies the different components and describes their function in the SIP architecture.

The SIP for Packet Trunking feature advances the architecture of the

®

5ESS

switch with the introduction of several components. Existing hardware and software components, including the administrative module (AM), communication module (CM), switching module 2000 (SM-2000), and peripheral units, are preserved.

Figure 2-7 SIP Architecture

To/From OSS

CM

CMP

GQPH

Qpipes

SM-2000 for

SIP call processing

MH

Qpipes

TSI

terminating

terminal process

GSM-2000 for SIP Signaling

To/FromSMP

CF2

SIP

SM-2000 for IP Bearer

SMP

IP Bearer Trunks

over OC-3c

IP bearer terminal process

OIU-IP

MH

TSI

SM-2000 for TDM Bearer

and call processing

MH

Qpipes

MH

Qpipes

AM

MSGS

TMS

QLPS

SMP

PSU2

SMP

MH

OIU-TDM

DS0 circuits

TSI

- new hardware

GQPH

D F

Non-Serving

Serving

2

SIP PH

SIP Signaling over Ethernet

P F 2

Figure 2-7, “SIP Architecture” (2-9) illustrates the SIP call signaling

and bearer architecture. The signaling components within the packet switch unit model 2

(PSU2) include the:

• general QLPS protocol handler (GQPH), and

• session initiation protocol - protocol handler (SIP PH).

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-9

System View

Architecture

Note: The GQPH is only required on for non-DRM/VCDX. The packet trunking bearer is handled by the optical interface unit -

internet protocol (OIU-IP). Refer to Figure 2-7, “SIP Architecture” (2-9) when reading the

following hardware descriptions.

....................................................................................................................................................................................................................................

2-10

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

System View

Architecture

Note:Figure Figure 2-7, “SIP Architecture” (2-9) is the non-DRM/VCDX architecture. See figure Figure 2-8, “SIP on DRM

Architecture” (2-11) showing the architecture on the DRM .

Figure 2-8 SIP on DRM Architecture

AM/CM

DRM

PI

SIP PH

SMP

SIP PH

Circuit Line or

Trunk Unit

SIP-T TP

TSI

Bearer TP

OIU-IP

PSU2

SIP Signaling over Ethernet

IP Packet Bearer

Over OC3C

Administrative Module (AM)

SIP operations, administration, maintenance and provisioning

®

(OAM&P) are integrated within the 5ESS

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

switch. The administrative

2-11

System View

Architecture

module (AM) is the integrated element management system (EMS) of

®

the 5ESS

switch and provides the interface to the operations support systems (OSSs). The OSS network includes the circuit OSS products for traditional public switched telephone network (PSTN) equipment.

Communication Module (CM)

The CM hardware remains unchanged. The CM consists of the message switch (MSGS) and the time multiplexed switch (TMS).

The communication module processor (CMP) is one of several functions within the MSGS. To support the SIP feature, the CMP selects an SM-2000 to process SIP call signaling for outgoing calls when destined for routes over packet groups controlled by SIP signaling. The CMP also selects the SM-2000 with an available OIU-IP for the bearer connection for both incoming and outgoing calls. Note: The CMP functions for SIP on the non-DRM/VCDX described here are carried out on the Switching Module Processor (SMP) for SIP on the DRM (other than selecting an SM, which isn’t required on DRM, since there is only the one SM).

Within the TMS, the quad link packet switch (QLPS) terminates QLPS endpoints, e.g. message handlers (MHs). SIP introduces the GQPH which is a new QLPS endpoint. Messages are sent between the QLPS and GQPH over a logical connection called a GQPH Qpipe. Connections between the GQPH and the call processing SMs are established over QLPS logical links. These connections are used to carry SIP related signaling messages between the SMs and the SIP PHs. The fabric of the TMS is used when different SMs are used for the TDM and IP bearer connections. In addition, any messaging between two SMs and between an SM and the AM goes through the CM. Note: This paragraph only applies to non-DRM/VCDX, there is no QLPS or GQPHs on the DRM/VCDX.

Global Switching Module-2000 (GSM-2000)

The GSM-2000 supports the PSU2. It is recommended that this module be set-up to provide only signaling.

Below is a partial list of status tracked by the GSM-2000 when supporting the SIP feature:

• SIP PHs,

• Ethernet links,

• processor groups,

....................................................................................................................................................................................................................................

2-12

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

System View

Architecture

• GQPHs, and

• SCTP associations and association sets.

Note: The GQPHs are only on the non-DRM/VCDX.

Packet Switch Unit Model 2 (PSU2)

The PSU2 is the signaling message distribution point for SIP

®

messages between the near 5ESS

switch and the far 5ESS®switch.

To support the SIP feature the PSU2 is equipped with SIP PHs and GQPHs.Note: The GQPHs are only on the non-DRM/VCDX.

Session Initiation Protocol Protocol Handler (SIP PH)

The SIP PH is a logical protocol handler that uses the PHE2 hardware. The SIP PH performs the message parser, message reformer, and transaction manager functions for SIP messages.

For outgoing messages, the SIP signaling terminal process in a SMP sends SIP related call information to the SIP PH and the SIP PH constructs a:

1. SIP header message with call routing information, and a

2. SIP message body with application data. For incoming messages, the SIP PH:

1. validates and translates SIP messages, and

2. delivers the data to the SIP signaling terminal process for processing by the call processing programs.

The SIP PH converts message data between SIP messages and an internal protocol used by the SMP. The internal messages are transported between the SIP PH and the SMP by the GQPH.

The SIP PHs are configured as processor groups each having one or two PHs. When redundancy is desired and processor groups are provisioned in pairs, one SIP PH will dynamically be assigned the “serving” role and the other as the “non-serving” role. During normal operations, the serving SIP PH provides the non-serving SIP PH with stable call data. Should the serving SIP PH fail, stable calls will be preserved. Refer to “Serving/Non-Serving” (2-30) for more details.

A 100BaseT Ethernet interface is used to pass SIP messages between the serving SIP PH and the IP network.

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-13

System View

Architecture

General QLPS Protocol Handler (GQPH)

The GQPH is a logical protocol handler that uses the PH33 hardware type. The GQPH supports message routing between a SIP PH and the SMP used for SIP call control. For outgoing messages sent from the SMP to the SIP PH, the GQPH forwards messages to the serving PH. For incoming calls, the GQPH forwards messages from the SIP PH to one of the QLPSs, which then forwards the message to the correct SM. The GQPH communicates with the QLPS network over logical connections called GQPH Qpipes.Note: The GQPHs are only on the non-DRM/VCDX.

Switching Module-2000 (SM-2000)

The SM-2000 provides IP packet trunking. The SMP terminal processes coordinates establishing the signaling and bearer connections between the originating and terminating network element. The bearer terminal process selects the OFI-IP for the voice connection. The signaling terminal process coordinates call information between the two network elements.

Optical Interface Unit-Internet Protocol (OIU-IP)

The OIU-IP on the 5ESS®switch provides the packet network interface for bearer traffic. Calls are switched in the time slot interchange (TSI) and an optical facility interface-internet protocol (OFI-IP) in the OIU-IP performs synchronous-to-asynchronous conversion (SAC) to transport the voice stream from the TDM network to the packet network.

The OFI-IP hardware control software interacts with the SM-2000 switching module processor (SMP) peripheral control using the proprietary protocol. Real-time maintenance orders and reports are also sent using the proprietary protocol to support OAM&P activities. An OFI-IP protection group (PG) supports interconnection to an IP edge router using OC-3c facilities with 1+1 automatic protection switching (APS).

....................................................................................................................................................................................................................................

2-14

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

System View

Architecture

IP Router & Layer 2

Switch Interoperability

The 5ESS®switch can interface with a number of IP network configurations. Figure 2-9, “Sample Configurations” (2-15) provides some examples of configurations that may be used.

Figure 2-9 Sample Configurations

R

L2

SIP PH

E

SIP PH

E

( a ) Separate pairs of L2 switches

and IP routers, SIP PH/Ethernet are a serving/non-serving pair.

R

L2

R

L2

E

SIP PH SIP PH

E

( b ) Integrated pair of L2 switches

and IP routers.

P

S U 2

P S

U

2

R R

VRRP

Pair

L2 L2

E

SIP PH

E

SIP PH

P S

U 2

( c ) VRRP pair providing access routing function,

plus physical L2 switches (VRRP pair appears as a single IP router to the 5ESS switch).

Legend R access router L2 Layer 2 switch E Ethernet link SIP PH SIPprotocol handler PSU2 Packet Switching Unit 2 VRRP Virtual Router Redundancy Protocol

R

The configuration shown in example “a”, uses a pair of layer 2 switches along with a separate pair of routers. This configuration can be used in cases where the routers used cannot support the layer 2 functionality. When used with the SCTP capability to support multiple IP paths, as well as with the SIP PH’s ability to monitor the status of

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-15

System View

Architecture

its reachability to the access routers, this configuration can achieve a significantly high level of reliability.

The configuration shown in example “b” is recommended when the router can support both the layer 2 function and routing function. This configuration would be expected to provide similar reliability to configuration “a”.

The configuration shown in example “c” using a pair of routers configured as a virtual router redundancy protocol (VRRP) pair can provide reliability in networks in where SCTP multihoming capability is not widely supported. If SCTP multihoming is widely supported, operating the routers independent of each other would be preferable.

Some considerations when selecting a configuration are the capabilities of the existing IP equipment, the desired level of reliability, the provisioning effort, and cost.

....................................................................................................................................................................................................................................

2-16

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Architecture

Signaling View

....................................................................................................................................................................................................................................

Overview

The 5E-XC supports SIP on the following transport layers:

• Stream Control Transmission Protocol (SCTP)

• User Datagram Protocol (UDP)

This section defines the concepts of endpoints, associations, and association sets for the stream control transmission protocol (SCTP), transport layer, and the concept of UDP paths for the UDP transport layer.

Figure 2-10, “SIP Protocol Stack” (2-17) shows the protocol stack

supporting SIP signaling with either a SCTP or UDP transport layer.

Figure 2-10 SIP Protocol Stack

SIP

SCTP/UDP

IP/ICMP

Ethernet

100BaseT

For more detailed information about the layers of the protocol stack refer to the Session Initiation Protocol (SIP) - Interface Specification, 235-900-344 document.

Transport Layer Comparison

Table 2-1, “TCP/UDP/SCTP Comparison” (2-17) highlights some of

the differences between the TCP, UDP, and SCTP transport layers.

Table 2-1 TCP/UDP/SCTP Comparison

TCP UDP SCTP

byte-oriented stream message-oriented

stream

multiple sockets use more resources

simpler protocol

needs less resources single-homed single-homed multi-homed vulnerable to

synchronize (SYN) bit packet attacks

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

connectionless

protocol is vulnerable

to attack

message-oriented stream

multiple streams uses less resources

4-way association startup procedure, security cookie

2-17

Signaling View

Architecture

Stream Control

Transmission Protocol

(SCTP)

SIP can use stream control transmission protocol (SCTP) to provide reliable end-to-end transport over an IP based network.

The benefits of using SCTP over transmission control protocol (TCP) or user datagram protocol (UDP) for transport are:

• improvements on the weaknesses of TCP and UDP for telephony

applications,

• provides the reliability of multiple paths between endpoints (per

association), and

• suitability for applications beyond SIP. The Session Initiation Protocol (SIP) - Interface Specification,

235-900-344 document explains the interface implementation in greater detail.

Endpoints

An SCTP endpoint is assigned to a processor group and each endpoint is identified by an address known as the SCTP transport address. An SCTP transport address consists of an SCTP port number and a list of one or more IP addresses. The SCTP transport address uniquely identifies an SCTP endpoint. The SCTP port number is used to send and receive messages. Each SIP PH processor group in an office can support one SCTP endpoint. Refer to Figure 2-11, “SCTP Endpoints”

(2-19).

An endpoint with more than one IP address in its SCTP transport address list is called a multi-homed SCTP endpoint. An endpoint can be configured with multiple network interface cards (NIC) each with its own IP address, or multiple IP addresses can be assigned to one

®

NIC. On the 5ESS

switch, the SIP PH processor group is the NIC and it can be assigned two IP addresses. When two IP addresses are assigned to a SIP PH processor group, at any one time one will be the serving SIP PH and the other will be the non-serving SIP PH. Both IP addresses will be assigned to the SIP PH performing the serving function.

An upper layer protocol like SIP may need to communicate with peers physically accessed through separate IP networks. In this case, an

....................................................................................................................................................................................................................................

2-18

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Signaling View

OfficeA Office B

Architecture

SCTP endpoint is established in each network on which a far, peer SIP entity resides.

Figure 2-11 SCTP Endpoints

Packet Group

7000

SIP PH

NIC SCTP Port: 5060 IP1: 144.12.1.20

IP2: 144.12.1.21

IP Network

Edge

Router

SCTP Endpoint SCTP Endpoint

Edge

Router

Association

An SCTP association is a protocol relationship between SCTP endpoints. It is composed of the two SCTP endpoints and protocol state information including verification tags and the currently active set of transmission sequence numbers (TSNs). An association is uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints can not have more than one SCTP association between them at any given time.

The SCTP layer initially establishes communication between two endpoints. The establishment of the SCTP association between the two endpoints is done with a cookie mechanism that results in the creation of a transmission control block (TCB). The TCB contains information about the endpoints and parameters governing how the endpoints will communicate. Figure 2-18, “Cookie Mechanism” (2-36) illustrates the exchange.

Packet Group

7500

SIP PH

NIC

SCTP Port: 5060

IP1: 161.54.15.6

IP2: 161.54.15.7

Below are the steps used to establish an association.

1. The four-way handshake is initiated by the initializing packet switch with an INIT message.

2. The far packet switch creates a cookie and sends it to the first packet switch in an ACK message.

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-19

Signaling View

Architecture

3. The first packet switch returns the cookie in an ECHO message to the far packet switch.

4. The far packet switch validates the cookie information and returns the cookie in an ACK message.

The endpoint at the initial packet switch is associated with the endpoint at the terminating packet switch through mutual knowledge by the TCBs and the implicit agreement to transmit messages to and receive messages from each other. Either endpoint in an association is allowed to initiate the establishment of the association.

Only one association may exist between two SCTP endpoints. However, a number of concurrent SCTP signaling flows may exist between those endpoints. In SCTP, these flows are called streams. Each SIP message contains an association and a stream number. Messages that are part of the same transaction are given the same stream number. For example, all SIP messages associated with a given call are carried over the same SCTP stream.

One near endpoint can also be associated with multiple far endpoints.

Figure 2-12, “Multiple SCTP Associations” (2-21) illustrates office A

containing one endpoint that has associations with more than one

....................................................................................................................................................................................................................................

2-20

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Signaling View

office. Although the illustration shows the office with only one endpoint, it may actually have many endpoints and associations.

Figure 2-12 Multiple SCTP Associations

R

5ESS Switch

Office B

R

5ESS Switch

Office C

SCTP

Endpoint

R

5ESS Switch

Office A

SCTP

Endpoint

Architecture

SCTP

Endpoint

R

5ESS Switch SCTP Endpoint 1 of n

Office A

Associations in the 5ESS

5ESS Switch

Association 1

{

Association 4

R

Office E

SCTP

Endpoint

R

5ESS Switch

R

5ESS Switch

R

5ESS Switch

R

5ESS Switch

®

switch are static and they are determined

R

5ESS Switch

Office D

SCTP

Endpoint

Office B, SCTP Endpoint Office C, SCTP Endpoint

Office D, SCTP Endpoint Office E, SCTP Endpoint

by the provisioning. Associations are established when a SIP PH pair is initialized.

IP Netw o r k

Paths

An association is a method to logically link two endpoints together to transfer data. A path is the physical route through the network between two associated endpoints. The number of paths from one endpoint to another depends on the number of transport addresses homed on each endpoint. Single-homed association endpoints have only one path between two endpoints. Multi-homed endpoints have more than one path between two endpoints. For example, if an

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-21

Signaling View

Architecture

association exists between two endpoints and both have two IP addresses assigned, there are four potential paths. Figure 2-13, “Paths

Between Endpoints” (2-22) shows multi-homed endpoints (Endpoint 1

and Endpoint 2) with each SIP PH being assigned two IP addresses. The number of paths to the destination endpoint is based on the number of destination IP addresses. The number of source IP addresses is only relevant to the far packet switch. In Figure 2-13,

“Paths Between Endpoints” (2-22), from Endpoint 1 to Endpoint 2

there are two paths and from Endpoint 2 to Endpoint 1 there are two paths.

Figure 2-13 Paths Between Endpoints

Endpoint 1

Endpoint 2

IP Address A

IP Address B

Path 4

E

Path 3

Path 1

Path 2

IP Address C

E

IP Address D

The advantage of multi-homed endpoints is they provide multiple paths in the IP network. If a specific path is out of service or failing, an alternate path can be used to send messages.

Association Sets

Association sets are unique to the 5ESS®switch. An association set is a grouping of SCTP associations. The purpose of an association set for the SIP capability is to support the transport of the SIP messages used to establish calls over a particular packet group.

Association sets minimize these limitations of associations:

• capacity mismatch of the two endpoints,

• provisioning limitations for the number of associations, and

• inability to route calls on non-functioning associations.

Association set are analogous to signaling link sets in Signaling System 7 (SS7) networks.

The associations pertaining to a given association set can be assigned across multiple processor groups. Thus, the call signaling pertaining to a given packet group can be load-shared across multiple processor groups.

....................................................................................................................................................................................................................................

2-22

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Signaling View

Architecture

User Datagram Protocol

(UDP)

When routing new calls to a particular packet group, the 5ESS

®

switch will avoid selecting any SCTP associations that are not functioning properly. This increases the reliability of the signaling pertaining to a packet group.

SIP can use User Datagram Protocol (UDP) in place of SCTP to provide the transport layer over an IP-based network, if adjacent network elements support UDP, but not SCTP. The use of UDP transport simplifies data provisioning, but lacks some of the benefits offered by SCTP, most notably the multi-homing and multi-stream capabilities.

Because UDP is a connectionless, stateless, unreliable protocol, the SIP layer is enhanced to handle retransmission of SIP messages and to react to “Destination Unreachable” indications from the IP network when the transport layer is UDP.

Paths

The 5E-XC™supports provisioning of UDP paths to identify the near-end processor group, IP address and UDP port number, and far-end IP address, and UDP port number to be used by the transport layer for sending and receiving SIP messages over UDP for a particular packet group. These UDP paths, however, have no independent status and cannot be separately maintained (i.e., cannot be manually removed or restored).

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-23

Architecture

Hardware View

....................................................................................................................................................................................................................................

Overview

Basic Description

This feature introduces two protocol handlers, the PHE2 and PH33. However, the terms SIP PH and GQPH are used to indicate that the PHE2 operates as a SIP PH and the PH33 operates as a GQPH, to be consistent with the document unless otherwise noted.

SIP PH Channel Group

The SIP PH channel group (logical protocol handler type) uses the PHE2 protocol handler. The PHE2 is a member of the PH30 family of protocol handlers. The PHE2 supports one 100BaseT paddle board.

Table 2-2, “SIP PH Characteristics” (2-24) lists some key

characteristics.

Table 2-2 SIP PH Characteristics

Channel Group Type SIPT CLI 0x20000 Software Image PHE2S Hardware Type PHE2 Pack Code TN13 Paddle Board Code LLE2 (Ethernet)

The LLE2 paddle board is located on the back side of the PSU2 and is mounted directly behind its associated SIP PH. The LLE2 provides the termination for one Ethernet link.

Refer to Hardware Description, 235-100-200 for additional information on the PHE2 and LLE2 paddle board.

GQPH Channel Group

The GQPH channel group (logical protocol handler type) uses the PH33 protocol handler. Like the PHE2, the PH33 is a member of the PH30 family of protocol handlers. Table 2-3, “GQPH Characteristics”

(2-24) lists some key characteristics.

Table 2-3 GQPH Characteristics

Channel Group Type GQPH CLI 0x880

....................................................................................................................................................................................................................................

2-24

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Hardware View

Architecture

Table 2-3 GQPH Characteristics (continued)

Software Image PH33Q Hardware Type PH33 Pack Code TN113

Note: The GQPHs are only on the non-DRM/VCDX. Refer to Hardware Description, 235-100-200 for additional

information on the PH33.

Pack physical

characteristics

Each SIP PH or GQPH circuit pack is located in a PH slot as required. They each contain two amber LEDs in the faceplate. Refer to Figure 2-14, “Pack Faceplates” (2-26) for an example of the SIP PH and GQPH faceplates and LEDs. Both the out-of-service (OOS) and signal fail (SF) LEDs are illuminated when the packs are removed from service. The SF LED, on the SIP PH only, is also illuminated when there is no signal from the Ethernet termination.

The LLE2 paddle board is located on the back side of the PSU2. One paddle board is attached to the upper pin field directly behind the corresponding SIP PH. The paddle board is equipped with an SF LED. The SF LED is illuminated when there is no signal from the

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-25

Hardware View

Architecture

Ethernet cable. At the bottom of the paddle board there is a connector for the Ethernet cable. Refer to Figure 2-14, “Pack Faceplates” (2-26).

Figure 2-14 Pack Faceplates

SIP PH & GQPH

Circuit Packs

LLE2 Paddle Board

SF LED

OOS LED

SF LED

Ethernet

Termination

PSU2 shelf arrangement

Legend:

OOS - Out of Service SF - Signal Fail

Figure 2-15, “PSU2 Shelf Arrangement” (2-27) provides the general

layout of a PSU2 shelf. The shelf shown is the common shelf (shelf

0). A fully equipped PSU2 consists of five shelves; the common shelf

and four growth shelves.

....................................................................................................................................................................................................................................

2-26

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Hardware View

Architecture

The PSU2 shelves can be located in the following vertical EQLs: 19, 28, 45, 53 and/or 62.

Figure 2-15 PSU2 Shelf Arrangement

Power Bus - A Power Bus - B

PH Slot Number

0

EQL

006 014

* Note: the CF2 packs are located in the common shelf only.

PSU2 shelf power

C

12

3

030 038

022

PH Slots PH Slots

5

4

67 8910

046 054 062 070 078 088 100 110 120 128

F

2

*

PSUCOM 0

D

P

F

2

P

D F 2

PSUCOM 1

C

F

2

*

136

11 12

152 160 168 176 184

144

When the shelf is equipped with PHs to support SIP for Packet Trunking, any of the PH slots can be used. If a processor group consists of two SIP PHs, the SIP PHs can either be on the same PSU2 shelf or different shelves. Each shelf that has one or more GQPH channel groups assigned to it should have at least one spare PH33.

A separate power bus provides power to each half of a PSU2 shelf. Refer to Figure 2-15, “PSU2 Shelf Arrangement” (2-27)

13

14

15

Each shelf receives power through six 10 amp fuses. Specifics on the EQLs and slots powered by each fuse can be found in Table 2-4,

“PSU2 shelf power terminations” (2-27). The table also provides a

reference to the -48V termination.

Table 2-4 PSU2 shelf power terminations

Power

Bus

A 006-030 PH 0-3 10 amp 02-028-006 A 038-062 PH 4-7 10 amp 02-060-006 A 070-088 PSUCOM 0 10 amp 02-086-006

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

Shelf EQLs

Powered

Slots Fuse

Value

Back Plane

Termination

2-27

Hardware View

Architecture

Table 2-4 PSU2 shelf power terminations (continued)

Cabling

Connecting circuits

Power

Bus

B 100-120 PSUCOM 1 10 amp 02-108-006 B 128-152 PH 8-11 10 amp 02-134-006 B 160-184 PH 12-15 10 amp 02-166-006

Shelf EQLs

Powered

Slots Fuse

Value

Back Plane

Termination

The PHs should be spread across power buses and fuses. Refer to

Chapter 4, “Engineering Considerations” for more specific

recommendations.

Ethernet cables provide the connection between the LLE2 paddle boards (located on the back plane of the unit) and the layer 2 switch or router. The location of each LLE2 paddle board is dependent on the equipage of the SIP PHs. The physical connection is by a Category 5 cable with RJ-45 connectors. The maximum length of an Ethernet 100BaseT cable is 328 feet.

This section provides a brief description of the interfaces that connect to the SIP PH and GQPH. Refer to Figure 2-16, “Connecting circuits”

(2-29).

SIP PH and GQPH interfaces consist of the following which are part of the PSU2 back plane:

• packet bus (PB),

• control bus (CB), and

• protocol handler data bus (PHDB).

The packet bus provides the packet data interface between the PHs and the packet fanout 2 (PF2). The PHs transmit and receive data packets over the packet bus.

The function of the control bus is to fanout control signals, which are controlled by the CF2, to the PHs and provide PH error status.

The protocol handler data bus provides a data interface between the PHs and the DF2. The PHDB carries time slots between the PH and DF2. The SIP PH does not use the PHDB.

....................................................................................................................................................................................................................................

2-28

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Hardware View

Architecture

The SIP PH supports an external interface, the LLE2 paddle board. The LLE2 paddle board terminates an Ethernet connection which provides the connection to the layer 2 switch or router.

Figure 2-16 Connecting circuits

CIB

PHDB

D

Non-Serving

LLE2

F 2

SIP Signaling over Ethernet

SIP PH

LLE2

PSU2

CF2

GQPH

Serving

SIP PH

- new hardware

CB PB

CIB

PIB

P F 2

Timing

Configuration

Service impacts to

subscriber

No changes.

The SIP PHs are configured as processor groups each having one or two PHs. When configured with two PHs in a processor group, both PHs are active with one being designated as serving and the other PH as non-serving. Refer to section“Serving/Non-Serving” (2-30) for additional information.

The GQPHs are configured as active loadshared PHs with a standby spare PH.

Cause Effect

SIP PH failure transient calls timeout and

abandon; stable calls remain.

Cause Effect

GSM full initialization with or without pump

most transient calls supported by SIP PHs dropped; stable calls should be recovered.

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-29

Hardware View

Service impacts to switch

Architecture

SIP PH

SIP PH failure when SMP unavailable due to:

Cause Effect

GSM selective initialization

• inbound and outbound

messages discarded, and

• associations closed.

Cause Effect

GSM full initialization with or without pump

Serving SIP PHs attempt to shutdown all established associations before being initialized.

GQPH

GQPH failure when SMP unavailable due to:

Cause Effect

GSM selective initialization

• inbound messages discarded,

and

• outbound messages rerouted

to alternate GQPH; if no alternate GQPH, messages are discarded.

Note: The GQPHs are only on the non-DRM/VCDX.

Serving/Non-Serving

SIP PHs are configured as processor groups containing one or two SIP PHs. For a processor group of two active SIP PHs, the GSM SMP selects one SIP PH as serving and the other SIP PH as non-serving. For a processor group of one active SIP PH, the GSM SMP selects the single SIP PH as the serving SIP PH.

....................................................................................................................................................................................................................................

2-30

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Hardware View

Architecture

The serving SIP PH:

• initiates its local SCTP endpoint and the associations provisioned

on that endpoint when SCTP transport is used,

• initiates the SIP interface to UDP paths provisioned on the

processor group when UDP transport is used,

• provides the non-serving SIP PH with stable call data to be

preserved in case a failure occurs with the serving SIP PH,

• provides the CP SMP with stable call data to address cases that

impact both SIP PHs,

• supports address resolution protocol (ARP) functionality, and

• initiates IP pings to confirm IP connectivity.

The non-serving SIP PH:

• Receives stable call data from the serving SIP PH over the PSU2

packet bus interface,

• Does not send or receive packets over the Ethernet interface,

• Is able to detect and report Ethernet link failures.

Figure 2-17, “SIP PH Functionality” (2-31) depicts how the serving

SIP PH saves the stable call data.

Figure 2-17 SIP PH Functionality

GSM - 2000

Primary

NCT2 Link

To CP

SMP

to CM

TSI

PCT

D F 2

IP Network

CIB

PHDB

LLE2

PSU2

CF2

GQPH

Non-Serving

SIP PH

Serving

LLE2

SIP PH

RR

CB PB CB PB CB

CIB

PIB

P F 2

PB

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-31

Hardware View

Architecture

SIP PH switch over

A SIP PH switch over can be automatic (fail-over) or manual operation (manual switch over). It switches the serving SIP PH to the non-serving SIP PH, and switches the non-serving SIP PH to the serving SIP PH.

Switch over from the serving SIP PH to the non-serving SIP PH occurs in 3 seconds or less.

A 5 minute timer is started following a switch over as a result of auto ping failing in the serving SIP PH. The timer is used to prevent ping failures on the new serving SIP PH from attempting continual switches. However, the timer does not prevent a manual switch over or a switch over due to a failure condition.

When the timer expires, the following can occur.

• If ping is up on the serving SIP PH, nothing occurs.

Service Selection

• If ping is down on the serving SIP PH and the other SIP PH is non-serving, a switch over occurs even if the non-serving SIP PH had a previous known ping failure.

• If ping is down on the serving SIP PH and the other SIP PH is unavailable, no switch over occurs.

The following failure conditions cause the serving SIP PH to do a SIP PH switch over:

• service selection state changes to unavailable (e.g., Ethernet link failure or SIP PH card failure), and

• loss of ping and the timer has expired.

A switch over does not occur when the service selection state of the non-serving SIP PH changes to unavailable.

The service selection state for a SIP PH indicates its ability to support or handle signaling services. The SIP PH may transition to another state automatically or manually by the switch personnel.

....................................................................................................................................................................................................................................

2-32

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Hardware View

Architecture

There are 3 service selection states:

• Serving - indicates that a SIP PH is performing the signaling role

for the SIP layer, transport layer, and IP layer. If the processor group supports an SCTP near endpoint for the transport layer, then the serving SIP PH establishes the SCTP associations terminated on that endpoint, connecting sockets between SCTP and the SIP layer when the associations are established to the far end. If the processor group supports UDP paths for the transport layer, then the serving SIP PH connects the sockets between UDP and the SIP layer.

• Non-Serving - indicates that a SIP PH is not performing the

signaling role but can take over the signaling role when needed.

• Unavailable - indicates that a SIP PH cannot perform any

signaling activities and cannot take over the signaling role if the serving SIP PH fails.

Table 2-5, “Service Selection State” (2-33) illustrates the valid service

selection states allowed based on the status of the PHE2.

Table 2-5 Service Selection State

SERVICE SELECTION STATE PHE2 STATUS

SERVING ACTIVE NON-SERVING ACTIVE UNAVAILABLE OOS UNAVAILABLE DEGRADED

The following conditions cause the SIP PH to transition to the unavailable service selection state:

• SM full initialization,

• PH full initialization,

• SIP PH out of service (OOS),

• Ethernet OOS, and

• PSU2 failures.

When a SIP PH transitions from the service selection state of serving or non-serving to the unavailable state due to a non-manual request, a major alarm is reported.

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-33

Hardware View

Architecture

When a SIP PH transitions from the service selection state of serving to the unavailable state and the mate SIP PH is in the unavailable state, a critical alarm is reported.

Table 2-6, “Service Selection State Combinations” (2-34) illustrates

the allowed service selection state combinations for a processor group with two SIP PHs.

Table 2-6 Service Selection State Combinations

SIP PH 0 SIP PH 1

SERVING NON-SERVING NON-SERVING SERVING UNAVAILABLE UNAVAILABLE UNAVAILABLE SERVING SERVING UNAVAILABLE

However, for a processor group with only one SIP PH, the allowed service selection states are serving and unavailable.

....................................................................................................................................................................................................................................

2-34

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Architecture

Security View

....................................................................................................................................................................................................................................

Overview

Bearer Security

The bearer and signaling interfaces on the IP core network may or may not be trusted and secure depending on the service provider’s network implementation. This section provides security information.

Additional security features were developed on the OIU-IP. The OIU-IP uses the real time transfer protocol (RTP) to carry voice traffic on protected packet over SONET (POS) fiber optic links.

The security features for the OIU-IP bearer interface include:

• point to point protocol (PPP) link scrambling,

• valid user datagram protocol (UDP) port range matching,

• dynamic packet filtering of voice RTP traffic,

• invalid packet discard for protocol errors,

• internet control message protocol (ICMP) message processing

controls,

• provisionable thresholds for triggering selected minor alarms

when detecting protocol violations, and

• detection of flood attack on links, and routing of new calls away

from such links during duration of the attack.

OIU-IP bearer network security is implemented in two main areas, the packet field programmable gate array (PFPGA) on the OFI-IP and the router to which the OFI-IP is connected. The router connected to an OFI-IP performs basic filtering functionality and guards the OC-3c intra-office link. The router should be capable of rough filtering non-relevant traffic away from the OFI-IP interface. A router which permits configurable packet filter policies based on IP destination protocol and is capable of rate limiting to minimize the effect of ping floods on the OC-3c link is recommended.

The PFPGA monitors the bit-stream for a large variety of protocol violations and discards nonconforming or malicious packets. Discarded packets are counted, and the counts are listed in various digital performance monitoring (DPM) and traffic measurement reports. A subset of the DPM counts can be provisioned with a minor alarm at DPM threshold crossing.

The OIU-IP Interface Specification, 235-900-316 document explains OIU-IP security in greater detail.

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-35

Security View

Architecture

SCTP Security

The 5ESS®switch uses SCTP layer security according to the SCTP standards. SCTP provides for protection against:

• flooding,

• blind masquerade,

• improper monopolization of services, and

• fraud and repudiation.

SCTP uses a cookie mechanism which is started during initialization to provide protection against security attacks. This is an advantage over TCP and UDP because they do not have this application function.

Cookie Mechanism

Figure 2-18, “Cookie Mechanism” (2-36) illustrates the cookie

mechanism.

1. The client, office A, sends a connection request (INIT) to the server.

2. The server, office B, builds a cookie (INIT ACK) containing TCB information and sends it to the client.

3. The client returns the TCB information to the server (COOKIE ECHO).

4. The server validates the cookie and uses it to rebuild the TCB that it returns to the client (COOKIE ACK).

Figure 2-18 Cookie Mechanism

R

5ESS Switch

Office A

SCTP

Endpoint

Transmission Control Block (TCB) Created

INIT

INIT AC K

COOKIE ECHO

COOKIE ACK

Association

IP Netw o r k

Endpoint

Transmission Control Block (TCB) Created

R

5ESS Switch

Office B

SCTP

The advantage of the cookie mechanism is that the server does not reserve memory or resources until a COOKIE ECHO message is received from the client. This protects the server from overload during blind attacks.

....................................................................................................................................................................................................................................

2-36

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Security View

Architecture

A blind attack occurs when a client is sending a client IP address different from its own to the server. The server returns the cookie to the invalid client IP address instead of the attacking client. The invalid client will drop the message instead of returning a COOKIE ECHO message. Since the server never receives a COOKIE ECHO message, memory and resources are not allocated and overload is avoided.

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

2-37

3 Call Flow

Overview

....................................................................................................................................................................................................................................

Purpose

The purpose of this chapter is to describe the Session Initiation Protocol (SIP) call flow.

The purpose of this chapter is to describe possible Session Initiation Protocol (SIP) call flows.

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

3-1

Call Flow

Call Flow Overview

....................................................................................................................................................................................................................................

When the 5ESS®switch determines a call must be routed to another

®

switch, the call processing programs in the 5ESS

switch determine a path to route the call. If the switch selects an IP network path, call processing programs use Session Initiation Protocol (SIP) signaling to establish the call. The switch converts incoming in-band or out-of-band signaling messages to SIP messages so Public Switch Telephone Network (PSTN) calls can traverse an IP network. In this situation, the switch is functioning as an Originating Packet Switch (OPS) at the boundary between the PSTN and the IP network.

At the far-end switch, the call is typically completed to a time division multiplexing (TDM) circuits. When a call is completed to a

®

TDM circuit at the terminating 5ESS

switch, the appropriate PSTN outgoing signaling message is formulated from the received SIP message.

®

The 5ESS

switch can also terminate calls that arrive from an IP network, in which case it converts incoming SIP signaling message to in-band or out-of-band signaling in order to complete the call on a circuit path in the PSTN. In this situation, the switch is functioning as a Terminating Packet Switch (TPS) at the boundary between the PSTN and the IP network.

Many call flows are possible, depending on the following factors:

• network architecture,

®

• function of the 5ESS

switch in the network,

• SIP protocol options supported by other SIP-enabled switches

®

which the 5ESS

switch connects via a SIP packet group, and the function of those far-end switches in the PSTN and/or IP network,

• transport layer used to carry the SIP messages in the IP network,

• provisioned mapping rules for signaling message conversion

between PSTN and SIP protocols for the packet group on the

®

5ESS

switch, and

• SIP protocol options provisioned for the packet group on the

®

5ESS

switch.

....................................................................................................................................................................................................................................

3-2

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Call Flow

Network Architecture

....................................................................................................................................................................................................................................

The 5ESS®switch can function as either an OPS or TPS in different network architectures:

Packet Trunking: The 5ESS

•

®

switch in the PSTN, connected to another SIP-enabled switch in the PSTN by means of SIP packet trunking (call originates and terminates in PSTN, but traverses the IP network between the PSTN endpoints). This network architecture is illustrated in Figure 3-1, “Packet Trunking” (3-3).

• PSTN Gateway: The 5ESS®switch in the PSTN connected to an

IP Telephone Application Server (TAS) TPS in the IP network,

®

with the 5ESS

switch serving as a PSTN Gateway for calls originating in the PSTN and terminating in the IP network, or originating in the IP network and terminating in the PSTN. This network architecture is illustrated in Figure 3-2, “PSTN

Gateway” (3-4).

Figure 3-1 Packet Trunking

Originating Switch

Terminating Switch

PSTN

IP Signaling Network

Edge RouterEdge Router

Ethernet Ethernet

DNU-S DNU-S

OPS

PSU2

OIU-IP

Edge Router Edge Router

PSU2

OIU-IP

OC-3cOC-3c

PSTN

TPS

IP Bearer Network

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

3-3

Network Architecture

Figure 3-2 PSTN Gateway

®

5ESS Switch

Signaling Path Bearer Path

PSTN

IP Network

Call Flow

®

5ESS Switch

PSTN Gateway

Telephone Application

Server (TAS)

Message conversion

between PSTN and IP

protocols

POTS Subscriber ISDN Subscriber IP Subscriber

PSTN signaling messages are converted to SIP messages using translation and encapsulation. For outgoing messages, the SIP protocol

®

handler (PH) in the 5ESS

switch constructs a SIP message in a standard, external format using information provided by the SIP call processing SM.

The SIP message contains the following:

• information used to route the message in the IP network,

• information describing the message type and content, and

• data associated with the particular application.

For incoming messages, the SIP PH extracts information from the SIP message and delivers the data to the SIP call processing SM. The SIP call processing SM passes the information to the SM that generates PSTN signaling messages and completes the call using TDM circuits.

The details of how the call signaling messages are converted to and from SIP are controlled by a number of provisionable parameters on

....................................................................................................................................................................................................................................

3-4

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Network Architecture

Call Flow

the 5ESS®switch. Provisionable parameters control what signaling

®

information from 5ESS

switch call processing is (or is not) translated into SIP headers; whether (or not) encapsulated ISUP is included in SIP headers at the OPS; and what information from the SIP signaling messages is (or is not) extracted from the SIP headers and/or encapsulated ISUP to be delivered to call processing at the TPS. The

®

setting of these parameters for each packet group on the 5ESS

switch is dependent on the SIP functionality supported by the switch at the far end of the packet group.

Notes:

1. Refer to the Session Initiation Protocol (SIP) - Interface

Specification, 235-900-344, document for more detailed

information on SIP messages and interworking to and from TDM messages.

2. Refer to System View in Chapter 2 of this document for more

®

information about the 5ESS

switch elements involved in the intra-switch messaging between the SIP PH and the Call Processing SM.

Elements

3. Refer to Chapter 5 of this document for details of provisioning procedures for the Recent Change views that affect call flows, particularly the provisioning of SIP Packet Groups (RC/V 5.71), SIP Parameter Sets (RC/V 5.82), and mapping rules for interworking between SIP and PSTN signaling (RC/V 5.83).

The initial application for SIP signaling is in tandem/toll offices. Considering this, there are five key network elements that a call traverses. They are:

• Originating Switch

• Originating Packet Switch (OPS)

• Routers

• Terminating Packet Switch (TPS)

• Terminating Switch

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

3-5

Network Architecture

Call Flow

Figure 3-3, “Network Elements” (3-6), illustrates how the different

network elements interface to each other.

Figure 3-3 Network Elements

Originating Switch

Terminating Switch

PSTN

IP Signaling Network

Edge RouterEdge Router

Ethernet Ethernet

DNU-S DNU-S

OPS

PSU2

OIU-IP

Edge Router Edge Router

PSU2

OIU-IP

OC-3cOC-3c

TPS

IP Bearer Network

Originating Switch

The originating switch terminates the calling party and provides an interface to the PSTN.

Originating Packet Switch (OPS)

The OPS serves as a gateway between the PSTN and an IP network. At the OPS, the incoming circuit call is routed out of the office to an IP bearer resource using SIP. Any circuit peripheral can be used for the incoming call.

Three SMP processes are involved in a SIP call:

• the SMP process for the circuit call (ISUP terminal process)

• the SMP process for the SIP call processing SM (SIP terminal

process), and

• the SMP process with the OFI-IP for the bearer connection

(bearer terminal process).

....................................................................................................................................................................................................................................

3-6

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Network Architecture

Call Flow

All three processes could be located on the same SM-2000 or they could be located in three different SM-2000s. Messaging between the SMPs that host the processes is done over the quad link packet switch (QLPS) network.

Routers

Control the routing of packets between the OPS and TPS and provides alternate paths when necessary. A router is able to the read network layer, IP, addresses of the transmitted packets and only forwards those addressed to another network. Routers do not examine application layer messages like SIP.

Terminating Packet Switch (TPS)

The TPS serves as a gateway between the PSTN and an IP network. At the TPS, the incoming SIP call is routed out of the office to the TDM network using TDM signaling. Any circuit peripheral can be used for the outgoing call.

Connections

Terminating Switch

The terminating switch terminates the called party and interfaces to the PSTN.

There are two network connections, bearer and signaling. The two connections can be made through separate networks or through the

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

3-7

Network Architecture

Call Flow

same network. Figure 3-4, “Network Connections” (3-8), illustrates connections to separate IP networks.

Figure 3-4 Network Connections

Signaling connection

The signaling connection is only provided by an SM-2000. A 100BaseT Ethernet connection passes the signaling messages between the edge router and the SIP PH in the packet switching unit model 2 (PSU2).

Bearer connection

The bearer connection is only provided by an SM-2000 that has optical facility interface-internet protocol (OFI-IP) boards in the OIU. It is the OFI-IP in an OIU that provides the synchronous to asynchronous conversion between TDM bearer flows and IP bearer flows.

....................................................................................................................................................................................................................................

3-8

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Call Flow

High-Level Call Flow

....................................................................................................................................................................................................................................

SIP OPS Call Setup

This section describes the steps for setting up a SIP call on a 5ESS

®

switch OPS from a high-level view. It presumes that the incoming circuit call to be terminated over a SIP packet group is an ISUP trunk call, although other circuit originations can terminate to SIP as well.

1. An ISUP IAM message from the far switch in the PSTN arrives

®

at the 5ESS

switch OPS. Call processing determines that the incoming ISUP call should be routed out over the IP network to another switch.

2. The OPS selects and allocates an IP address and port on an OFI-IP to be the bearer for the call.

3. The OPS formulates a SIP INVITE message. The SIP INVITE message requests that the TPS allocate resources for the call. This message includes:

• the IP address of OPS signaling point,

• the IP address of TPS signaling point,

• a description of the requested bearer session, including the

IP address and port number for the OPS bearer resource,

• information about the SIP methods and procedures supported

by SIP at the OPS, and

• call information from the ISUP IAM, such as the called and

calling party information.

Note: The call information from the IAM is translated into

the SIP headers according to the PSTN-to-SIP mapping rules provisioned for the selected SIP packet group, and the ISUP IAM may be encapsulated in the SIP message or not, according to the provisioning of the ISUP encapsulation parameter for the packet group.

4. The OPS sends the SIP INVITE to the TPS, and waits for a response. If the transport layer is UDP, the SIP layer at the OPS retransmits the INVITE until a response is received. If the transport layer is SCTP, which is a reliable, connection-oriented protocol, the SIP layer does not retransmit the INVITE.

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

3-9

High-Level Call Flow

Call Flow

5. If the transport layer is UDP, the first provisional response is

likely to be a ″100 TRYING″ message unless the TPS is a 5ESS switch and the transport layer is SCTP. The ″100 TRYING″ message indicates that the far end has received the INVITE, so that retransmissions can be halted, but provides no other information for call setup. The OPS continues to wait for a response containing the necessary session description and other signaling information.

6. Depending on the nature of the call, the next response received (or the first response, when the transport layer is SCTP), is likely to be a provisional response such as ″180 RINGING″ or ″183 SESSION PROGRESS″, which contains the bearer session description of the far end, as well as other call signaling information, possibly including encapsulated ISUP, if encapsulated ISUP was included in the original INVITE.

7. There may, or may not, be additional SIP messages exchanged between the OPS and TPS before the call is answered, depending on the nature of the call and the provisioned options for SIP methods and procedures allowed and/or supported at each end, which are communicated and agreed upon between the OPS and TPS, by means of parameters in SIP headers in the INVITE/18X SIP message exchange. The options that might lead to additional messages being exchanged before the call is answered include support for SIP preconditions procedures (allowed only when the transport layer is SCTP), and support for reliable provisional responses (PRACK).

®

8. When the call has been answered, the OPS receives a 200 OK INVITE final response.

9. The OPS acknowledges the 200 OK INVITE with a SIP ACK message. Whether the transport layer is UDP or SCTP, the SIP protocol requires the 200 OK INVITE final response to be retransmitted by the TPS until the ACK is received, so the OPS must respond to any retransmissions of the 200 OK INVITE with retransmissions of the ACK message.

10. After the 200 OK INVITE is received and the ACK is sent, the call proceeds to the ″talking″ state, and call setup is complete.

At this point the bearer path for the call is available to carry call data (e.g., PCM voice) between the calling and called party. The path remains available until either party terminates the call.

....................................................................................................................................................................................................................................

3-10

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

High-Level Call Flow

Call Flow

SIP TPS Call Setup

The following is a high-level view of call setup from the viewpoint of

®

a 5ESS

1. The 5ESS

switch TPS:

®

switch TPS receives a SIP INVITE from a far switch.

2. If the transport layer is UDP, the TPS immediately responds with

a ″100 TRYING″ message to inform the OPS that the INVITE has been received, so that INVITE retransmissions may cease. If retransmitted INVITEs are received, the TPS responds by retransmitting the latest INVITE response sent.

3. The TPS extracts the call signaling data from the SIP headers and/or the encapsulated ISUP IAM (if any) in the SIP INVITE, according to the provisioned SIP-to-PSTN mapping rules.

4. The TPS selects and allocates an IP address and port on an OFI-IP to be the bearer for the call.

5. The TPS uses the call signaling data to route the call to an outgoing ISUP trunk. The call signaling data extracted from the SIP message is included in an ISUP IAM to be sent the PSTN switch at the far end of the ISUP trunk.

6. The TPS formats and sends a provisional response to the OPS. The exact response, such as ″183 SESSION PROGRESS″ or ″180 RINGING″, depends on the nature of the call, the methods and procedures supported by the OPS as indicated in the incoming INVITE, and the methods and procedures supported by the TPS, according to the SIP parameters provisioned for the packet group over which the INVITE was received. The response includes the bearer session information determined by the TPS, and may or may not include an encapsulated ISUP response from the switch at the far end of the ISUP trunk group in the PSTN, depending on whether the received INVITE included encapsulated ISUP.

7. There may, or may not, be additional SIP messages exchanged between the OPS and TPS before the call is answered, depending on the nature of the call and the provisioned options for SIP methods and procedures allowed and/or supported at each end, which are communicated and agreed upon between the OPS and TPS by parameters in SIP headers in the INVITE/18X SIP

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

3-11

High-Level Call Flow

Call Flow

message exchange. The options that might lead to additional messages being exchanged before the call is answered include support for SIP preconditions procedures (allowed only when the transport layer is SCTP), and support for reliable provisional responses (PRACK).

8. If PRACK procedures are supported by both the OPS and the TPS, the TPS will retransmit the 18X provisional response until a PRACK is received to acknowledge it, or until the call is answered. This retransmission of provisional responses is performed by the SIP layer independent of transport layer, over either SCTP or UDP. When PRACK procedures are enabled, the TPS will not send any additional provisional responses, and will not accept any new requests, until the PRACK is received to acknowledge the last provisional response. If PRACK procedures are not supported by both ends, the TPS will not retransmit the 18X response when the transport layer is SCTP, and will only retransmit the 18X response as a result of receiving a retransmitted INVITE request from the OPS when the transport layer is UDP.

SIP Call Tear Down

9. When an ISUP message is received indicating that the call has been answered at the other end of the ISUP trunk in the PSTN, the TPS formats and sends a 200 OK INVITE final response. The TPS retransmits the final response, independent of transport layer, until it receives an ACK from the OPS.

10. After the 200 OK INVITE is sent and the ACK is received, the call proceeds to the ″talking″ state, and call setup is complete.

This section describes tearing down of a SIP call, from a high-level view.

Originating Packet Switch:

From the viewpoint of a 5ESS®switch OPS, when the calling party in the PSTN goes on-hook:

1. The OPS receives an ISUP REL message from the switch at the other end of the ISUP trunk in the PSTN.

2. The OPS formulates a SIP BYE messages and forwards it to the TPS. The OPS also tears down the call and releases resources dedicated to the call.

Terminating Packet Switch:

....................................................................................................................................................................................................................................

3-12

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

High-Level Call Flow

Call Flow

From the viewpoint of the 5ESS®switch TPS, when the calling party (either in the IP network if the TPS is a PSTN Gateway, or in the PSTN for SIP packet trunking between PSTN offices) goes on-hook:

1. The TPS receives a SIP BYE message.

2. The TPS formulates an ISUP REL message and forwards it to the terminating switch. The TPS also tears down the call and releases resources dedicated to the call.

Tearing Down Call Path

This section overviews tearing down of a SIP call from a high-level view. In this scenario, the calling party ended the call by going on-hook.

1. The calling party goes on-hook. The originating switch send an ISUP REL message to the OPS to notify the OPS of the state change.

2. The OPS formulates a SIP BYE messages and forwards it to the TPS. The OPS also tears down the call and releases resources dedicated to the call.

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

3-13

High-Level Call Flow

Call Flow

3. The TPS receives the SIP BYE message. The TPS formulates an ISUP REL message and forwards it to the terminating switch. The TPS also tears down the call and releases resources dedicated to the call.

4. The call flow is now complete.

....................................................................................................................................................................................................................................

3-14

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Call Flow

Message Flows

....................................................................................................................................................................................................................................

Figure 3-5, “Successful Call Completion Message Flow” (3-15)

illustrates ISUP and SIP messages sent between network elements in order to successfully setup and tear down a call between two subscribers.

Figure 3-5 Successful Call Completion Message Flow

Originating Terminating

Switch OPS TPS Switch

| --IAM-> | | | | | ------INVITE-----> | | | | | --IAM-> | ||183 SESSION || | | <----PROGRESS----- | | | | ------UPDATE-----> | | ||<-200 OK (UPDATE)-| | | | | <-ACM-- | | | <---180 RINGING--- | | | <-ACM-- | | | | | | <-ANM-- | ||<-200 OK (INVITE)-| | | <-ANM-- | | | || | Talking Path Available | || | --REL-> | | | | | --------BYE------> | | | | | --REL-> | | | <--200 OK (BYE)--- | |

Overview

There are many possible message flows for successful SIP calls, for various network configurations and SIP protocol options. This section illustrates three likely message flows, with different configurations and options provisioned.

Message Flow 1

This message flow is a straightforward packet trunking scenario

®

between a 5ESS

switch OPS and 5ESS®switch TPS in the PSTN, where the call originates from an ISUP trunk in the PSTN at the OPS, and terminates to an ISUP trunk in the PSTN at the TPS. Refer to

®

Figure 3-6, “ 5ESS

Switch OPS - 5ESS®Switch TPS Message Flow”

(3-17).

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

3-15

Message Flows

Call Flow

The provisioning at both OPS and TPS which affects the message flow and message content is as follows:

• Transport Layer: SCTP (RC/V 5.71 ASSOC SET NAME

provisioned),

• Preconditions: Yes (RC/V 5.71 SIP-T PRECOND=Y),

• Local Audible: No (RC/V 5.71 LOCAL AUDIBLE=N),

• Encapsulated ISUP: Yes (RC/V 5.82 ISUP

ENCAPSULATION=Y),

• PRACK procedures: No (RC/V 5.82 PRACK ENABLED=N),

• PSTN-to-SIP mapping rules at OPS: [don’t map optional SIP

headers] RC/V 5.83:

- REQUEST URI ADDR=BASIC

- REQUEST URI CIC=BASIC

- REQUEST URI CSEL=NOTMAPPED

- TO HEADER=BASIC

- FROM ADDR=BASIC

- FROM NAME=NOTMAPPED

- FROM OLI=NOTMAPPED

- P-ASSERTED ADDR=NOTMAPPED

- P-ASSERTED NAME=NOTMAPPED

- DIVERSION=NOTMAPPED

- MAX FORWARDS=BASIC

• SIP-to-PSTN mapping rules at TPS: [use encapsulated ISUP

IAM] RC/V 5.83:

- CALLING PARTY INFO=ISUPMIME

- CALLED PARTY NUMBER=ISUPMIME

- TRANSIT NETWORK SELECTION=ISUPMIME

- REDIRECTING INFO=ISUPMIME

- ORIGINATING LINE INFO=ISUPMIME

....................................................................................................................................................................................................................................

3-16

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Message Flows

Call Flow

- HOP COUNTER=ISUPMIME

- CARRIER SELECTION=ISUPMIME

Figure 3-6

Originating

PSTN

Switch

IAM

COT

ACM

ANM

SUS

REL

RLC

5ESS

Flow

Lucent

O

5E-XC

®

Switch OPS -

TM

1

2

183 SESSION PROGRESS {SDP}

3

200 OK (UPDATE) {SDP}

4 5

180 RINGING {ISUP ACM}

6

Audible Ringing Provided from Termination

7

200 OK (INVITE) {ISUP ANM}

8

SIP

INVITE {SDP,ISUP IAM}

UPDATE {SDP}

ACK

Call in TalkingState

INFO {ISUP SUS}

200 OK INFO

BYE {ISUP REL}

200 OK (BYE)

5ESS

®

Switch TPS Message

TPSOPS

Lucent

O

Terminating

5E-XC

TM

IAM

COT

ACM

ANM

SUS

REL

RLC

PSTN

Switch

Called Party

goes off-hook

Called Party

goes on-hook

Note: All SIP messages have the common SIP headers used to

identify and route SIP messages and associate them with particular transactions within calls, e.g.: either Request URI or response status line, To, From, Call-ID, CSeq, Via, Contact, Length, Max-Forwards, etc. The following message flow description does not explicitly list these. For more detailed examples, refer to the Session Initiation Protocol (SIP) - Interface Specification, 235-900-344, document.

This message flow starts with an ISUP Initial Address Message (IAM) received at the OPS, which routes the call to a SIP packet trunk and sends a SIP INVITE message to the TPS. The ISUP

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

3-17

Message Flows

Call Flow

IAM for this scenario has the COT indicator set, indicating that an ISUP COT message will be received for the ISUP trunk.

1. The SIP INVITE includes:

• SDP offer with bearer session description for the OPS,

• encapsulated ISUP Initial Address Message,

• SIP Allow header indicating support for these methods:

INVITE, ACK, BYE, CANCEL, UPDATE, INFO, OPTIONS,

• SIP Require header indicating that Precondition procedures

are required. Due to the provisioning of the PSTN TO SIP MAPPING RULES on RC/V 5.83, some call information is not populated in SIP headers, even if the corresponding ISUP parameter is present in the ISUP IAM:

• no carrier selection information in Request URI,

• no calling name information in the From header,

• no originating line information in the From header,

• no P-Asserted-Identity header, and

• no Diversion headers.

2. When the TPS has allocated bearer resources, it sends a 183 SESSION PROGRESS which includes:

• SDP answer with bearer session description for TPS,

• SIP Allow header indicating support for these methods:

INVITE, ACK, BYE, CANCEL, UPDATE, INFO, OPTIONS,

• SIP Require header indicating that Precondition procedures

are required.

3. The OPS sends a SIP UPDATE message as part of the preconditions procedures, after COT has been received from the PSTN and 183 SESSION PROGRESS with SDP has been received from the TPS. The UPDATE includes an SDP offer with the same bearer IP address and port information as the SDP in the original INVITE, but with different quality-of-service attributes.

4. 200 OK UPDATE includes an SDP answer with the same bearer IP address and port as the SDP in the 183 SESSION PROGRESS, but with different quality-of-service attributes.

....................................................................................................................................................................................................................................

3-18

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Message Flows

Call Flow

5. When an ISUP Address Complete message is received from the terminating switch in the PSTN, the TPS sends a SIP 180 RINGING provisional response, which includes:

• encapsulated ISUP Address Complete Message, and

• the same SIP Allow and Require headers as the 183

SESSION PROGRESS.

6. Audible ringing is provided by the terminating switch in the PSTN.

7. When the TPS receives an ISUP Answer message, it sends a SIP 200 OK INVITE response, which includes the encapsulated ISUP ANM.

8. When the called party goes on-hook first, the TPS receives an ISUP Suspend message, which it sends in a SIP INFO message with the ISUP SUS message.

Note: When the calling party goes on hook, the OPS receives an

ISUP Release and sends a SIP BYE message with the encapsulated ISUP REL Message. The call resources are then released.

Message Flow 2

In this message flow, the 5ESS®switch is acting as a PSTN Gateway, handling a call that originates from subscriber on a TAS in the IP network and terminates to a subscriber on another switch in the

®

PSTN. The 5ESS

switch is the TPS in this scenario, and the TAS is

the OPS. It is presumed in this scenario that the TAS has a directly

®

provisioned route to the 5ESS proxies or other intermediate nodes between the 5ESS Gateway and the TAS. Refer to Figure 3-7, “ 5ESS

switch PSTN Gateway, so there are no

®

switch PSTN

®

Switch PSTN

Gateway TPS and TAS OPS Message Flow” (3-21).

The provisioning at the 5ESS®switch PSTN Gateway which affects the message flow and message content is as follows:

• Transport Layer: UDP (RC/V 5.71 UDP PATH provisioned),

• Preconditions: No (RC/V 5.71 SIP-T PRECOND=N),

• Encapsulated ISUP: No (RC/V 5.82 ISUP

ENCAPSULATION=N),

• PRACK procedures: Yes (RC/V 5.82 PRACK ENABLED=Y), and

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

3-19

Message Flows

Call Flow

• SIP-to-PSTN mapping rules at TPS: [extract call information

from SIP headers] RC/V 5.71: SIP PSTN SET NAME=DEFAULTNOISUP, RC/V 5.83:

- CALLING PARTY INFO=PIDENT,

- CALLED PARTY NUMBER=BASIC,

....................................................................................................................................................................................................................................

3-20

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Message Flows

Call Flow

- TRANSIT NETWORK SELECTION=BASIC,

- REDIRECTING INFO=DIVERSION,

- ORIGINATING LINE INFO=FROM,

- HOP COUNTER=MAXFORWARD, and

- CARRIER SELECTION=BASIC.

• PSTN to SIP mapping rules do not apply to this example, they only apply to OPS scenarios.

Figure 3-7

Originating IP

IP subscriber

call is forwarded

to PSTN

®

5ESS

Switch PSTN Gateway TPS and TAS OPS

Message Flow

SIP

TAS OPS

1

2

4

Audible Ringing Provided from Termination

5

INVITE {SDP}

100 TRYING

180 RINGING {SDP}

PRACK

200 OK (PRACK)

(R)

5ESS Switch

PSTN Gateway

TPS

Lucent

O

TM

5E-XC

3

IAM

ACM

Terminating

PSTN Switch

6

8

200 OK (INVITE)

ACK

Call in Talking State

BYE

200 OK (BYE)

ANM

7

SUS

REL

RLC

Called Party

goes off-hook

Called Party

goes on-hook

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

3-21

Message Flows

Call Flow

Note: All SIP messages have the common mandatory SIP headers

used to identify and route SIP messages and associate them with particular transactions within calls, e.g.: either Request URI or response status line, To, From, Call-ID, CSeq, Via, Length, Max-Forwards, etc. The following message flow description does not explicitly list these. For more detailed examples, refer to the Session Initiation Protocol (SIP) - Interface Specification, 235-900-344, document.

The following steps provide a description of the messages between the

®

Originating IP TAS, 5ESS

switch PSTN Gateway and Terminating

PSTN switch.

1. The SIP INVITE includes:

• SDP offer with bearer session description for originating IP

subscriber,

• SIP Allow header indicating support for at least these

methods: INVITE, ACK, BYE, CANCEL, UPDATE, INFO, OPTIONS, PRACK,

• SIP Supported header indicating support for reliable provisional responses (indicated by ″100rel″ parameter), and

• SIP P-Asserted-Identity header, with calling party information.

If the call was forwarded one or more times within the IP network, before ultimately being forwarded to a PSTN subscriber, the SIP INVITE from the TAS OPS may also include a SIP Diversion header for each instance of call forwarding. If there are presentation restrictions on the calling party information, the INVITE may include a Privacy header. The TAS OPS may include Originating Line Information (OLI),

....................................................................................................................................................................................................................................

3-22

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Message Flows

Call Flow

appended as an isup-oli= parameter in the From header. The TAS OPS may include a Carrier ID Code and Carrier Selection Information for the origination, appended as

cic= and csel=

parameters on the username portion of the SIP Request URI and the SIP To header.

2. Because the transport layer is UDP, the SIP layer at the TAS OPS will retransmit the INVITE until it receives a response, so the

®

5ESS

switch TPS will send a 100 TRYING response

immediately after receiving the INVITE to indicate to the OPS

®

that it can cease retransmissions. The 5ESS

switch TPS will retransmit the 100 TRYING in response to INVITE retransmissions it receives.

®

3. When the 5ESS

switch PSTN Gateway has selected an ISUP trunk over which the call is to be routed to the terminating PSTN switch, it constructs an ISUP IAM message for the PSTN side of the call. Since there was no embedded ISUP IAM in the INVITE from the IP TAS, the PSTN Gateway TPS must map information from the SIP headers in the INVITE into ISUP parameters in the IAM, according to the provisioning rules for SIP-to-PSTN mapping on RC/V 5.83. Some of the mappings, given the provisioning described for this scenario, are:

• SIP Request URI to ISUP Called Party information,

• SIP P-Asserted-Identity and Privacy headers to ISUP Calling

Party information and presentation restrictions,

• SIP Max-Forwards header to ISUP Hop Counter parameter,

• SIP

cic= carrier code treated like a received ISUP TNS in

sunsequent switch translations,

• SIP

csel= parameter to ISUP Carrier Selection Information, isup-oli= parameter to ISUP Originating Line

Information , and

• First and last SIP Diversion headers to ISUP Redirecting

information parameters.

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

3-23

Message Flows

Call Flow

4. When the TPS has allocated SIP bearer resources and received an ISUP Address Complete Message (subscriber free) from the terminating PSTN switch, it sends a SIP 180 RINGING provisional response, which includes the following:

• SDP answer with bearer session description for TPS end of

IP bearer,

• SIP Allow header indicating support for these methods:

INVITE, ACK, BYE, CANCEL, UPDATE, INFO, OPTIONS, PRACK,

• SIP Require header indicating that the call will use reliable

provisional responses (indicated by ″100rel″ parameter), and

• SIP Rseq header with a sequence number specific to this

provisional response. (The CSeq number for the INVITE transaction is the same for all provisional and final responses, so an additional sequence number is required to uniquely identify one provisional response for reliable

transport.) Because the OPS and TPS have agreed to require reliable provisional responses, the TPS will retransmit the 180 RINGING until it receives a PRACK message acknowledging receipt by the OPS.

5. When the TPS receives a PRACK request containing a SIP RAck header with the RSeq of the 180 RINGING, it stops retransmitting the 180 RINGING message and sends a 200 OK PRACK to acknowledge receipt of the PRACK. Because the transport layer is UDP, the OPS will retransmit the PRACK until it receives the 200 OK PRACK. If the TPS receives retransmissions of the PRACK, it will respond with a retransmission of the 200 OK PRACK.

Note: The TPS will not send any more provisional responses,

and will not accept any more requests from the OPS, until the 180/PRACK/200 OK PRACK exchange has been completed.

6. When the PSTN Gateway TPS receives an ISUP ANM from the terminating PSTN switch, it sends a 200 OK INVITE. The TPS retransmits the 200 OK INVITE until it receives an ACK from the OPS. At this point, the call is in the talking state.

....................................................................................................................................................................................................................................

3-24

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Message Flows

Call Flow

7. If the called party in the TPS goes on-hook first, the TPS can receive an ISUP SUS message. Since this call does not use encapsulated ISUP, there is no means to signal that information to the OPS, so the TPS takes no action on the SIP side of the call until it receives an ISUP REL from the terminating PSTN switch.

8. When the TPS receives an ISUP REL from the terminating PSTN switch, it formats and sends a SIP BYE to the OPS, which responds with a 200 OK BYE. The call resources are then released.

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

3-25

Call Flow

Detailed Call Scenarios - SIP Base

....................................................................................................................................................................................................................................

This section closely examines how SIP calls are processed within the

®

5ESS

switch.

There are several different switching module processor (SMP) processes involved in the call. These processes include:

ISUP Terminal Process (ISUP TP): Formulates and interprets

•

ISUP messages. The switching module that hosts the ISUP terminal process also hosts the ISUP trunk member that has been assigned for the call.

SIP Terminal Process (SIP TP): Formulates and interprets SIP

•

messages in a compact, internal format. The SM-2000 that hosts this process is called the SIP call processing switching module.

Bearer Terminal Process (BRR TP): Assigns and controls the

•

OFI for the call. The switching module that hosts the bearer terminal process also hosts the packet group that has been assigned for the call.

These processes can be provided by the same switching module, three different switching modules, or a combination of two switching modules.

The following detailed called scenarios are discussed:

• Call Setup at Originating Packet Switch

• Call Setup at Terminating Packet Switch

• Call Tear Down at Originating Packet Switch

• Call Tear Down at Terminating Packet Switch

Note: These call scenarios use PSU-SS7 signaling.

....................................................................................................................................................................................................................................

3-26

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Detailed Call Scenarios - SIP Base

Call Flow

Call Setup at Originating

Packet Switch (ISUP to

SIP)

This section takes a closer look at the processing and messaging performed by the OPS when acting as a gateway between the PSTN and an IP network.

1. An ISUP IAM message arrives at the OPS on a signaling data link (SDL). The message is sent from the trunk peripheral terminating the SDL to the ST PH in the SS7 GSM via nailed up timeslots.

2. The ST PH in the PSU2 examine the message and forward it to the ISUP terminal process.

3. The ISUP terminal process performs digit analysis to determine if the call should be routed to a line or a trunk. Digit analysis determines that the call should be routed to a SIP packet group and requests that the CMP select a SIP packet group for the call.

4. The CMP:

• determines the call is routed to a SIP packet group,

• selects a switching module for the SIP terminal process, and

• selects a switching module for the bearer terminal process.

The determined information is then forwarded to the SIP terminal process and then the bearer terminal process.

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

3-27

Detailed Call Scenarios - SIP Base

Call Flow

5. The bearer terminal process selects an OFI and a port for the call. The corresponding IP address and port number are forwarded to the SIP terminal process.

6. The SIP terminal process develops an INVITE message. This message is in a compact, internal SIP format. An INVITE message requests that the TPS allocate resources for the call. This message includes:

• IP address and port number for the OPS OFI-IP

• Encapsulated ISUP IAM message

• A description of the requested session.

The formulated message is forwarded to the SIP PH in the SIP GSM. Additionally, an INVITE transaction timer is started.

7. The SIP PH expands the INVITE message to standard, external SIP format, adds the appropriate SCTP and IP headers, and forwards it to TPS via the IP signaling network.

8. The OPS waits for the TPS to respond.

9. The SIP PH receives a 183 SESSION PROGRESS message from the TPS. The message includes the IP address and port number of the TPS bearer resource.

....................................................................................................................................................................................................................................

3-28

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Detailed Call Scenarios - SIP Base

Call Flow

10. The SIP PH strips the SCTP and IP headers, compacts the message to the internal SIP format, and forwards the message to the SIP terminal process.

11. The SIP terminal process forwards the IP address and port number of the TPS bearer resource to the bearer terminal process.

12. The bearer terminal process forwards the IP address and port number of the TPS bearer resource to the selected OFI.

13. The selected OFI acknowledges that it received the information and opens the selected port.

14. The SIP terminal process formulates an UPDATE message and forwards it to the SIP PH in the SIP GSM. This message is in a compact, internal SIP format. The UPDATE message notifies the TPS that the bearer path is now available.

15. The SIP PH expands the UPDATE message to standard, external SIP format, adds the appropriate SCTP and IP headers, and forwards it to TPS via the IP signaling network.

16. The OPS waits for the TPS to respond.

....................................................................................................................................................................................................................................

235-200-118 Issue 3.02B, March 2007

Lucent Technologies

3-29

Detailed Call Scenarios - SIP Base

Call Flow

17. The SIP PH receives a 200 OK (UPDATE) message from the TPS. This message acknowledges that the TPS received the UPDATE message.

18. The SIP PH strips the SCTP and IP headers, compacts the message to the internal SIP format, and forwards the message to the SIP terminal process.

19. The SIP PH receives a 180 RINGING message from the TPS. The message informs the OPS that the called party is available and that ringing has been applied.

20. The SIP PH strips the SCTP and IP headers, compacts the message to the internal SIP format, and forwards the message to the SIP terminal process. The INVITE transaction timer is stopped in the SIP terminal process.

....................................................................................................................................................................................................................................

3-30

Lucent Technologies 235-200-118

Issue 3.02B, March 2007

Lucent Technologies 5ESS User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Contents

List of Figures

List of Tables

About this information product

Purpose

Reason for reissue

Safety labels

Intended audience

Conventions used

Systems supported

Related documentation

How to comment

How to order

1 Overview

Overview

SIP for Packet Trunking

2 Architecture

Overview

Network View

System View

Signaling View

Hardware View

Security View

3 Call Flow

Overview

Call Flow Overview

Network Architecture

High-Level Call Flow

Message Flows

Detailed Call Scenarios - SIP Base