SBC support for SIP-I to tunneling ISUP signaling

In this section:

Scenarios

SIP-I(ISUP Variant-A) ->
Unable to show "metadata-from": No such page "_space_variables"
-> SIP-I(ISUP Variant-B)
SIP-I(ISUP Variant-A) ->
Unable to show "metadata-from": No such page "_space_variables"
-> SIP
SIP ->
Unable to show "metadata-from": No such page "_space_variables"
-> SIP-I (ISUP Variant-A)

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.

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
Unable to show "metadata-from": No such page "_space_variables"
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
Unable to show "metadata-from": No such page "_space_variables"
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
Unable to show "metadata-from": No such page "_space_variables"
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).