Page History

Panel

In this section:

Table of Contents

maxLevel	3

Scenarios

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.

Caption

0	Figure
1	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
Spacevars
0 product
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
Spacevars
0 product
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
Spacevars
0 product
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).

Pagebreak