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
Figure 1: SBC support for SIP-I 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).
Overview
Content Tools