DO NOT SHARE THESE DOCS WITH CUSTOMERS!

This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.

In this section:

Scenarios

  • SIP-I(ISUP Variant-A) -> SBC -> SIP-I(ISUP Variant-B)
  • SIP-I(ISUP Variant-A) -> SBC -> SIP
  • SIP -> SBC -> SIP-I (ISUP Variant-A)

Background Information

  • The requirements specified in the section "Background Information and Dependencies" under Minimal Out-Of-The-Box Configuration are met.
  • Ports and IP Interface Groups have been configured as described in NNI: Complex route selection.
  • SIP-I (or SIP-T) connects two PSTN networks which support ISUP but use a VoIP network in between
  • SIP-I defines a MIME attachment which allows a PSTN->VoIP gateway to encode the ISUP call control message an embed it within the SIP method.
  • The native SIP content and the equivalent contents in the ISUP MIME are consistent.
  • A SIP-I tunnel across a VoIP network allows PSTN services to function seamlessly end-to-end.

Description

SBC support for SIP-l to tunneling ISUP signaling

  • For ISUP A->SIP-I->ISUP A, the source and destination ISUP versions are the same and the SBC components in the middle are simply transiting the MIME attachment.
  • For ISUP A->SIP-I->ISUP B (depicted by the orange arrows), the source and destination ISUP versions are different and the SBC must understand the ISUP MIME and convert from one variant to another.
  • For ISUP A->SIP (depicted by the blue arrows), the call is destined to a point where the ISUP MIME can no longer be understood (such as terminating to a SIP IAD) and the SBC must interwork the SIP-I/ISUP-MIME into plain SIP. In these cases, the operators may insist on mapping of ISUP information into non-standard SIP headers in order to preserve the functionality of some feature (e.g. BT, CPWH with RBWF).

  • No labels