Editorial comments to H.225.0

[Rich Bowen]

Hi Espen,

Some comments below.

Espen Skjæran (ETO) wrote:
>
> Rich,
>
> I have noticed that some of the meanings/descriptions has changed merely as the new ASN.1 structures for the ServiceControl has been extended to what was in the original proposal. Unfortunately, there was no time to discuss this in Osaka.
> As the editor, I hope you would consider making some minor changes before issuing the white paper. I've added a document with change marks which suggests improvements for these. I believe these changes are purely editorial.
>
> -       The ASN.1 structure, ServiceControlSession, should have change marks for possible extensions. It's my fault, I omitted these in the original proposal.

OK.

> -       The definition of the ServiceControlSession structure is placed in the SCI message defintion. It should be placed in the common section.

OK.

> -       The examples in the definition for serviceControl in ARJ and ACF are copied directly from other messages, but are not relevant for the call state/model.

OK.

> -       How is the structure sent without a URL, for "close"? With a 0-length URL? I propose a separate "null" tag.

How about making the 'address' field OPTIONAL?  I believe this would
result in slightly less coding.

> -       The name "ServiceControlAddress" is no longer covering as it also now holds actual content for service control. I propose it should be replaced "ServiceControlResource" or just "ServiceControl" or something?

How about "ServiceControlDescriptor"?  The field "describes" the
location of the service information in the URL case, and provides a
"SignalsDescriptor" in the signal case.

> -       The textual description of the ServiceControlSession and all messages must be modified to also contain "in-band" content

OK.

>
> Another, not-so-editorial issue is the addition of the "result" tag in SCR from the 248 packages that was added in Geneva. As the SCI may contain several ServiceControlSession structures, I don't think it is clear what they apply to. The SCR message was originally added just to compensate for packet loss, as an application-level acknowledgement is something very different (and in the case of HTTP and multi-format content, can't really be known until the end.)

Just to put this point in context, these are the definitions that were
agreed upon in Osaka for the result field:

  result - This field indicates the result of processing the information
contained
  in the SCI message.  The following values are defined:
    started - The requested service control was started.
    failed - There was some error with the request, so the request
failed.
    stopped - The service control was stopped.
    notAvailable - The requested service control was not available at
the time of
    the request.

This does appear to pose a problem.  This means that when my H.323 code
receives an SCI, it can't immediately turn around and reply with an SCR
to acknowledge receipt of the SCI.  Rather, it has to pass the service
information up to the application layer, and wait for the application
layer to do something with that information.  Then the application layer
has to tell the session layer which result to send in the SCR.  In the
meantime, the sender of the SCI could timeout and retry.

I agree that an application-layer result code doesn't seem appropriate
in the SCR.  But then how could the application layer send a result
indication back to the requestor?  Should we add a 'result' field to the
SCI instead of the SCR, so that the SCI could be used to relay *either*
a session resource descriptor *or* a session-related event (started,
failed, etc.)?

As you said, this last issue is non-editorial, so I'll postpone any
changes related to it until the August meeting.

Regards,
Rich

>  <<h225changes.zip>>
>         Regards,
>         Espen
>
>   ------------------------------------------------------------------------
>                       Name: h225changes.zip
>    h225changes.zip    Type: Winzip32 File (application/x-zip-compressed)
>                   Encoding: base64

--
--------------------------------------------------------------------
Richard K. Bowen                       Cisco Systems, Inc.
rkbowen at cisco.com                      Research Triangle Park, NC
--------------------------------------------------------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com