Christian,
As an aside, do you know if there's any work in the IETF around CAP?
Honestly, I don't know. In theory, CAP could be carried as a MIME part in a SIP message. Most SIP implementations do not properly support MIME, so that might present some problem. Even so, it should be easily specified as an attachment to (or even serve as the main body of) an INVITE. Re: H.460.21
[CNG] I know we have this capacity that's why I think it would be worthwhile to describe in a Annex/Appendix titled something like "CAP usage in H.323 systems".
This is a good idea. Given the informative nature, then it might be best as an Appendix or even a H-series supplement. Perhaps we can do the latter and address all H-series devices? Re: carrying CAP natively in H.323.
[CNG] With regards to the request, are you referring to a liaison or a request by some end user? At least for me it would be good to have a submission by an end user into this discussion. Do you know anybody (or anybody on the list) who would be using or implementing this service? Having their input would help the discussion in SG16.
I've heard no user request this. The only requests we had for consideration of this was this liaison at the Shenzhen meeting and also TD-365/WP2 at the last meeting in Geneva. In TD-365, there was this action item: "Join efforts in increasing support of the CAP standard in various communications systems (in particular those defined by ITU-T, e.g. H.323, IP Cablecom and NGN)." I read this to mean that there is a desire to transport CAP within H.323 systems, not merely that an H.323 system might be able to deliver a voice message in response to some serve outside H.323 having received a CAP message. If it were the latter, then H.323 would need no work to "support CAP". I might have also made this assumption, since Simao had mentioned to me in passing before the last meeting in Geneva that CAP looked relevant to H.460.tm (but don't blame Simao if I read more into his "heads up" than he intended). So, what shall we do? Should H.323 "support" CAP and how? If support means it does not need to transport CAP, we're done. But, I am of the opinion that the *intent* was that support meant we can transport a CAP message. There was certainly no hint that the interpretation expressed in our liaison was misguided, either. Perhaps we need to sync up with OASIS?
So, the question then is "how"? Do we use an IM mechanism that is capable of delivering any kind of "text" (including human-entered, CAP message, a emoticon, a sound bit, or other), or do we create something special just for CAP? I would prefer to avoid the latter, personally.
[CNG] I'm usually for "generic" type mechanisms that can be re-used. From the other emails from what I'm reading is that why re-invent/implement something where there's an existing solution.
The problem is that the other solutions are external to H.323 and not well integrated. To borrow words from the Jingle spec: "Because dual-stack XMPP+SIP clients are difficult to build, given that they essentially have two centers of program control, [5] we have designed Jingle as a pure XMPP signalling protocol." The same could be said of H.323+XMPP. The H.323 device registers with the H.323 network. The XMPP client with the XMPP network. There are two centers of control and no good coordination.
So, does that help your thinking? Or, did I muddy the water?
[CNG] I agree with you on the 2 usages of the CAP as you described above. Given that CAP could be a rather important tool in the future I'd like to see that whatever solution we chose meets the requirements of those using it. That's why I think it would be good to have an end user perspective of it.
And I doubt we'll get an unbiased perspective. Ask Average Joe and he'll ask, "what?" Ask OASIS and they'll say it needed to be done yesterday. :-) So, I think we need to deliver the tools and let people use what is appropriate. If we can carry CAP within the context of H.460.tm, I think we should. The standing question is whether we want to move forward with H.460.tm. I suggest we move forward, as I know there are several who want a native IM-type solution for H.323 where messages can be delivered within and outside the context of a call. I just need to convince a few people to jump on the bandwagon without fear of being volunteered for the editor job ;-) Paul