Browse Prior Art Database

SELF CONFIGURED/PLUG-AND-PLAY, SELF HEALING, ADAPTIVE, AUTONOMIC SESSION BORDER CONTROLLER

IP.com Disclosure Number: IPCOM000239326D
Publication Date: 2014-Oct-29

Publishing Venue

The IP.com Prior Art Database

Abstract

A solution is presented herein in which a Session Border Controller adapts to the dynamics of the UC deployment, providing automatic correction, improved user experience and reduced administrative intervention. This solution will remove the complexity and delays associated with manual troubleshooting and fixing by automatic correction. This improves customer user experience and reduces operational expenses.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 27% of the total text.

Page 01 of 13

SELF CONFIGURED/PLUG-AND-PLAY, SELF HEALING, ADAPTIVE, AUTONOMIC SESSION BORDER CONTROLLER

AUTHORS:

 Jayesh Sangpal Naveen Rajasekaran Hasmeet Singh Bedi

CISCO SYSTEMS, INC.

ABSTRACT

    A solution is presented herein in which a Session Border Controller adapts to the dynamics of the UC deployment, providing automatic correction, improved user experience and reduced administrative intervention. This solution will remove the complexity and delays associated with manual troubleshooting and fixing by automatic correction. This improves customer user experience and reduces operational expenses.

DETAILED DESCRIPTION

    Session Initiation Protocol (SIP) trunking is a mechanism for the Enterprise/SOHO Unified Communications (UC) network to communicate to the ITSP. A session border controller (SBC) often interfaces the enterprise UC network with a SIP Trunk. The SIP trunk provider services this trunk via its UC core.

    Interoperability issues between the Internet Telephony Service Providers (ITSP) UC core and Enterprise/SOHO UC network are mostly due to the following factors:

1. Often the ITSP UC core is not feature rich and built for speed. The load on this core is high and hence very sensitive to the changes from the Enterprise/SOHO side.

2. The Enterprise/SOHO UC deployment on the other hand is dynamic and many new features get rolled out often. These services would generally be rolled out in phased manner exposing signaling changes to the ITSP.


3. Different interpretation of the SIP protocol across the Enterprise and ITSP.


4. Inconsistent default settings and parameters on the Enterprise and ITSP side.

Copyright 2014 Cisco Systems, Inc.
1


Page 02 of 13

5. Software defects on either side call processing devices.

6. Software upgrades on either side may change the working behavior and result in call flow alterations. Identifying/isolating/tackling/addressing these issues become tedious and very time consuming.

Below are few cases, which explain the interoperability issues.

1. The Enterprise side UC controller relies much on SIP Re-INVITEs for all supplementary services. This generates too many SIP messages on the SIP Trunk, which may be disfavored by the ITSP.

2. Few of the codecs may not be supported by the ITSP. So upon offering these codecs, ITSP always sends 488 SIP response.

3. For an outbound dialer case, it is important to negotiate g711ulaw for user identification (Call Progress Analysis). The ITSP may not like/choose g711ulaw.

4. If the ITSP does not support Secure Real-time Transport Protocol (SRTP), it may reject the call with a 415 response.

5. Few early dialog supplementary services with SIP-UPDATE would not be supported by the ITSP, causing failure of the early dialog transfer services.

6. The SIP session timer value may be configured differently on the ITSP and results in 422 response.

    Typically, when these interoperability issues are detected, the network administrator is required to manually configure different CLI/knobs on the...