Annex K over multiple domains (Regarding APC-1934)

[Espen Skjæran (ETO)]

Dear M.Ishii and S.Minono,

Thank you for addressing the errors and ambiguities in H.323 Annex K in APC-1934. I am sorry I could not attend to the meeting, but will try to explain my comments here.

I have also though about the use of Annex K (and other service control mechanisms using the ServiceControlSession scheme) outside the local zone, for example using Annex K from home domain to the visiting terminal would be of great value. However, I have intentionally delayed contributions on this field as I wanted the mobility work to have a clear architecture and messages before the service control issues are brought in.

I have targeted the ServiceControl codepoints for Annex K in call signaling messages, along with RCF and SCI, for simplicity. The other RAS messages have included this for other applications, e.g. the call credit. I have assumed that annex K communication exist between the local gatekeeper and the endpoint, or between two entities in a call. Now as you suggest, we can also do useful services between different entities out of a call, and that shouldn't be restricted.

2.5.1 Adding ServiceControl fields to LRJ/LCF
I have sort of assumed that most applications want the possibility to update a session later, in which case they need an open channel towards the endpoint. The LCF/LRJ message is a one-time thing.
Also, to do services that interact with call control layer a service provider needs the call signaling channel anyway, in which case they wouldn't need the URL in the LCF message, but rather do the whole thing within the call signaling channel.
But as you say, lightweight applications could take use of a ServiceControlSession in LRJ/LCF messages, for example by showing a list of other call addresses through the H.323 URL.
I have nothing against adding the ServiceControlSession to LRJ/LCF.

2.5.2. Forwarding the SCI message by gatekeepers
Forwarding the SCI message, I think, will require quite substantial changes to the SCI message, along with addressing schemes in the existing gatekeepers. I like the idea that the RAS messages (well, at least most of them), have clear states and are kept on the same interface, in this case terminal-gatekeeper.

What about following the same schemes as H.450 and H.323 Annex L instead? Using call independent signaling? (ConferenceGoal = callIndependentSupplementaryService)
This way we don't have to include addressing info in SCI, we reuse existing gatekeeper policing and addressing schemes. Services will be available even if the client's gatekeeper does not support v4 or Annex K. Also, the use of the sessionID will be clear (as these are defined over one specific interface).

I hope this clarifies my points and that my suggestions satisfy you.
I guess the addition of ServiceControl fields to LRQ and LCF would be the job of H.225 editor, while I can bring in a statement about the use of call independent signaling in K.2.1 and K.2.2?

Regards,
Espen Skjaeran

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