Subject: RE: ISUP MIME type

From: "Mark Watson" <[email-masked]>
Date: Mon, 13 Sep 1999 13:59:55 +0100

Adam,

I essentially agree with your comment (1), you are right that it would be
better to rely on SIP itself where the service level of the external
telephony network supported is very low, as of course it is with register
signalling. There will doubtless be some things supported by register
signalling which aren't (yet) supported by SIP - overlap signalling perhaps
?

Regarding your comment (2), I think there is value to be gained by
standardising on an ISUP variant wherever possible  and trying to keep the
real legacy stuff (like BT NUP) out of the IP domain. The problem with
sending BT NUP over the IP network is that you have to be sure that if the
other end is a PSTN/ISDN gateway as well, then it understands BT NUP. This
is not reasonable as this gateway may not even be in the UK. If you use UK
ISUP, then as long as the egress PSTN network supports some kind of ISUP,
you will be able to maintain transparency of the narrowband ISDN services.

Regards,

Mark Watson
Nortel Networks

> ----------
> From: 	Adam B. Roach
> Sent: 	Friday, September 10, 1999 9:36 pm
> To: 	Watson, Mark [MOP:EP12-M:EXCH]
> Cc: 	[email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: 	Re: ISUP MIME type
> 
> >Telephony User Part/Register signalling
> >
> >Some countries still use the older Telephony User Part or even register
> >signalling such as R2, rather than the ISDN User Part for their
> signalling.
> >In a number of countries (in particular most of Europe) national variants
> of
> >ISUP exist which can be used in place of the TUP variants with no loss of
> >services.
> >
> >Standard ISUP can be used in place of register signalling.
> >
> >When moving to IP technology, it does not make sense to perpetuate this
> >legacy signalling within the IP network, when the level of services can
> be
> >maintained with ISUP. There is therefore no need to carry protocols such
> as
> >BT NUP (aka IUP), France's SSUTR2, R2 etc.
> 
> I have two comments on this topic:
> 
> 1) Since the purpose of an ISUP mime type is for (semi) transparancy of 
>    signalling information, and since the information conveyed by CAS
>    systems is quite rudimentary, it is decidedly unnecessary to 
>    carry *any* sort of telephony signalling body in the case of R1 or R2 
>    interworking scenarios. The discussion of converting CAS to an
> equivalent 
>    ISUP to pass it across an IP network is ludicrous. I beleive it is
>    sufficient to just put the CAS information in the SIP message (e.g.
> To:)
>    and have no signalling in the body. Remember: the far end gateway will
>    still have the capability to generate its own ISUP/NUP/CAS (as
>    appropriate) based on SIP headers, even without a signalling body; if 
>    it doesn't, it has no hope of interoperating with regular SIP nodes.
>    (And if you can't do that, why are you using SIP?!?)
> 
> 2) Similarly, the purpose of an ISUP mime type (and I still think
>    we should be working to define an "application/ss7-userpart" mime type
>    instead) is for ferrying user part packets from one end of the network 
>    to the other, with no real interpretation in the middle. So it seems 
>    unnecessary to force TUP protocols to be translated into ISUP. For 
>    instance, it seems like a heck of a lot of extra work to translate 
>    incoming BT NUP to British ISUP for its IP journey, and then have the 
>    egress gateway translate it *back* to BT NUP to put it out on the PSTN.
> 
> --   
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS
> L-04
> [email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081
> USA
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 13 Sep 1999 10:16:20 -0400

> signalling which aren't (yet) supported by SIP - overlap signalling perhaps

Overlap signaling is supported. See the 484 status code.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Eric Zimmerer" <[email-masked]>
Date: Mon, 13 Sep 1999 08:33:06 -0700

Regarding comment 2,

The scenario that Adam describes, where BT NUP is translated into ISUP,
transported via IP and then translated back into BT NUP implies
less-than-optimized interworking logic on the originating MGC.

It makes sense that the originating MGC will have a good idea about where
the call is going, and what protocols are understood by the terminating MGC.
If the originating MGC knows the terminating MGC "speaks" BT NUP, then there
is no need to translate it.  If the originating MGC does not know enough
about the terminating MGC, then Mark's comment about standardizing on an
ISUP variant solves the problem.  Pick a variant and standardize it as the
"lowest common denominator" ISUP variant.

Adam's scenario is still possible, but its occurrence is minimized.

Eric

=======================
<snip>

Regards,

Mark Watson
Nortel Networks

<snip>
> Adam Roach, Ericsson Inc.

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 13 Sep 1999 17:02:55 -0500 (CDT)

Eric> The scenario that Adam describes, where BT NUP is translated into
Eric> ISUP, transported via IP and then translated back into BT NUP
Eric> implies less-than-optimized interworking logic on the originating
Eric> MGC.

I beleive you missed my point altogether: my example was meant to 
highlight the fact that Mark Watson's current proposal specifies
that BT NUP **can't** be transited across the IP network. Even if the 
MGC knows that the far end speaks BT NUP, Mark's messages imply that
it **must** be translated to ISUP before encapsulation in a SIP message. 

Allow me to re-quote the exact section of Mark's message to which
I was responding:

Mark> When moving to IP technology, it does not make sense to perpetuate
Mark> this legacy signalling within the IP network, when the level of 
Mark> services can be maintained with ISUP. There is therefore no need 
Mark> to carry protocols such as BT NUP...

Eric> If the originating MGC knows the terminating MGC "speaks" BT NUP, 
Eric> then there is no need to translate it.

I couldn't agree more. This is what I'd like to see: a draft that 
addresses transit of User Part messages in general, not just ISUP 
messages. Eric's draft appears to do this (although the name of
"application/ISUP" is horribly misleading if it is allowed to transit
TUP variants). What Mark has proposed in his "Comments on the proposed 
ISUP MIME type" explicitly does *not* allow this.

Finally, to address one of your earlier comments: why would we want to 
go through the effort to define separate ISUP and TUP drafts, when
they'll be doing the same thing? By defining an "application/ss7-userpart"
draft, we do the work *once* for both.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: "David Oran" <[email-masked]>
Date: Tue, 14 Sep 1999 10:09:06 -0400

One of the nice things about SIP's architecture is that you can move
functions around. The ingress gateway could do the ISUP variant translation,
the terminating gateway could do the translation, or, the ingress, on seeing
an ISUP variant it didn't know what to do with, could forward the SIP
message to a SIP proxy that had the capability to do  ISUP variant
translation.

Which of these you do is an implementation decision.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Eric Zimmerer
> Sent: Monday, September 13, 1999 11:33 AM
> To: 'Mark Watson'; 'Adam B. Roach'
> Cc: [email-masked]
> Subject: RE: ISUP MIME type
>
>
> Regarding comment 2,
>

---

From: "Eric Zimmerer" <[email-masked]>
Date: Tue, 14 Sep 1999 15:04:04 -0700

Adam,

We decided not to include non-ISUP user parts in the draft.  I believe a
well defined target is easier to hit.

If you would like to target BT NUP, I will be happy to give you comments on
your draft.

Thanks,

Eric

-----Original Message-----
From: Adam B. Roach [mailto:[email-masked]]
Sent: Monday, September 13, 1999 3:03 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]

---

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 14 Sep 1999 18:24:33 -0500 (CDT)

>If you would like to target BT NUP, I will be happy to give you comments on

I doubt you would have many. Were I to produce such a draft, I
would do by loading yours into a text editor, performing a
search-and-replace to change "ISUP" to "BT-NUP," and adding my
name.

Which is precisely why I see no need for two (or more) documents.