Re: Multimedia contexts for H.320 and H.324 support in megaco/H.g cp

John I don't think you have achieved what you stated your goals were by proposing that there is only one context, and the MG sorts out what to do by the properties of the terminations. For one thing, the picture you are advocating is: +------------------------------------+ | Context C1 | | | | DS0/0 -----\ /---- RTP/101 | | \ / | | DS0/1 -------- o ------- RTP/102 | | / | \ | | H.221/0 ----/ | \---- RTP/103 | | | | | H.233/0 | +------------------------------------+ Not a pretty picture, even if all the terminations have enough properties to allow the gateway to figure out what is intended. You are really into the "chocolate chip cookie model" where you just throw all kinds of different termination types into one context and let them sort themselves out. You also don't like having the MUX visible, but you do want the difference between H.221 and H.223 visible. I don't get it; the MGC doesn't care about the differences, and the MG doesn't need to keep them separate with respect to the MGC. You might as well just have more properties in the Context to deal with the H.221 and H.223 stuff, and not have H.221 and H.223 ephemerals at all. At least by making the mux visible, we deal with the issue that the DS0s are on one "side" of the process with the RTP on the other. I could have drawn the picture above: +------------------------------------+ | Context C1 | | | | DS0/0 -----\ /---- RTP/101 | | \ / | | RTP/102 ------ o ------- H.223/0 | | / | \ | | H.221/0 ----/ | \---- DS0/1 | | | | | RTP/103 | +------------------------------------+ Since there is no natural way to sort out the relationships between the external terminations, they are all in one big hairball. An even worse picture. Making lots of properties of terminations is always possible. It's not going to make the number of operations or the size or number of messages much different. All of the proposals end up having similar sized messages to get the job done, primarily because the operations are based on the external terminations. The differences are in the number of Actions, the number of commands per Action, and the number of properties per command but the product isn't much different for any of the cases. You have smaller numbers of terminations and contexts, but larger numbers of properties. Message sizes should be about the same. There also isn't any great differences I can see in what the MG has to do in order to figure out how to accomplish what it is asked. One large problem is how you specify which RTP flow is which. Since all you have to help you is properties, we would have to add properties to RTP that would specify which media was being asked for on that RTP stream. When you add a new context type, you may have to extend the RTP termination class; very undesirable. This of course extends to all the "packet/cell" termination types -- each of them would have to be extended with the new media types. Finally, you are making a complex case "simple"; H.320 gateways are not the focus of the effort, but are in scope. Support for such uses should be possible, not necessarily optimal. By making contexts multimedia, you complicate the simple cases of single media gateways; not a good thing. So far, we have not needed any parameters to Action other than ContextID. If we really need them, we should add them. I don't want to go there unless we have a good reason. Making H320 gateways simpler is not a good reason IMO. I guess the bottom line is that the current model of one media per context, no context parameters, works for all the really primary cases (Access Gateways, Tandems, residential gateways, NASs, etc.), and it extends, perhaps less elegantly than you would like, to corner cases like decomposed H320 gateways. We have to have a really good reason to add more stuff to the model. While I like my model "best", there is a case to be made for ContextType - I think it's more like "combination rule". The audio rule is "mixing bridge". That clearly does not work for any kind of other media, and doesn't cover all the cases of audio (although it covers 95+% cases!). If there is any change to be made, I think it would be that there is a single, optional parameter to Action which is the combination rule. The default is mixing bridge. That still leaves us with how to handle terminations that are different "types" going into the rule. Properties on terminations is one way, implied naming conventions is another, extra termination classes is another. Similarly, there must be a way to relate multiple streams in a conference. Single context is one way, ConferenceID, either as a parameter to an Action or a property of a termination is another, and implied naming conventions is a third. We can back our way into two parameters on the Action, or we can use one mechanism for stream ID and another for CallID, or we can use one mechanism for both. Implied semantics in TerminationIDs serves both purposes, so I favor that. Brian

Brian, I'll attempt to show an apples to apples comparison of your H.320 model with two DS0s and three IP streams versus John's model with the same. I will do this via attached Powerpoint slide to keep myself from screwing with text formatting all afternoon. The points I have are illustrated on the slide, but I will summarize below. Brian's Model: 1) Five separate Contexts 2) One new Context type (i.e.-MUX; to hold the DS0 and MUX Terminations; could be a Context property as opposed to a new type?) 3) Five new Termination types (MUX, plus H.320 audio, video, data and DS0) 4) Linkage between Contexts is required and is provided via a new Termination property called the "mux ephermal instance identifier" 5) DS0 Terminations exist as separate entities representing physical terminations 6) Multiplex is described with a new Context type and new Termination types, as well as Termination properties required to link Contexts John's Model: 1) One context 2) One new Context Type (i.e.-multimedia; could be a Context property as opposed to a new type?) 3) One new Termination type (H.320) 4) No linkage between Contexts is required 5) DS0 Termination replaced by logical Termination that refers to the physical DS0 6) Multiplex is described with a new Termination type which must refer to the physical DS0s it uses I hope I have not misrepresented either your or John's ideas. I think John's looks quite a bit simpler, but would encourage you guys to maybe put together a little white paper to describe each of your models and to argue your points. This e-mail thread has gotten too hard to follow. May I suggest putting out a Word document with illustrative diagrams? A call flow describing the setup of the H.320 call would be nice to include also so we can see the effects on the model at various points in the setup. Rex Brian Rosen wrote:
participants (2)
-
Brian Rosen
-
Rex Coldren