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

From: "Dean Willis" <[email-masked]>
Date: Wed, 21 Oct 1998 16:30:39 -0500

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: "Henry Sinnreich" <[email-masked]>
Date: Wed, 21 Oct 1998 21:30:21 -0500

This is a generic problem for transport of telephony signaling, no matter if
SIP or tunneling or something else.

Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Dean Willis
> Sent: Wednesday, October 21, 1998 4:31 PM
> To: Conference Control List
> Cc: Matthew Cannon; Steven R. Donovan
> Subject: SIP-SS7 Mapping and SIP-in-the-middle
>
>
>

---

From: Bobby Sardana <[email-masked]>
Date: Thu, 22 Oct 1998 20:48:27 -0500

Greetings:

> this meta-language as an attachment.

In both cases, whether (1) or (2), the gateway should possess the
intelligence for the conversion and hopefully not the SIP server.

For a thought, why not provide XML DTD's for SS7 and ISUP (and its
variants) and let gateways performs the conversion and attach/detach them
to/from
SIP messages.

Bobby Sardana.
[email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Fri, 23 Oct 1998 11:45:02 -0400 (EDT)

> variants) and let gateways performs the conversion and attach/detach them

You don't really want to translate ISUP in any ways (except maybe
do some conversion to hexadecimal or base64 for carrying in a
text form.) The ISUP format is ripe with 1980-style bit splicing,
which is hard to translate and also much more compact than
any text form.  It is probably better to carry an untranslated
attachment.   However:

1) This may pose some privacy problems.  ISUP is not meant to be
   disclosed to the end user.  What of, for example, service
   bit such as the presentation indicator in the calling party
   number?  How do you prevent the SIP message to carry these all
   the way to the third party?

2) SIP provides a clear mapping for the basic call set up messages,
   IAM, ACM, ANM, CPG, REL, RLC.  But what of facilities messages?
   information? call tracing/identification? continuity test?

Using SIP to carry ISUP is a reasonable idea.  But we need to do a bit more
than just slap ISUP in the messages.  A possible solution to the second
problem, for example, could be to carry some form of end-to-end
(gateway controller to gateway controller) identification, which would
then enable the gateways to transparently exchange ISUP ancillary 
messages relating to a call.

-- 
Christian Huitema