Subject: RE: ISUP MIME type

From: "Mark Watson" <[email-masked]>
Date: Wed, 15 Sep 1999 13:14:40 +0100

Eric,

There is no need to 'catalog' all the variants because, as you say, people
can register them on a first-come, first served basis. However if I am on
the receiving end of a Martian ISUP message whose variant name I have never
heared of and do not explicitly support, there is surely value in also
receiving an indication that this is a variant of, say, ETSI ISUP v2, which
I do support.

If I know this, not only can I correctly understand 99% of the message, but
I know what to do with the other 1% of it because I will also receive
'compatibility instructions'. These will allow me to gracefully remove the
'Martian' aspects of the message and so send it onwards into any part of the
PSTN/ISDN which is also based on ETSI ISUP v2.

If you do not capture this information then you need explicit support for
every variant which you might encounter and you have the well-trodden
n-squared problem of mapping between them. I admit it might be possible to
store this information statically, but why bother with this management
hassel when it's easy to it dynamically.

So, this extra information buys you the ability to transport and *interwork*
new protocol variants with potentially zero or minimal software upgrades to
your MGCs.

Regards,

Mark Watson
Nortel Networks, UK

> ----------
> From: 	Eric Zimmerer
> Reply To: 	ericz
> Sent: 	Tuesday, September 14, 1999 11:23 pm
> To: 	Watson, Mark [MOP:EP12-M:EXCH]; 'Adam B. Roach'
> Cc: 	confctrl
> Subject: 	RE: ISUP MIME type
> 
> 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
> 
> 
> 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: Wed, 15 Sep 1999 19:49:33 -0700

Mark,

It seems to me the key word here is "potentially".

Thanks,

Eric

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Wednesday, September 15, 1999 5:15 AM
To: 'Adam B. Roach'; 'ericz'
Cc: confctrl
Subject: RE: ISUP MIME type

Eric,

Regards,

Mark Watson
Nortel Networks, UK