Subject: RE: SIP-SS7 Mapping and SIP-in-the-middle

From: Jerome Privat <[email-masked]>
Date: Thu, 22 Oct 1998 13:59:01 +0100

The best option is the second one where you use a meta-language in the
middle. As you said, we need to map all the ISUP variants to this
meta-language. But we also need to map other signalling protocols (e.g.
Q.931, Q.2931, DPNSS, ...) to this meta-language.

Jerome

Jerome Privat
Applied Research&Technology
BT Labs

>----------
>From: 	Dean Willis[SMTP:[email-masked]]
>Sent: 	Wednesday, October 21, 1998 10:30 PM
>To: 	Conference Control List
>Cc: 	Matthew Cannon; Steven R. Donovan
>Subject: 	SIP-SS7 Mapping and SIP-in-the-middle
>
>
>A couple of the folks here were covering  whiteboards with scribbles
>last week and ran into something that I think bears discussion in this
>forum. For lack of a better term, we called it the "SIP-in-the-middle"
>problem.
>
>This situation occurs when a call originating on PSTN is signaled via
>ISUP to a SIP gateway, carried on IP, signaled back to ISUP at another
>gateway, then terminated back to PSTN. The problem is that many ISUP
>parameters not required by SIP will be needed to correctly handle the
>call at the destination. This of course is compounded by the many
>varieties of ISUP in general use . . .
>
>Two proposals were made in our whiteboard session:
>
>1) Carry the delivered ISUP data as a binary attachment on the SIP and
>make the gateways responsible for dealing with it.
>
>2) Map the ISUP (of which there are many varieties) to some sort of
>meta-language which provides the basis for ISUP translations, and carry
>this meta-language as an attachment.
>
>The first proposal keeps the SIP simple, but could make the gateways
>very complex as they may be held responsible for interpreting "alien"
>ISUPs, iff SIP is used between divergent ISUP terminations. This is the
>translation problems that wakes carrier engineers up at night every
>time
>a potential merger is announced . . .
>
>The second proposal may require significant development work, but
>provides much simpler gateways as only a single translation need be
>understood by each gateway.
>
>Both proposals keep SIP clean as they both carry "ISUP" as an
>attachment.  The only difference is that the second proposal involves
>translating from a local variant of ISUP to a "meta" ISUP at the
>ingress
>gateway and translating back to a local variant at the egress gateway.
>
>Discussion?  I know that SS7-to-SIP mappings are in pre-draft
>discussion. Is anyone aware of a generalized representation for
>divergent ISUPs that might be used as a reference? Maybe somebody has
>some even better ideas?
>
>--
>Dean Willis
>
>[email-masked]
>MCI Data Architecture LOC 1916/041
>IP Telephony Architecture and Standards
>voice  972-729-4162 or v 772-4162
>page   888-266-1761
>fax    972-729-3034
>
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 22 Oct 1998 09:31:09 -0400

The first alternative is better in principle, perhaps with the ISUP unpacked
and translated into tag-length-value form so downstream nodes have an easier
time of parsing it.  As Henry says, ISUP (or whatever) interworking has to
happen anyway.  It's an engineering decision which node has to translate
into the other's version.

> -----Original Message-----
> From:	Dean Willis [SMTP:[email-masked]]
> Sent:	Wednesday, October 21, 1998 5:31 PM
> translation problems that wakes carrier engineers up at night every time
> translating from a local variant of ISUP to a "meta" ISUP at the ingress