Subject: Re: ServiceChangeReason - Optional or not?

From: Raju <[email-masked]>
Date: Tue, 2 Jan 2001 09:46:21 -0500

Troy,

About the SDP lines...
H.248 says the SDP line "v=0" is a delimiter to specify multiple sessions in
a single descriptor.
And if there is only one session this line is optional (Some GWC/GWs may not
specify this).

Excerpts from H.248 7.1.8
When multiple session descriptions are provided in one descriptor, the "v="
lines are required as delimiters; otherwise they are optional in session
descriptions sent to the MG.

Thanks
Raju

----- Original Message -----
From: "Troy Cauble" <[email-masked]>
To: <[email-masked]>
Sent: Friday, December 29, 2000 6:42 PM
Subject: Re: ServiceChangeReason - Optional or not?

> Troy Cauble wrote:
> >
> > Hi all,
> >
> > ServiceChangeReason is optional in the ABNF encoding,
> > but not in the ASN.1 encoding.
> >
> > All of the sample messages in Appendix A that
> > have ServiceChangeRequests omit it.
> >
> > Is it optional or not?
> >
> > -troy
>
> OK.  I guess an EMPTY serviceChangeReason Value
> will correspond to a missing serviceChangeReason
> in the ABNF.
>
> So now the question is, how do I encode the following
> specification as an OCTET STRING?
>
> From 7.2.8:  [The ServiceChangeReason parameter] consists
> of an alphanumeric token (IANA registered) and, optionally,
> an explanitory string.
>
> -try
>

---

From: Raju <[email-masked]>
Date: Wed, 3 Jan 2001 10:56:29 -0500

> of an alphanumeric token (IANA registered) and, optionally,

The ServiceChangeReason is an 'alphanumeric token'.
H.248 doesn't follow the ErrorDescriptor (IANA numeric error code + optional
explanatory string) conventions (see H.248 7.3) for the ServiceChangeReason
(which is an IANA alphanumeric string). Why H.248 didn't do this is, these
ServiceChangeReason error cases are part of GW/Termination dynamics, it's
not an "error" (may be some failure).

The following are the registered IANA ServiceChangeReason tokens (each line
is an IANA token):

 900 Service Restored
 901 Cold Boot
 902 Warm Boot
 903 MGC Directed Change
 904 Termination malfunctioning
 905 Termination taken out of service
 906 Loss of lower layer connectivity (e.g. downstream sync)
 907 Transmission Failure
 908 MG Impending Failure
909 MGC Impending Failure
910 Media Capability Failure
911 Modem Capability Failure
912 Mux Capability Failure
913 Signal Capability Failure
914 Event Capability Failure
915 State Loss

One can optionally add an explanatory string add the end of this token (it's
still an OCTET STRING).
The receiver can easily get the ServiceChangeReason Code (900 to 915) using
sscanf(), if it is needed. This is possible because by adding optional
string the sender won't change the ServiceChangeReason token string, it's
just a string append.

Thanks
Raju

---

From: Troy Cauble <[email-masked]>
Date: Wed, 3 Jan 2001 12:09:40 -0500

> The following are the registered IANA ServiceChangeReason tokens (each line

<... snip>

>
> One can optionally add an explanatory string add the end of this token (it's'
                                               ^^^^^^^^^^^ assumption
> string the sender won't change the ServiceChangeReason token string, it's
         ^^^^^^^^^^^^^ assumption

Raju,

I understand that an 'alphanumeric token' and an explanatory string
can be easily combined to make another string.  (Although it's poorly
specified:  Do we assume that they're separated by whitespace?  Do we
assume the order of these two elements?  We're assuming string
concatenation already, probably because of the word "token".)

My real issue (like always:) is encoding a character string as an
ASN.1 OCTET STRING.  You don't address this except to say
"it's still an OCTET STRING".  Which seems to imply that
you think the OCTET STRING will be a byte for byte copy
of the source string.

OCTET STRING is for protocol hole for opaque, 8-bit data.
How a character string is encoded into this has not been
specified and should not be assumed.

Someone else might assume it's compressed some way to take
advantage of the wasted 8th bit in each byte.  Or two parties
might assume it's a byte-for-byte copy, but differ on whether
the NULL is included.

Even worse, serviceChangeReason is no longer an OCTET STRING,
it's a SEQUENCE OF OCTET STRING.  Maybe I'll put the alphanumeric
token and the explanatory string in separate OCTET STRINGs.

If the serviceChangeReason is intended to (always) be a character
string, it should be specified as an ASN.1 IA5String or UTF8String
or one of the many other ASN.1 character string types.

-troy

---

From: Christian Groves <[email-masked]>
Date: Mon, 15 Jan 2001 16:43:23 +1100

G'Day Troy,

The encoding of ServiceChangeReason is not quite a simple problem with
the ASN1. There are several options to rectify the confusion. The ASN1
and ABNF should align on this point. Currently the ABNF allows the
reason to be a quoted string with the reasoncode number and optionally
some other text as you indicate below. The ASN1 also allows this.

The confusion lies in how do you encode the optional text? There are
several options:
1. Delete the text saying that you can add optional information.
    Possibly then:
       a. change the ASN1 and ABNF to have a numerical number.
       b. the leave syntax as is to minimise stack change.
2. Add text to the ASN1 and ABNF saying that you need to add a
whitespace before any additional text.
    Possibly then:
       a. add note to ASN1 saying that it should be encoded as an
UTF8String?

Peoples suggestions on how to capture this?

Cheers, Christian