Subject: RE: ISUP MIME type

From: "Mark Watson" <[email-masked]>
Date: Tue, 14 Sep 1999 10:36:46 +0100

My proposal was just motivated by the desire to keep stuff like BT NUP out
of the IP network if at all possible. If you want to keep a list at your
originating MGC of the places to which it is 'safe' to send BT NUP, then by
all means go ahead - I don't want to do it but I'm not going to stop you.
So, I don't object to Adam's proposal of an application/ss7-userpart MIME
type or Eric's suggestion of an application/tup MIME type.

I'm afraid I have a pathelogical hatred of BT NUP which anyone else with
experience of this protocol will hopefully understand :-)

The main part of my comment was to suggest that we capture the compatibility
relationships between various ISUPs in the MIME parameters - what do you
think of that part ?

Regards,

Mark Watson
Nortel Networks

> ----------
> From: 	Adam B. Roach
> Sent: 	Monday, September 13, 1999 11:02 pm
> To: 	[email-masked]
> Cc: 	Watson, Mark [MOP:EP12-M:EXCH]; [email-masked];
> [email-masked]
> Subject: 	Re: ISUP MIME type
> 
> 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: "Eric Zimmerer" <[email-masked]>
Date: Tue, 14 Sep 1999 15:23:30 -0700

Mark,

Capturing the compatibility relationships between ISUP variants does not
seem to buy me anything.

If we assume that MGCs will exist in a service provider's network, then
there will be coordination that will enable interoperability/compatibility
using a limited number of variants.

In this case, a complete catalog of variants and relationships is overkill.

If this assumption is not valid, and MGCs exist in an environment similar to
hosts on the internet, (can you say chaos?) picking one ISUP variant and
"standardizing" on it makes the most sense to me.

In this case there is no need for a catalog of variants either.

Eric

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Tuesday, September 14, 1999 2:37 AM
To: [email-masked]; 'Adam B. Roach'
Cc: [email-masked]
Subject: RE: ISUP MIME type

Regards,

Mark Watson
Nortel Networks