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@cisco.com Research Triangle Park, NC --------------------------------------------------------------------

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