Subject: RE: ISUP MIME type

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

> ----------
> From: 	Henning Schulzrinne
> Sent: 	Monday, September 13, 1999 3:16 pm
> To: 	Watson, Mark [MOP:EP12-M:EXCH]
> Cc: 	'Adam B. Roach'; [email-masked]; [email-masked];
> [email-masked]
> Subject: 	Re: ISUP MIME type
> 
> Mark Watson wrote:
> > 
> > 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
> > ?
> 
> Overlap signaling is supported. See the 484 status code.
> 
Yes, but it is hardly efficient and relies on the server knowing that more
information is required. If you are interworking with PSTN equipment then
you will receive a backwards indication when the address in *complete*, but
you will not receive any indication that the address is incomplete - the
equipment will just be waiting for you to send subsequent digits.

Regards,

Mark Watson
Nortel Networks

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

---

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

Eric,

I think there is advantage in having the heirachy I suggest with the
'protocol' and 'version' parameters. This allows nodes which don't support
the particular variant being transported to make use of the subset that they
do support, be that ETSI, or just plain ITU-T ISUP. A flat name-space would
not allow this.

However, when it comes to variants of those main regional standards, I think
leaving the name-space open would be a great idea. I'd like to see some way
that registration of multiple names for the same thing be
discouraged/prevented though.

Regards,

Mark Watson
Nortel Networks

> ----------
> From: 	Eric Zimmerer
> Reply To: 	ericz
> Sent: 	Friday, September 10, 1999 9:51 pm
> To: 	Watson, Mark [MOP:EP12-M:EXCH]; confctrl
> Subject: 	RE: ISUP MIME type
> 
> 
> 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,
> 
> 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: "Donovan, Steven R." <[email-masked]>
Date: Wed, 22 Sep 1999 21:35:28 +0000

Eric,

I seem to be missing something here.  Why is there an aversion to
generalizing the draft to be SS7 user parts instead of just ISUP.  The
Internet is international in scope and carriers will need to interface with
all different varieties of country specific user parts.  It doesn't seem an
efficient use of our time to require a separate MIME type for each when
Adam's proposal will handle them all at once.

Steve

-----Original Message-----
From: Adam B. Roach [mailto:[email-masked]]
Sent: Tuesday, September 14, 1999 6:25 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: ISUP MIME type

>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.

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.

--
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