Subject: ISUP MIME type

From: "Mark Watson" <[email-masked]>
Date: Fri, 10 Sep 1999 16:04:52 +0100

Hi,

I have some comments on the Internet Drafts proposing an ISUP MIME type -
basically I think these could be improved to better capture the types of
ISUP variants which exist and the relationships between them.

This idea is described in detail below. There are four open issues at the
end - can anyone help with these ?

I've cross-posted this to mmusic and sigtran since similar I-Ds have been
put forward in both groups. I suggest follow-ups go to mmusic only to save
confusion.

Regards,

Mark Watson
Nortel Networks, UK
+44 1628 434456
[email-masked]

Comments on the proposed ISUP MIME type
-----------------------------------------------------------------------

Internet draft draft-zimmerer-mmusic-sip-isup-mime-00.txt (July 1999)
describes a new MIME type for carrying C7 ISUP messages within the body of a
SIP request/response.

A key feature of ISUP signalling, from ITU-T White Book onwards, is the
compatibility mechanism. This introduces forward compatibility in that
allows future versions of the protocol, and regional and national variants
of the protocol can be sucessfully processed by node conformant to earlier
specifications.

This is achieved by new protocol extensions being accompanied by
'compatibility extensions' which tell earlier version nodes how to process
the unrecognised parameters and messages - either pass them on, discard them
or clear the call.

Therefore, if a node knows that a particular variant of ISUP is based on
ITU-T White Book, then it need not understand the whole variant in order to
sucessfully process it. This is particularly the case in 'toll bypass'
applications.

Equally, if a node knows that a particular ISUP is based on ETSI ISUP v2,
and the node supports ETSI v2, then it can sucessfully process the ETSI
extensions, without needing to know any other national extensions which may
be present.

It would be desireable to include mode detailed ISUP variant information in
the MIME content type for ISUP. This would allow nodes supporting just ITU-T
White Book to sucessfully process regional and national variants of White
Book.

This could be achieved by several parameters instead of the single 'version'
parameter to the application/isup media type.

The first parameter 'protocol' would indicate whether the protocol was based
on Blue Book (i.e. no compatibility mechanism) or on White Book or later
(i.e. compatibility mechanism):

Parameter Name: 'protocol'	Value set: { 'ISUPblue', 'ISUPwhite' }

The second parameter would indicate whether any extensions specified by a
regional standards body were present, or whether the protocol was the Q.767
version of blue book (a subset of Blue Book specified for International
Use).

Parameter Name: 'version'	Value set: 	protocol=ISUPblue	{
'ansi', 'etsi', 'q767', 'ntt' }
						protocol=ISUPwhite	{
'ansi', 'gr317', 'etsi', 'ntt' }

So, 'protocol=ISUPblue version=etsi' implies ETSI ISUP v1 (which happens to
be the same as 'book=blue version=q767'). 'protocol=ISUPwhite version=etsi'
implies ETSI v2 or higher. Note it is not necessary to distinguish between
ETSI ISUP v2 and higher versions because of the compatibility mechanism.

Similar clarification for the ANSI versions of blue and white book is
required, as well as for Japanese and other regional version (if there are
any)

Finally, there are a number of national variants of ETSI ISUP v1 and v2. In
the case of the v2 variants, then comprehension of the national extensions
may not always be required according to the compatibility mechanism. Some
kind of country identification is required - I've used informal two
character country codes, but a more formal identification scheme is
required.

Parameter Name: 'extensions'	Value set:	protoco=ISUPblue
version=etsi		{ 'it', ... }
							protocol=ISUPwhite
version=etsi 	{ 'uk1', 'uk2.2', 'fr' ... }
							protocol=ISUPwhite
version=ntt	{ '90.10v1', '90.10v2' }

Further work is required on this proposal to correctly capture the various
versions of ANSI ISUP and Japan ISUP. The value sets for the 'extensions'
parameter could be owned initially by the regional standards bodies, but
should be delegated to individual national standards organisations.

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.

In certain other countries there may not yet be a national variant of ISUP
which can suport the same services as the national TUP (e.g. China ?) and in
these cases there may be a need to carry the TUP signalling. It may
therefore be necessary to extend the value set for the 'protocol' parameter
to include { 'TUPred', 'TUPblue' } etc.

Examples

UK ISUP version 2.2 would therefore be encoded as:

Content-type: application/isup; protocol="isupwhite" version="etsi"
extensions="uk2.2"

Chinese TUP might be encoded as:

Content-type: application/isup; protocol="tupred" version="china"

If the extension to TUPs is decided to be required, then it may be sensible
to rename the MIME subtype to 'ccs7' for 'Common Channel Signalling System
No. 7'.

Proposal

The ISUP MIME type parameters should be enhanced as described above to
better capture the version/variant information.

Open Issues

1) What are the versions of ANSI/Bellcore ISUP which need to be captured ?
2) What are the versions/variants of Japanese ISUP which need to be captured
?
3) Are there any other regional standards bodies which have defined an ISUP
other than ANSI, ETSI and Japan ?
4) What is the best naming scheme for the 'extensions' parameter in order to
give every country some name-space ?

ends

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 10 Sep 1999 15:36:34 -0500 (CDT)

>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: "Eric Zimmerer" <[email-masked]>
Date: Fri, 10 Sep 1999 13:51:08 -0700

Mark,

You make some interesting suggestions.  If you want to create a naming
convention for all the possible ISUP variants, please feel free to do so.  I
don't think it is something I am interested in persuing, however.

You hit the nail on the head when you said "it does not make sense to
perpetuate this legacy signalling within the IP network".  That is one of
the prime motivations for encapsulating ISUP.  If we can put a wrapper
around ISUP and use it for backwards compatibility, we can move forward with
IP enabled services.

Your first two open issues (versions of ISUP to be captured) point to the
key issue: who needs to capture them?  It seems to me that an efficient
course of action is to name and catalog variants as the need arises.  I say
the first one to need/use/publish an ISUP variant as a MIME type gets to
name it ;-) (Please don't name it "Eric Zimmerer")

Your third issue should be taken care of by those who need to capture such
variants.

Your fourth issue is satisfied by letting the first implementer pick the
name.

As far as TUP goes, this is not a TUP MIME type draft.  We could easily
produce a TUP MIME type draft, and perhaps we should.

Thanks,

Eric

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Friday, September 10, 1999 8:05 AM
To: [email-masked]'; [email-masked];
[email-masked]'; [email-masked]'
Subject: ISUP MIME type

Hi,

Regards,

Mark Watson
Nortel Networks, UK
+44 1628 434456

Examples

Proposal

Open Issues

ends