Subject: Re: FW: Info Method draft

From: Christian Huitema <[email-masked]>
Date: Mon, 23 Aug 1999 12:04:05 -0400

At 02:06 PM 8/23/99 +0000, Donovan, Steven R. wrote: 

>
> Please let me know if there are any objections to the attached request from
> Aparna Vemuri of Level 3.  Aparna has requested that the INFO draft reference
> Eric Zimmerer's ISUP MIME draft instead of the original draft from Christian
> Huitema.

The two drafts are not entirely equivalent, as they try to address two
different problems:

1) The draft by Zimmerer & Vemuri does a very good job of explaining the use of
binary encoding, and only specifies one parameter, a version field that can be
set to         ANSI-ISUP,  ETSI-ISUP, GR-317,BTNUP           BT NUP or R2.

2) My draft had two parameters, variant and headers. "Variant" had the same
intent has the "version" in Zimmerer & Veruni's draft, but allowed coding
points for national variants. Header is intended to signal whether the  MTP-3
routing header was or was not included, with three options, header="routing"
when the addresses and CIC are included, header="CIC" when only the CIC is
included, header="none" when the header is entirely excluded.

The SS7 pointcodes of the source and destinations, as well as the CIC, are not
needed when using SIP, but they are definitely needed in other situations. Just
specifying Q.761-4 is ambiguous; it can be interpreted as either the complete
ISUP message, including pointcodes, or the restricted message, containing only
ISUP parameters. At a minimum, the exact chapter and verse of Q.963 should be
spelled out, in order to remove ambiguities.

In addition, we should note that both drafts have problems. The use of the
"version" field in Zimmerer & Vemuri's examples is inconsistent with the MIME
specification of the content-type header line, and the specific value used in
the example is inconsistent with the parameter's specifications (should be
ETSI-ISUP instead of ETSIv1). Just specifying "header present" in my draft was
noted to be problematic -- if we do that, we have to be able to specify the
format of the pointcodes, which varies from country to country. Also, the
reference to Q.764 in my draft is erroneous (wrong title).

I believe that we should merge, and update, these two drafts. I agree that the
default should be exactly what Zimmerer & Veruni specified (no routing header),
which can be solved by setting the default value of the header parameter to
"none." The only remaining difference would be the extension of the "version"
definition to also allow national variants. The two drafts are both 3 page
long, so the merging could easily be done before COB today...
Christian Huitema

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 23 Aug 1999 13:36:08 -0500 (CDT)

If we're revising the drafts: it seems a bit inconsistent to give a
type of "ISUP" if we're transiting, for example, TUP messages, it may 
be more appropriate to call it something like "application/ss7-userpart".

One more note: how would you encode CAS payloads? The Zimmerer/Vemuri
draft lists R2 as a potential protocol for transit.

-- 
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: Christian Huitema <[email-masked]>
Date: Mon, 23 Aug 1999 15:18:56 -0400

>draft lists R2 as a potential protocol for transit.

Well, if we carry TUP, then we should call it TUP.  If we call it ISUP, it
means that we have translated it to ISUP. I can't speak for Eric, but I
believe this is what he had in mind with an ISUP/R2 payload.

On the other hand, if the call did originate from an MF/R2 interface, I
don't really see the point of carrying an ISUP payload in the first place.
There are pretty few R2 protocol elements that cannot be directly
incorporated in the SIP header fields. (The reason we would bother carrying
ISUP at all is "transparent relay", i.e. make sure that features that are
unused on the SIP/VoIP network can be carried all the way accross.)
Christian Huitema