- sg16-avd - lists.packetizer.com

Re: Implementers Guide Edits
by Callaghan, Robert 30 Apr '99

30 Apr '99

Another alternative: Just uploaded the following to ftp://incoming.redhat.com/libc6 They should available on ftp://contrib.redhat.com soon. mswordview-0.5.10-1.i386.rpm 554335 mswordview-0.5.10-1.src.rpm 865947 These files are also available on the following sites My main RPM archive at ftp://ftp.falsehope.com/pub/mswordview which is mirrored at ftp://ftp.tux.org/pub/sites/ftp.falsehope.com/mswordview Or on FreshMeat at ftp://ftp.freshmeat.net/pub/rpms/mswordview RPMs are built on a Pentium 200mmx w/256megs RAM with RedHat 5.2 plus updates from ftp://updates.redhat.com installed. Required programs to install shared binary rpm. Programs listed here are either updates or are not in the default RedHat 5.2 installation. ----------------------------------------------- freetype-1.1-5.1 installed. ----------------------------------------------- ------------------------------------------------------------------ Robert Callaghan Siemens Information & Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: Thursday, April 29, 1999 4:41 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Implementers Guide Edits Use Corel WordPerfect 8 for Linux (http://linux.corel.com/linux8/download.htm) It'll read Word docs and it's free. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Jonathan E. Peace [SMTP:jonathan.peace@CONEXANT.COM] Sent: Thursday, April 29, 1999 3:10 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Implementers Guide Edits Hi Jim, Is there any good reason why docs cannot be distributed in a more cross-platform form such as PDF? Some people use Linux these days you know:) J > Greetings, > > Attached is the updated text from the Implementers guide that > incorporates > the comments that I got back from the previous posting. Specifically it > includes elements from Espen Skjaeran, Dave Walker and Karl Klaghofer. > > Any final comments ASAP to me. > > Best Regards, > jimt. MetaTel - Boston, MA > mailto:jim.toga@metatel.com +1-781-891-9000 > PGP keyID E746 1CE4 CEC0 C91E 7190 65CA 70B1 B1D2 6A1E A2B7 > > ------------------------------------------------------------------------ > Name: TD-implementers guide.doc > TD-implementers guide.doc Type: Microsoft Word Document (application/msword) > Encoding: base64 > Download Status: Not downloaded with message

1 0

Megaco/H.gcp call
by Bryan Hill 30 Apr '99

30 Apr '99

Colleagues, We would like to hold another H.GCP/Megacop audio call on Tuesday May 4th at 10 AM until noon EST. Agenda for the call is as follows 1. Discuss multimedia/H.320 support 2. Discuss SDP/H.245 message formats 3. Any issues/question for the latest megacop draft The call details are listed below and as usual, comments presented during this call carry equal weight as those on the Megaco and ITU reflectors. The SG16 meeting in Santiago is fast approaching and reaching consensus on these topics prior to this meeting is clearly the goal of this call. Date: Tuesday May 4th/99 Time: 10:00amEST - 12:00pmEST Phone: 1-613-763-6338 PassCode: 131313# ***Problems getting on the call? Call 1-613-765-CONF, and ask for the conference chaired by Nancy Greene ***No tones will announce people joining or leaving the conference ***Minutes from the call will be posted by the end of the day to both the Megaco and the SG16 mailing lists ***supposedly 63 will mute your phone, and 64 will unmute it - if you are about to use it, let Nancy Greene know - we had problems with it last time... Of course your regular phone mute button should work with no problems. Nancy Greene Bryan Hill ngreene(a)nortelnetworks.com <mailto:ngreene@nortelnetworks.com> bhill(a)videoserver.com <mailto:bhill@videoserver.com> ----------------------------------------------------------------------------

1 0

Re: Implementers Guide Edits
by Paul Long 29 Apr '99

29 Apr '99

Use Corel WordPerfect 8 for Linux (http://linux.corel.com/linux8/download.htm) It'll read Word docs and it's free. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Jonathan E. Peace [SMTP:jonathan.peace@CONEXANT.COM] Sent: Thursday, April 29, 1999 3:10 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Implementers Guide Edits Hi Jim, Is there any good reason why docs cannot be distributed in a more cross-platform form such as PDF? Some people use Linux these days you know:) J > Greetings, > > Attached is the updated text from the Implementers guide that > incorporates > the comments that I got back from the previous posting. Specifically it > includes elements from Espen Skjaeran, Dave Walker and Karl Klaghofer. > > Any final comments ASAP to me. > > Best Regards, > jimt. MetaTel - Boston, MA > mailto:jim.toga@metatel.com +1-781-891-9000 > PGP keyID E746 1CE4 CEC0 C91E 7190 65CA 70B1 B1D2 6A1E A2B7 > > ------------------------------------------------------------------------ > Name: TD-implementers guide.doc > TD-implementers guide.doc Type: Microsoft Word Document (application/msword) > Encoding: base64 > Download Status: Not downloaded with message

1 0

Re: Implementers Guide Edits
by Francois Audet 29 Apr '99

29 Apr '99

It looks like the H.323/Annex C comments have also been incorporated. ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com > Greetings, > > Attached is the updated text from the Implementers guide that > incorporates > the comments that I got back from the previous posting. > Specifically it > includes elements from Espen Skjaeran, Dave Walker and Karl Klaghofer. > > Any final comments ASAP to me. > > Best Regards, > jimt. >

1 0

Synchronization Of Streams
by Tom-PT Taylor 29 Apr '99

29 Apr '99

This is a question which affects the design of the Media gateway control protocol. What information must be passed to the MG so it knows which media streams have to be synchronized? Is it sufficient that the MG knows which streams are flowing over the same user connection, or does the relationship have to be specified on a per-stream basis. I know that H.245 allows the latter, but I am considering the possibility of a Termination in a multimedia context, which binds together multiple H.245 Logical Channels. Under that circumstance, can the MG use rules to know that, for instance, audio and video are synchronized but data flows independently? Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 736 0961 (ESN 396-1490) FAX: same number by prior arrangement (manual answer).

1 0

ASN.1 compilers; request
by Dale L. Skran 28 Apr '99

28 Apr '99

While at the IMTC meeting in Munich yesterday, a question was raised by an implementor who was having trouble compiling the ASN for H.323 V2. I suggested using the OSS or Teles ASN.l compilers, both of which he had not yet tried. However, this raises some interesting questions: 1)What is the complete list of available ASN.1 compilers, both commercial and free? 2)Are there known problems with some products that implementors should be warned about? I have in mind a section in the implementors guide on this topic. Please post responses to this request to the list so that all can benefit ASAP. I will as the editor of the implementor's guide to collect and edit the results for the guide. Thanks for your attention, Dale Skran Q13 Rapporteur

3 3

Re: Multimedia contexts for H.320 and H.324 support in megaco/H.g cp
by Brian Rosen 28 Apr '99

28 Apr '99

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 > -----Original Message----- > From: John Segers [mailto:jsegers@LUCENT.COM] > Sent: Wednesday, April 28, 1999 1:44 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Multimedia contexts for H.320 and H.324 support in > megaco/H.gcp > > > Over the past couple of days there has been some interesting > discussion > on the mailing list with respect to multimedia support in > H.gcp/MEGACO, > starting with Tom Taylor's note. Unfortunately I have been > off-line and > have not been able to respond until now. > > Tom indicated that he would not pursue an approach in which a > multimedia > session is made up of one single context. The discussion > that followed > did not explore this option either. I would like to take the > opportunity to look into this, and compare this approach to the > proposals that have been posted earlier. > > Let me first state the main reason why I favor an approach in which > there is just one context for a multimedia, multi-party session: > simplicity of the model. In my opinion having multiple contexts for > mux/demux, audio, video, data adds too much detail to the connection > model. It starts to resemble the first MDCP draft where there were > separate entities in the model for echo canceling, bridging, > transcoding, etc. I think we can all agree that there was too much > detail there. It is much better to set properties of terminations (or > edge points as we used to call them in MDCP). > > So the connection model should be as abstract and flexible as > possible, > keeping in mind that the 95% use case is point to point voice. To me > this means that a model for a multimedia call does not need separate > entities in the model for mux/demux, the audio, video and data flows > that are sourced/sinked by the mux/demux. To me it also means that > there is no need to have the conference bridge split up over different > contexts. It seems better to have one context describing the bridging > functionality, and leave it to MG implementers to decide which > hardware/software units to use in the box. > > Now let me get to the ingredients of the model that I propose for > multimedia support. There are only ephemeral terminations. Every > termination has a list of bearer channels it uses. A termination > describes the (de)multiplexing rule used in case media are multiplexed > on the bearer(s). Examples are H.221 terminations, H.223 > terminations, > and terminations that use layered H.263 video encoding with > the multiple > layers going to/coming from different UDP ports. As Tom noted in his > message, this can be seen as a shorthand notation for the separate > context that indicates the (de)multiplexing. My point is > that we don't > need the context if we can do with the termination describing the > (de)multiplexing. And having only one context for the multimedia > session, > there is no need to repeat the list of bearers in multple contexts. > > > +----------+ --- +----------+ > | | audio / \ audio | audio on | > --| H.221 |--------| |--------| RTP |-- > | termina- | video | b f | | | > --| tion |--------| r u | +----------+ > | | data | i n | > | |--------| d c | +----------+ > +----------+ | g t | video | video on | > | e i |--------| RTP |-- > +----------+ | o | | | > | | audio | n | +----------+ > | H.223 |--------| | > --| termina- | video | | +----------+ > | tion |--------| | data | data on | > | | data | |--------| T.120 |-- > | |--------| | | | > +----------+ \ / +----------+ > --- > > The bridging functionality is described by means of properties of the > context. An identification of the streams that are linked to one user > would be helpful to be able to easily specify that all users should > receive the video stream of the last active speaker. > > The impact on protocol syntax is small. Manipulating a > session amounts > to adding/deleting/modifying terminations as before, no extra commands > are needed. There is a need to set the bridging properties, > so we need > a mechanism to set context properties. In the other > approaches there is > a need to do so as well. > > Another advantage of this approach is the use of ephemeral > terminatinos. > The MG can assign simple names to these (in the same way it assigns > names to contexts). Thus there is no need any more to have the long > hierarchical names included in all commands that reference > terminations. > (I see no good reason for having termination names containing any > information about the type of transport and/or media used in the > termination. This information is present in the termination > properties > already.) > > Final remark on this approach: I think that this is actually what Tom > alluded to as Paul Sijben's approach (I didn't check with Paul, I have > to admit). > > Now for a couple of comments on the earlier mails. It seems overly > complex to me to have multiple ephemeral instances of mux > contexts/terminations around as Brian Rosen suggests. The approach I > outlined above only has one ephemeral termination for the media > multiplexed for transport, which looks much simpler. It is > as flexible > as the idea Brian presented and does not need the semantics that all > ephemeral instances of a mux are created when the first one is, nor do > you need multiple actions because you don't have to deal with multiple > contexts. > > Fernando Cuervo suggested having terminations imply the > (de)multiplexing > requires that it is possible to describe in every termination > which bits > from which packet/frame are to be sent out because a media > stream may be > split up over multiple. So I feel it would be much better to have the > mux explicit. An advantage of having the (de)multiplixing in one > termination/context is that it is immediately clear which bearers are > used for the aggregated stream. What I like about Fernando's proposal > is the fact that there is a context type. What may even be better (I > haven't thought it through, though) is to have a limited number of > context profiles: one for voice-only with all streams going > to everyone > but the sender, video+audio with audio to everyone but the sender, > speaker's video to everyone, etc. > > Kindest regards, > > John Segers > -- > John Segers email: jsegers(a)lucent.com > Lucent Technologies Room HE 344 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 >

2 1

Multimedia contexts for H.320 and H.324 support in megaco/H.gcp
by John Segers 28 Apr '99

28 Apr '99

Over the past couple of days there has been some interesting discussion on the mailing list with respect to multimedia support in H.gcp/MEGACO, starting with Tom Taylor's note. Unfortunately I have been off-line and have not been able to respond until now. Tom indicated that he would not pursue an approach in which a multimedia session is made up of one single context. The discussion that followed did not explore this option either. I would like to take the opportunity to look into this, and compare this approach to the proposals that have been posted earlier. Let me first state the main reason why I favor an approach in which there is just one context for a multimedia, multi-party session: simplicity of the model. In my opinion having multiple contexts for mux/demux, audio, video, data adds too much detail to the connection model. It starts to resemble the first MDCP draft where there were separate entities in the model for echo canceling, bridging, transcoding, etc. I think we can all agree that there was too much detail there. It is much better to set properties of terminations (or edge points as we used to call them in MDCP). So the connection model should be as abstract and flexible as possible, keeping in mind that the 95% use case is point to point voice. To me this means that a model for a multimedia call does not need separate entities in the model for mux/demux, the audio, video and data flows that are sourced/sinked by the mux/demux. To me it also means that there is no need to have the conference bridge split up over different contexts. It seems better to have one context describing the bridging functionality, and leave it to MG implementers to decide which hardware/software units to use in the box. Now let me get to the ingredients of the model that I propose for multimedia support. There are only ephemeral terminations. Every termination has a list of bearer channels it uses. A termination describes the (de)multiplexing rule used in case media are multiplexed on the bearer(s). Examples are H.221 terminations, H.223 terminations, and terminations that use layered H.263 video encoding with the multiple layers going to/coming from different UDP ports. As Tom noted in his message, this can be seen as a shorthand notation for the separate context that indicates the (de)multiplexing. My point is that we don't need the context if we can do with the termination describing the (de)multiplexing. And having only one context for the multimedia session, there is no need to repeat the list of bearers in multple contexts. +----------+ --- +----------+ | | audio / \ audio | audio on | --| H.221 |--------| |--------| RTP |-- | termina- | video | b f | | | --| tion |--------| r u | +----------+ | | data | i n | | |--------| d c | +----------+ +----------+ | g t | video | video on | | e i |--------| RTP |-- +----------+ | o | | | | | audio | n | +----------+ | H.223 |--------| | --| termina- | video | | +----------+ | tion |--------| | data | data on | | | data | |--------| T.120 |-- | |--------| | | | +----------+ \ / +----------+ --- The bridging functionality is described by means of properties of the context. An identification of the streams that are linked to one user would be helpful to be able to easily specify that all users should receive the video stream of the last active speaker. The impact on protocol syntax is small. Manipulating a session amounts to adding/deleting/modifying terminations as before, no extra commands are needed. There is a need to set the bridging properties, so we need a mechanism to set context properties. In the other approaches there is a need to do so as well. Another advantage of this approach is the use of ephemeral terminatinos. The MG can assign simple names to these (in the same way it assigns names to contexts). Thus there is no need any more to have the long hierarchical names included in all commands that reference terminations. (I see no good reason for having termination names containing any information about the type of transport and/or media used in the termination. This information is present in the termination properties already.) Final remark on this approach: I think that this is actually what Tom alluded to as Paul Sijben's approach (I didn't check with Paul, I have to admit). Now for a couple of comments on the earlier mails. It seems overly complex to me to have multiple ephemeral instances of mux contexts/terminations around as Brian Rosen suggests. The approach I outlined above only has one ephemeral termination for the media multiplexed for transport, which looks much simpler. It is as flexible as the idea Brian presented and does not need the semantics that all ephemeral instances of a mux are created when the first one is, nor do you need multiple actions because you don't have to deal with multiple contexts. Fernando Cuervo suggested having terminations imply the (de)multiplexing requires that it is possible to describe in every termination which bits from which packet/frame are to be sent out because a media stream may be split up over multiple. So I feel it would be much better to have the mux explicit. An advantage of having the (de)multiplixing in one termination/context is that it is immediately clear which bearers are used for the aggregated stream. What I like about Fernando's proposal is the fact that there is a context type. What may even be better (I haven't thought it through, though) is to have a limited number of context profiles: one for voice-only with all streams going to everyone but the sender, video+audio with audio to everyone but the sender, speaker's video to everyone, etc. Kindest regards, John Segers -- John Segers email: jsegers(a)lucent.com Lucent Technologies Room HE 344 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954

1 0

Re: Methods For Support of H.320/H.324
by Callaghan, Robert 28 Apr '99

28 Apr '99

Ami, I understand that the transport of any DS0 stream will require RTP transport. The question has to do with Interworking vs. Transport. When the destination is an H.323 terminal, the DS0 streams that are part of an H.320 call must be converted from H.320 to H.323 in the gateway. However, if the destination is another H.320 terminal and the packet network is only an intermediate transport link, then it is better to transport each DS0 stream from the H.320 terminal individually rather than to interwork H.320 to H.323 to H.320 in both gateways. I a carries is to use the packet network as transparent segments added to the existing network, then all services must be completely transparent to the end users. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information & Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Ami Amir [mailto:amir@RADVISION.RAD.CO.IL] Sent: Wednesday, April 28, 1999 4:42 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Methods For Support of H.320/H.324 Hi Tom and Bob, On the last question: There is no way that you can just tunnel DS0 channels that are part of an H.320 call between two gateways over IP and expect it to work. This statement is based on work we did in the pre-323 days, we built a proprietary solution that really works. Hence, the question is academic, and the DS0s always need to be converted to RTP stream (or call it H.GCP contexts?). Ami -----Original Message----- From: Tom-PT Taylor [SMTP:taylor@NORTELNETWORKS.COM] Sent: Tuesday, April 27, 1999 2:40 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Methods For Support of H.320/H.324 -----Original Message----- From: Callaghan, Robert [SMTP:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Monday, April 26, 1999 5:12 PM [[TomT]] snip > However, one major problem is only touched. You stated the multi-DS0s may > be established using multi-link procedure. To the network, these appear > as > individual calls. The network will route the call such that it reaches > the > specified endpoint. The network has no concept of routing multiple > independent calls by the same path. Since the gateway is only part of > network, by what means can it be determined that the interworking of H.320 > to H.323 will have all of the applicable DS0 connection at the same > gateway? > If they do not use the same gateway, how do the endpoints and gateways > handle the connection? [[TomT]] I agree that this is mysterious, but people must solve it now. Thoughts of ISDN and wideband service go through my mind. If it helps any, I'll point out that we're really talking about an MCU rather than a Gateway at this point. > Another problem was not discussed. If a H.320 connection arrives at the > gateway, how does the gateway know that H.320 to H.323 interworking is > required as opposed to the simple transport of the signal to another > egress > gateway? As a corollary, how does the gateway know that the signal is not > voice, and should be transported as 64Kbps clear? [[TomT]] That's where the V.140 negotiation comes in. > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Information & Communication Networks > Tel: +1.561.997.3756 Fax: +1.561.997.3403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ >

1 0

Re: Methods For Support of H.320/H.324
by Ami Amir 28 Apr '99

28 Apr '99

Hi Tom and Bob, On the last question: There is no way that you can just tunnel DS0 channels that are part of an H.320 call between two gateways over IP and expect it to work. This statement is based on work we did in the pre-323 days, we built a proprietary solution that really works. Hence, the question is academic, and the DS0s always need to be converted to RTP stream (or call it H.GCP contexts?). Ami -----Original Message----- From: Tom-PT Taylor [SMTP:taylor@NORTELNETWORKS.COM] Sent: Tuesday, April 27, 1999 2:40 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Methods For Support of H.320/H.324 -----Original Message----- From: Callaghan, Robert [SMTP:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Monday, April 26, 1999 5:12 PM [[TomT]] snip > However, one major problem is only touched. You stated the multi-DS0s may > be established using multi-link procedure. To the network, these appear > as > individual calls. The network will route the call such that it reaches > the > specified endpoint. The network has no concept of routing multiple > independent calls by the same path. Since the gateway is only part of > network, by what means can it be determined that the interworking of H.320 > to H.323 will have all of the applicable DS0 connection at the same > gateway? > If they do not use the same gateway, how do the endpoints and gateways > handle the connection? [[TomT]] I agree that this is mysterious, but people must solve it now. Thoughts of ISDN and wideband service go through my mind. If it helps any, I'll point out that we're really talking about an MCU rather than a Gateway at this point. > Another problem was not discussed. If a H.320 connection arrives at the > gateway, how does the gateway know that H.320 to H.323 interworking is > required as opposed to the simple transport of the signal to another > egress > gateway? As a corollary, how does the gateway know that the signal is not > voice, and should be transported as 64Kbps clear? [[TomT]] That's where the V.140 negotiation comes in. > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Information & Communication Networks > Tel: +1.561.997.3756 Fax: +1.561.997.3403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ >

1 0

Re: Delayed contribution - Proposed editorial correction on H.245 V5 white
by Yoshihiro Kikuchi 28 Apr '99

28 Apr '99

Dear all, I'm sorry, I forgot to attach the document. -----Original Message----- From: Yoshihiro Kikuchi <kiku(a)eel.rdc.toshiba.co.jp> To: itu-SG16(a)MAILBAG.INTEL.COM <itu-SG16(a)MAILBAG.INTEL.COM>; sg16.lbc(a)research.kpn.com <sg16.lbc(a)research.kpn.com> Cc: Yoshihiro Kikuchi <kiku(a)eel.rdc.toshiba.co.jp>; kawahara(a)mlab.nttdocomo.co.jp <kawahara(a)mlab.nttdocomo.co.jp>; Hidenobu Harasaki <harasaki(a)ccm.cl.nec.co.jp>; Mike Nilsson <mike.nilsson(a)bt-sys.bt.co.uk> Date: Wednesday, April 28, 1999 4:42 PM Subject: Delayed contribution - Proposed editorial correction on H.245 V5 white >Dear experts, > >Attached find please a delayed contribution to the SG16 Santiago >meeting: > >TITLE: Proposed editorial revisions on H.245 version 5 regarding MPEG-4 >visual codepoints and the generic capability >SOURCE: Toshiba, NEC, NTT DoCoMo > >We had some e-mail discussions on this issue with the H.245 editor and >relevant rapporteurs. This delayed contribution is a summary of the >discussion. > >Best regards, >Yoshihiro Kikuchi >---- > Yoshihiro Kikuchi > >E-mail: kiku(a)eel.rdc.toshiba.co.jp >Research and Development Center Toshiba Corp. >TEL: +81 +44 549 2288 FAX: +81 +44 520 1308 > > >

1 0

Delayed contribution - Proposed editorial correction on H.245 V5 white
by Yoshihiro Kikuchi 28 Apr '99

28 Apr '99

Dear experts, Attached find please a delayed contribution to the SG16 Santiago meeting: TITLE: Proposed editorial revisions on H.245 version 5 regarding MPEG-4 visual codepoints and the generic capability SOURCE: Toshiba, NEC, NTT DoCoMo We had some e-mail discussions on this issue with the H.245 editor and relevant rapporteurs. This delayed contribution is a summary of the discussion. Best regards, Yoshihiro Kikuchi ---- Yoshihiro Kikuchi E-mail: kiku(a)eel.rdc.toshiba.co.jp Research and Development Center Toshiba Corp. TEL: +81 +44 549 2288 FAX: +81 +44 520 1308

1 0

Re: Annex G and Roaming?
by Roy, Radhika R, ALCOO 27 Apr '99

27 Apr '99

Douglas: I agree with you. We also discussed this topic last year. It is also true that some kind of roaming can be supported the way H.323 (H.323, H.225.0, H.225.0 Annex G, H.245) standards are there. It depends what we actually mean by roaming. There should be some kind of common understandings or standards what kinds of roaming services are to be supported. For example, per call authorzation is one way of satisfying roaming requirements. Now we need to define the scope or requirements of roaming in a standard way. Accordingly, we have to see how much of these requirements we already can support in the existing standards, and what else we need to develop in standards. Radhika R. Roy AT&T > -----Original Message----- > From: Douglas Clowes [SMTP:dclowes@OZEMAIL.COM.AU] > Sent: Monday, April 26, 1999 7:01 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Annex G and Roaming? > > Espen, > > It all depends on what you mean by "roaming of users between different > domains". > > Annex G does support some functionality for some favours of roaming, but > requires further development - particularly in how to use these aspects > between domains. > > Comments below. > At 14:54 1999-04-23 +0200, Espen Skjæran wrote: > >Hi all, > > > >I've recently heard (unofficially) that some claim Annex G > >(APC-1546/TD-20 in Monterey) > >also to support roaming of users between different domains. > > > >If this is true, I wonder how. > > > >I can see how the AccessRequest/ValidationRequest might be sent from a > >visiting domain to the home domain for per-call authorization. While > >this might work in simple cases, it will hinder the use of services > >while roaming. > > Per call authorization permits a user from one domain to use gateway > equipment from a second domain, to make calls to through a gateway in a > third domain. There could even be a fourth domain present as a > clearinghouse. > > I don't know what you mean by "hinder the use of services while roaming" > in > this context. Perhaps you could elaborate please. > > >I can not either see any mechanism to authorize the roaming > >registration. > > Registration is a completely different issue, and I don't see support for > it in Annex G. Perhaps an RRQ with a remote e.164 or IP address could be > issued to the home domain, by the terminal or host gatekeeper? > > >I am sorry to post based on "rumors", but this may change the scope of > >Annex G significally, and I worry if this might affect future work on > >roaming. As Tiphon has just started their work on roaming by analysing > >existing roaming techniques in telco and datacom/IETF work,and not yet > >reached any conclusion, it seems premature to use annex G > >in its current state for roaming. > > These concepts will have to be developed in parallel. There is more than > one "type" or "roaming", and different people will think of different > things when that word is used. Some people think of terminal mobility, > while others think of mobile IP. Neither of these apply to the mobile user > on public ingress gateways depicted above, but they are no less valid and > need to be considered. > > When we know what the opportunities are, we will be better placed to seek > solutions. It is not enough to just say "roaming"! > > Douglas > > > >Espen > > > >

1 0

Re: Methods For Support of H.320/H.324
by Tom-PT Taylor 27 Apr '99

27 Apr '99

-----Original Message----- From: Callaghan, Robert [SMTP:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Monday, April 26, 1999 5:12 PM [[TomT]] snip > However, one major problem is only touched. You stated the multi-DS0s may > be established using multi-link procedure. To the network, these appear > as > individual calls. The network will route the call such that it reaches > the > specified endpoint. The network has no concept of routing multiple > independent calls by the same path. Since the gateway is only part of > network, by what means can it be determined that the interworking of H.320 > to H.323 will have all of the applicable DS0 connection at the same > gateway? > If they do not use the same gateway, how do the endpoints and gateways > handle the connection? [[TomT]] I agree that this is mysterious, but people must solve it now. Thoughts of ISDN and wideband service go through my mind. If it helps any, I'll point out that we're really talking about an MCU rather than a Gateway at this point. > Another problem was not discussed. If a H.320 connection arrives at the > gateway, how does the gateway know that H.320 to H.323 interworking is > required as opposed to the simple transport of the signal to another > egress > gateway? As a corollary, how does the gateway know that the signal is not > voice, and should be transported as 64Kbps clear? [[TomT]] That's where the V.140 negotiation comes in. > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Information & Communication Networks > Tel: +1.561.997.3756 Fax: +1.561.997.3403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ >

1 0

Delayed Contribution from Motorola and Cisco
by Sakae OKUBO 27 Apr '99

27 Apr '99

Dear Q.12-14/16 experts, The following Delayed Contribution for the SG16 meeting in Santiago has been placed at the PictureTel ftp site: SOURCE: Motorola and Cisco TITLE: Proposal for a New Annex in (H.246) ftp://standard.pictel.com/avc-site/9905_San/034_DC.zip or http://standard.pictel.com/ftp/avc-site/9905_San/034_DC.zip Mr. Edgar Martinez, should I delete Tun&H.246.doc at the /Incoming directory? Using this opportunity, I would encourage other contributors to upload their contributions to the PictureTel ftp site for review of other members. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

H.225v3 facilityReason
by henri.maenpaa＠NOKIA.COM 27 Apr '99

27 Apr '99

All, I was reading the latest H.225v3 draft and saw the new facilityReason "noH245" in the ASN.1. I'm just wondering is this reason supposed to be used in a situation where the other end wants to keep the H245 tunneling on and informs the other end about this? -Henri Mäenpää

1 0

Annex G and Roaming?
by Espen Skjæran 26 Apr '99

26 Apr '99

Hi all, I've recently heard (unofficially) that some claim Annex G (APC-1546/TD-20 in Monterey) also to support roaming of users between different domains. If this is true, I wonder how. I can see how the AccessRequest/ValidationRequest might be sent from a visiting domain to the home domain for per-call authorization. While this might work in simple cases, it will hinder the use of services while roaming. I can not either see any mechanism to authorize the roaming registration. I am sorry to post based on "rumors", but this may change the scope of Annex G significally, and I worry if this might affect future work on roaming. As Tiphon has just started their work on roaming by analysing existing roaming techniques in telco and datacom/IETF work,and not yet reached any conclusion, it seems premature to use annex G in its current state for roaming. Espen

2 1

Re: Methods For Support of H.320/H.324
by Callaghan, Robert 26 Apr '99

26 Apr '99

Tom, The problem is well stated. However, one major problem is only touched. You stated the multi-DS0s may be established using multi-link procedure. To the network, these appear as individual calls. The network will route the call such that it reaches the specified endpoint. The network has no concept of routing multiple independent calls by the same path. Since the gateway is only part of network, by what means can it be determined that the interworking of H.320 to H.323 will have all of the applicable DS0 connection at the same gateway? If they do not use the same gateway, how do the endpoints and gateways handle the connection? Another problem was not discussed. If a H.320 connection arrives at the gateway, how does the gateway know that H.320 to H.323 interworking is required as opposed to the simple transport of the signal to another egress gateway? As a corollary, how does the gateway know that the signal is not voice, and should be transported as 64Kbps clear? Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information & Communication Networks Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Monday, April 26, 1999 4:10 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Methods For Support of H.320/H.324 This note fulfils an action item I had out of the last H.GCP conference call. It presents alternative ways to support H.320/H.324 within a multimedia conference. Statement Of The Problem ==================== The basic connection model issue when dealing with H.320 and H.324 is how to indicate the fact that multiple DS-0 channels are being spanned by a single user's data. A secondary issue is to indicate exactly how these channels are framed to carry the different streams of media and control signals, but that can be done simply by specifying the multiplexer (e.g. H.221) which is being used. There are a number of potential complications here. First off, the conferencing mode (H.320, H.323, H.324) is generally not known in advance, and must be determined through negotiation. (ITU-T Rec. V.140 describes the various levels of negotiation involved.) This probably implies a requirement for an event reporting package, so the MGC can be aware of the service being provided. Another complication is that the complete set of DS-0 channels may all be signalled at once as a wideband service, or they be added one at a time through a multilink procedure. This is not a protocol issue so long as the flexibility to add Terminations individually is maintained. Any implementation should bear in mind that the ordering of the DS-0 channels is significant. That constrains the order of addition of Terminations to a Context, but does not actually constrain the representation of the connection. The Alternatives On The Table ====================== Three basic methods have been proposed for representing the multiplexed n x DS-0 service: * use a separate Context to represent the relationship between the H.320/H.324 session and the n DS-0s which carry it * allow the n DS-0s to appear directly within the Context(s) to which they contribute, using an UserID parameter to indicate their relationship * define a Termination Class where the Terminations are always ephemeral, with the ability to list multiple supporting circuit bearers as part of the instance descriptor. Preliminary Assumptions ================== A number of open issues were identified during the preparation of this discussion, which are not directly related to the immediate question but need resolution before we have a complete protocol specification. To simplify the discussion, specific assumptions have been made, as follows: Issue: how to specify the Termination Class of a Termination. This issue arises especially for new ephemeral Terminations which, for instance, might be RTP-based or some flavour of ATM-based. As an additional "would be nice" consideration, it should be easy for the MGC to recognize the Termination Class of ANY Termination. The assumption made in this discussion is that Termination Class is indicated by the root component of the TerminationID. Thus a request for a new RTP termination may be represented as "RTP/?", where "?" denotes the "choose one" wildcard. Issue: constraints on the lowest-order component of a TerminationID where this component is assigned by the MG. There are really two issues here: whether the low-order part of the TerminationID has any meaning, and what conditions are required to assure naming uniqueness. Here are some examples to illustrate the potential problems: * Case 1: we decide that a single-channel DS-0 bearing an H.320 session can appear directly in the audio and video contexts to which it contributes. If the name of the DS-0 is "DS-0/15/6" (e.g. channel 6 on transmission facility 15, but this is a matter of local convention), then what do we call the representative of this circuit which appears in the audio context? One possibility is "DS-0/15/6/audio", another is "DS-0/15/6/C7" where "C7" is the context name, a third is "DS-0/15/6/1" where "1" is an arbitrary value assigned by the MG which ensures that the resulting name is unique. The first form, with the "audio" tag, can probably be discarded because it makes the unnecessary assumption that the same physical termination cannot appear in more than one context carrying the same medium. The second form falsely assumes that the Termination will never be moved to another context. This leaves only the third possibility. * Case 2: the same user has two RTP streams, one for video, one for audio. Should there be any relationship between the names of the TerminationIDs representing flows to and from that user? The assumption made in this discussion is that when the MG assigns the low-order component of the TerminationID, it assigns an arbitrary value which is chosen to guarantee uniqueness of the resulting TerminationID. Issue: single- versus multimedia contexts. This discussion assumes single-medium contexts, just to keep its size reasonable. The alternative is very relevant to the issue at hand, but should be explored in a separate note. Issue: how does the MGC determine whether the MG should be looking for an H.320/H.324 conference on a DS-0 channel in the first place? We have to think about this one, but it seems likely to me that the answer comes either from the context of the call (e.g. all calls to an MCU-MG are H.32x conferences) or from signalling (e.g. in the bearer capability element). In this discussion I assume that the MGC knows by some means and can tell the MG to look for the appropriate event. Exploration Of The Alternatives ======================= 1. Separate Context To Represent Multiplexing -------------------------------------------------------------------- This proposal represents an H.320/H.324 session as an ephemeral Termination. The Termination appears in a Context with the DS-0 Terminations which support it. It is then used in place of a physical Termination within other contexts representing the actual multimedia conference. The proposal is illustrated below, where MUX/1 is an ephemeral multiplexed Termination supported by two DS-0s, and C2 and C3 represent the audio and video planes of a conference with two other participants. Context C1 (Multiplex) Context C2 (Audio) |---------------------| |----------------------| | | | | | MUX/1 | | MUX/1/1 | | | | | | | | DS0/1 ---O--- DS0/2 | | | | | | | O | |---------------------| | / \ | | / \ | | RTP/1 RTP/2 | Context C3 (Video) | | |----------------------| |----------------------| | | | MUX/1/2 | | | | | | | | O | | / \ | | / \ | | RTP/3 RTP/4 | | | |----------------------| Before looking at the syntax this representation implies, let us examine the nature of Context C1. It has one topological peculiarity: there is no intention of any data interchange between the two DS-0 Terminations. One cannot model this as a property of the respective DS-0s, since in another call they could be playing a different role. Thus it has to be a property of the Context as a whole. It seems reasonable to make this a generic multiplexing capability rather than a conferencing-system-specific property, and associate the details of the multiplex (H.221, H.223, ...) with the termination class. In our discussions, we have determined that a Context may have media type, mixing type, and possibly linkage attributes. We need some sort of "transparent data" media type to denote the role of Context C1, along the "multiplex" mixing type. It is clear in the present case that any linkage will be at the Termination rather than the Context level. Having said that, let us consider the syntax required to set up the conference. First the multiplexing Context and Terminations are defined: MGC->MG: TransactionRequest (TransactionID=1); ContextID=? (Medium=transparent data, Mixing=multiplex); Add( MUX/?, ... ); Add( DS0/1 ..., EventDescriptor=(EventID=1, Observe and report conference mode ))); Add( DS0/2, ... -- Sets up the MG to negotiate the conference mode on the first DS-0 and report the outcome to the MGC. The second DS-0 is also placed into the context with the assumption that the MG can figure out the framing from the control signals coming in on DS0/1. At some point someone is going to have to work out what other parameters should be represented here. MG->MGC: TransactionAccept (TransactionID=1); ContextID=C1; Add accepted (TerminationID=MUX/1); Add accepted; Add accepted MG->MGC: TransactionRequest (TransactionID=2); Notify( TerminationID=DS0/1, EventID=1, ConferenceMode=H.324) -- the MG has negotiated an H.324 conference. It could also report details such as whether the DS-0 channels are supporting 56kbs or 64kbs transfer rates. MGC->MG: TransactionAccept (TransactionID=2); Notify accepted; TransactionRequest (TransactionID=3); ContextID=C1; Modify( MUX/1( Transport=H.223)) -- The MGC indicates that H.223 is the particular multiplex in use. MG->MGC: TransactionAccept (TransactionID=3); ContextID=C1; Modify accepted Now, assuming that the necessary H.245 signalling is carried out to make this happen, the audio and video contexts are set up and the participants are added. MGC->MG: TransactionRequest (TransactionID=4); ContextID=? (Medium=audio); Add( MUX/1/? ...); Add( RTP/? ...); Add( RTP/? ...); -- The MGC asks for the RTP terminations and specifies their parameters in accordance with its outgoing H.245 OLC requests. Notice the suggested syntax for requesting a representative of MUX/1 within this context. MG->MGC: TransactionAccept (TransactionID=4); ContextID=C2; Add accepted (TerminationID=MUX/1/1, ...); Add accepted (TerminationID=RTP/1, ...); Add accepted (TerminationID=RTP/2, ...) MGC->MG: TransactionRequest (TransactionID=5); ContextID=? (Medium=video, Mixing=...); Add( MUX/1/? SynchWith=MUX/1/1, ...); Add( RTP/? SynchWith=RTP/1, ...); Add( RTP/? SynchWith=RTP/2, ...); -- The video has to be synchronized with the audio. Assumed here that specification of the corresponding audio TerminationID is sufficient because of uniqueness of naming. MG->MGC: TransactionAccept (TransactionID=5); ContextID=C3; Add accepted (TerminationID=MUX/1/2, ...); Add accepted (TerminationID=RTP/3, ...); Add accepted (TerminationID=RTP/4, ...) 2. Direct Representation Of Contributing DS-0s In Audio and Video Contexts ---------------------------------------------------------------------------- ---------------------------------- Paul Sijbens suggested that we use this approach along with multimedia contexts. It can also be used with single-media contexts, as illustrated here. There are two key issues to resolve: * How to indicate that the DS-0s are carrying H.320 or H.324 data. One possible answer is to indicate in the LocalDescriptor that the transport type is H.221 or H.223 respectively. * How to indicate that the terminations all represent the same H.320/H.324 session. The answer suggested by Paul Sijben is to introduce a linkage parameter, which he suggested calling the UserID. As we shall see, this intra-context linkage is additional to the cross-context linkage required for lip synchronization. The behavioural implication is that Terminations with the same UserID do not send data to each other. The contexts set up are illustrated below, using the same basic information as in the previous case. Context C1 (Audio) Context C2 (Video) |----------------------| |----------------------| | | | | | DS0/1/1 DSO/2/1 | | DS0/1/2 DSO/2/2 | | \ / | | \ / | | \ / | | \ / | | O | | O | | / \ | | / \ | | / \ | | / \ | | RTP/1 RTP/2 | | RTP/3 RTP/4 | | | | | |----------------------| |----------------------| The syntax required to set up the connections according to this procedure looks something like this: MGC->MG: TransactionRequest (TransactionID=1); ContextID=? (Medium=audio); Add( DS0/1/?, UserID=5764, ..., EventDescriptor=(EventID=1, Observe and report conference mode ))); Add( DS0/2/?, UserID=5764, ... Add( RTP/? ...); Add( RTP/? ...); MG->MGC: TransactionAccept (TransactionID=1); ContextID=C1; Add accepted (TerminationID=DS0/1/1, ...); Add accepted (TerminationID=DS0/2/1, ...); Add accepted (TerminationID=RTP/1, ...); Add accepted (TerminationID=RTP/2, ...) MG->MGC: TransactionRequest (TransactionID=2); Notify( TerminationID=DS0/1/1, EventID=1, ConferenceMode=H.324) -- the MG has negotiated an H.324 conference. MGC->MG: TransactionAccept (TransactionID=2); Notify accepted; TransactionRequest (TransactionID=3); ContextID=C1; Modify( DS0/1/1( Transport=H.223)) Modify( DS0/2/1( Transport=H.223)) -- The MGC indicates that H.223 is the particular multiplex in use. MG->MGC: TransactionAccept (TransactionID=3); ContextID=C1; Modify accepted Modify accepted MGC->MG: TransactionRequest (TransactionID=4); ContextID=? (Medium=video, Mixing=...); Add( DS0/1/?, UserID=5764, (SynchWith=DS0/1/1, DS0/2/1), ...Transport=H.223, ...); Add( DS0/2/?, UserID=5764, SynchWith=(UserID=5764 in Context C1), ...Transport=H.223, ...); Add( RTP/?, SynchWith=RTP/1, ...); Add( RTP/?, SynchWith=RTP/2, ...); -- The video has to be synchronized with the audio. A question here: whether we should show a list of SynchWith terminations as shown in the first Add, or whether it would be sufficient to name the UserID and context as in the second Add. Both methods are shown for the reader to think about. MG->MGC: TransactionAccept (TransactionID=4); ContextID=C2; Add accepted (TerminationID=DS0/1/2, ...); Add accepted (TerminationID=DS0/2/2, ...); Add accepted (TerminationID=RTP/3, ...); Add accepted (TerminationID=RTP/4, ...) 3. Allow Lists Of Supporting Bearers For Terminations ---------------------------------------------------------------------------- --- This alternative has much of the logical structure of the first one. The bearer list is a shorthand notation for the separate context set up to indicate the multiplexing relationship. The Termination Class itself is a multiplexing class, with the type of multiplex indicated by the transport parameter. In general, we get a more compact version of the first alternative, with one drawback: the list of bearers has to be repeated (for regularity) for each context in which the multiplexing Termination participates. The contexts set up under this alternative are as follows: Context C1 (Audio) Context C2 (Video) |----------------------| |----------------------| | | | | | MUX/1 | | MUX/2 | | | | | | | | | | | | | | O | | O | | / \ | | / \ | | / \ | | / \ | | RTP/1 RTP/2 | | RTP/3 RTP/4 | | | | | |----------------------| |----------------------| The syntax for setting these up is as follows: MGC->MG: TransactionRequest (TransactionID=1); ContextID=? (Medium=audio); Add( MUX/?, Bearers=(DS0/1, DS0/2), ..., EventDescriptor=(EventID=1, Observe and report conference mode ))); Add( RTP/? ...); Add( RTP/? ...); MG->MGC: TransactionAccept (TransactionID=1); ContextID=C1; Add accepted (TerminationID=MUX/1, ...); Add accepted (TerminationID=RTP/1, ...); Add accepted (TerminationID=RTP/2, ...) MG->MGC: TransactionRequest (TransactionID=2); Notify( TerminationID=MUX/1, EventID=1, ConferenceMode=H.324) -- the MG has negotiated an H.324 conference. MGC->MG: TransactionAccept (TransactionID=2); Notify accepted; TransactionRequest (TransactionID=3); ContextID=C1; Modify( MUX/1( Transport=H.223)) -- The MGC indicates that H.223 is the particular multiplex in use. MG->MGC: TransactionAccept (TransactionID=3); ContextID=C1; Modify accepted MGC->MG: TransactionRequest (TransactionID=4); ContextID=? (Medium=video, Mixing=...); Add( MUX/?, SynchWith=MUX/1, ... Bearers=(DS0/1, DS0/2), Transport=H.223, ...); Add( RTP/?, SynchWith=RTP/1, ...); Add( RTP/?, SynchWith=RTP/2, ...); -- It seems most natural to create a separate MUX class Termination for each context. MG->MGC: TransactionAccept (TransactionID=4); ContextID=C2; Add accepted (TerminationID=MUX/2, ...); Add accepted (TerminationID=RTP/3, ...); Add accepted (TerminationID=RTP/4, ...) Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 736 0961 (ESN 396-1490) FAX: same number by prior arrangement (manual answer).

1 0

Methods For Support of H.320/H.324
by Tom-PT Taylor 26 Apr '99

26 Apr '99

This note fulfils an action item I had out of the last H.GCP conference call. It presents alternative ways to support H.320/H.324 within a multimedia conference. Statement Of The Problem ==================== The basic connection model issue when dealing with H.320 and H.324 is how to indicate the fact that multiple DS-0 channels are being spanned by a single user's data. A secondary issue is to indicate exactly how these channels are framed to carry the different streams of media and control signals, but that can be done simply by specifying the multiplexer (e.g. H.221) which is being used. There are a number of potential complications here. First off, the conferencing mode (H.320, H.323, H.324) is generally not known in advance, and must be determined through negotiation. (ITU-T Rec. V.140 describes the various levels of negotiation involved.) This probably implies a requirement for an event reporting package, so the MGC can be aware of the service being provided. Another complication is that the complete set of DS-0 channels may all be signalled at once as a wideband service, or they be added one at a time through a multilink procedure. This is not a protocol issue so long as the flexibility to add Terminations individually is maintained. Any implementation should bear in mind that the ordering of the DS-0 channels is significant. That constrains the order of addition of Terminations to a Context, but does not actually constrain the representation of the connection. The Alternatives On The Table ====================== Three basic methods have been proposed for representing the multiplexed n x DS-0 service: * use a separate Context to represent the relationship between the H.320/H.324 session and the n DS-0s which carry it * allow the n DS-0s to appear directly within the Context(s) to which they contribute, using an UserID parameter to indicate their relationship * define a Termination Class where the Terminations are always ephemeral, with the ability to list multiple supporting circuit bearers as part of the instance descriptor. Preliminary Assumptions ================== A number of open issues were identified during the preparation of this discussion, which are not directly related to the immediate question but need resolution before we have a complete protocol specification. To simplify the discussion, specific assumptions have been made, as follows: Issue: how to specify the Termination Class of a Termination. This issue arises especially for new ephemeral Terminations which, for instance, might be RTP-based or some flavour of ATM-based. As an additional "would be nice" consideration, it should be easy for the MGC to recognize the Termination Class of ANY Termination. The assumption made in this discussion is that Termination Class is indicated by the root component of the TerminationID. Thus a request for a new RTP termination may be represented as "RTP/?", where "?" denotes the "choose one" wildcard. Issue: constraints on the lowest-order component of a TerminationID where this component is assigned by the MG. There are really two issues here: whether the low-order part of the TerminationID has any meaning, and what conditions are required to assure naming uniqueness. Here are some examples to illustrate the potential problems: * Case 1: we decide that a single-channel DS-0 bearing an H.320 session can appear directly in the audio and video contexts to which it contributes. If the name of the DS-0 is "DS-0/15/6" (e.g. channel 6 on transmission facility 15, but this is a matter of local convention), then what do we call the representative of this circuit which appears in the audio context? One possibility is "DS-0/15/6/audio", another is "DS-0/15/6/C7" where "C7" is the context name, a third is "DS-0/15/6/1" where "1" is an arbitrary value assigned by the MG which ensures that the resulting name is unique. The first form, with the "audio" tag, can probably be discarded because it makes the unnecessary assumption that the same physical termination cannot appear in more than one context carrying the same medium. The second form falsely assumes that the Termination will never be moved to another context. This leaves only the third possibility. * Case 2: the same user has two RTP streams, one for video, one for audio. Should there be any relationship between the names of the TerminationIDs representing flows to and from that user? The assumption made in this discussion is that when the MG assigns the low-order component of the TerminationID, it assigns an arbitrary value which is chosen to guarantee uniqueness of the resulting TerminationID. Issue: single- versus multimedia contexts. This discussion assumes single-medium contexts, just to keep its size reasonable. The alternative is very relevant to the issue at hand, but should be explored in a separate note. Issue: how does the MGC determine whether the MG should be looking for an H.320/H.324 conference on a DS-0 channel in the first place? We have to think about this one, but it seems likely to me that the answer comes either from the context of the call (e.g. all calls to an MCU-MG are H.32x conferences) or from signalling (e.g. in the bearer capability element). In this discussion I assume that the MGC knows by some means and can tell the MG to look for the appropriate event. Exploration Of The Alternatives ======================= 1. Separate Context To Represent Multiplexing -------------------------------------------------------------------- This proposal represents an H.320/H.324 session as an ephemeral Termination. The Termination appears in a Context with the DS-0 Terminations which support it. It is then used in place of a physical Termination within other contexts representing the actual multimedia conference. The proposal is illustrated below, where MUX/1 is an ephemeral multiplexed Termination supported by two DS-0s, and C2 and C3 represent the audio and video planes of a conference with two other participants. Context C1 (Multiplex) Context C2 (Audio) |---------------------| |----------------------| | | | | | MUX/1 | | MUX/1/1 | | | | | | | | DS0/1 ---O--- DS0/2 | | | | | | | O | |---------------------| | / \ | | / \ | | RTP/1 RTP/2 | Context C3 (Video) | | |----------------------| |----------------------| | | | MUX/1/2 | | | | | | | | O | | / \ | | / \ | | RTP/3 RTP/4 | | | |----------------------| Before looking at the syntax this representation implies, let us examine the nature of Context C1. It has one topological peculiarity: there is no intention of any data interchange between the two DS-0 Terminations. One cannot model this as a property of the respective DS-0s, since in another call they could be playing a different role. Thus it has to be a property of the Context as a whole. It seems reasonable to make this a generic multiplexing capability rather than a conferencing-system-specific property, and associate the details of the multiplex (H.221, H.223, ...) with the termination class. In our discussions, we have determined that a Context may have media type, mixing type, and possibly linkage attributes. We need some sort of "transparent data" media type to denote the role of Context C1, along the "multiplex" mixing type. It is clear in the present case that any linkage will be at the Termination rather than the Context level. Having said that, let us consider the syntax required to set up the conference. First the multiplexing Context and Terminations are defined: MGC->MG: TransactionRequest (TransactionID=1); ContextID=? (Medium=transparent data, Mixing=multiplex); Add( MUX/?, ... ); Add( DS0/1 ..., EventDescriptor=(EventID=1, Observe and report conference mode ))); Add( DS0/2, ... -- Sets up the MG to negotiate the conference mode on the first DS-0 and report the outcome to the MGC. The second DS-0 is also placed into the context with the assumption that the MG can figure out the framing from the control signals coming in on DS0/1. At some point someone is going to have to work out what other parameters should be represented here. MG->MGC: TransactionAccept (TransactionID=1); ContextID=C1; Add accepted (TerminationID=MUX/1); Add accepted; Add accepted MG->MGC: TransactionRequest (TransactionID=2); Notify( TerminationID=DS0/1, EventID=1, ConferenceMode=H.324) -- the MG has negotiated an H.324 conference. It could also report details such as whether the DS-0 channels are supporting 56kbs or 64kbs transfer rates. MGC->MG: TransactionAccept (TransactionID=2); Notify accepted; TransactionRequest (TransactionID=3); ContextID=C1; Modify( MUX/1( Transport=H.223)) -- The MGC indicates that H.223 is the particular multiplex in use. MG->MGC: TransactionAccept (TransactionID=3); ContextID=C1; Modify accepted Now, assuming that the necessary H.245 signalling is carried out to make this happen, the audio and video contexts are set up and the participants are added. MGC->MG: TransactionRequest (TransactionID=4); ContextID=? (Medium=audio); Add( MUX/1/? ...); Add( RTP/? ...); Add( RTP/? ...); -- The MGC asks for the RTP terminations and specifies their parameters in accordance with its outgoing H.245 OLC requests. Notice the suggested syntax for requesting a representative of MUX/1 within this context. MG->MGC: TransactionAccept (TransactionID=4); ContextID=C2; Add accepted (TerminationID=MUX/1/1, ...); Add accepted (TerminationID=RTP/1, ...); Add accepted (TerminationID=RTP/2, ...) MGC->MG: TransactionRequest (TransactionID=5); ContextID=? (Medium=video, Mixing=...); Add( MUX/1/? SynchWith=MUX/1/1, ...); Add( RTP/? SynchWith=RTP/1, ...); Add( RTP/? SynchWith=RTP/2, ...); -- The video has to be synchronized with the audio. Assumed here that specification of the corresponding audio TerminationID is sufficient because of uniqueness of naming. MG->MGC: TransactionAccept (TransactionID=5); ContextID=C3; Add accepted (TerminationID=MUX/1/2, ...); Add accepted (TerminationID=RTP/3, ...); Add accepted (TerminationID=RTP/4, ...) 2. Direct Representation Of Contributing DS-0s In Audio and Video Contexts ---------------------------------------------------------------------------- ---------------------------------- Paul Sijbens suggested that we use this approach along with multimedia contexts. It can also be used with single-media contexts, as illustrated here. There are two key issues to resolve: * How to indicate that the DS-0s are carrying H.320 or H.324 data. One possible answer is to indicate in the LocalDescriptor that the transport type is H.221 or H.223 respectively. * How to indicate that the terminations all represent the same H.320/H.324 session. The answer suggested by Paul Sijben is to introduce a linkage parameter, which he suggested calling the UserID. As we shall see, this intra-context linkage is additional to the cross-context linkage required for lip synchronization. The behavioural implication is that Terminations with the same UserID do not send data to each other. The contexts set up are illustrated below, using the same basic information as in the previous case. Context C1 (Audio) Context C2 (Video) |----------------------| |----------------------| | | | | | DS0/1/1 DSO/2/1 | | DS0/1/2 DSO/2/2 | | \ / | | \ / | | \ / | | \ / | | O | | O | | / \ | | / \ | | / \ | | / \ | | RTP/1 RTP/2 | | RTP/3 RTP/4 | | | | | |----------------------| |----------------------| The syntax required to set up the connections according to this procedure looks something like this: MGC->MG: TransactionRequest (TransactionID=1); ContextID=? (Medium=audio); Add( DS0/1/?, UserID=5764, ..., EventDescriptor=(EventID=1, Observe and report conference mode ))); Add( DS0/2/?, UserID=5764, ... Add( RTP/? ...); Add( RTP/? ...); MG->MGC: TransactionAccept (TransactionID=1); ContextID=C1; Add accepted (TerminationID=DS0/1/1, ...); Add accepted (TerminationID=DS0/2/1, ...); Add accepted (TerminationID=RTP/1, ...); Add accepted (TerminationID=RTP/2, ...) MG->MGC: TransactionRequest (TransactionID=2); Notify( TerminationID=DS0/1/1, EventID=1, ConferenceMode=H.324) -- the MG has negotiated an H.324 conference. MGC->MG: TransactionAccept (TransactionID=2); Notify accepted; TransactionRequest (TransactionID=3); ContextID=C1; Modify( DS0/1/1( Transport=H.223)) Modify( DS0/2/1( Transport=H.223)) -- The MGC indicates that H.223 is the particular multiplex in use. MG->MGC: TransactionAccept (TransactionID=3); ContextID=C1; Modify accepted Modify accepted MGC->MG: TransactionRequest (TransactionID=4); ContextID=? (Medium=video, Mixing=...); Add( DS0/1/?, UserID=5764, (SynchWith=DS0/1/1, DS0/2/1), ...Transport=H.223, ...); Add( DS0/2/?, UserID=5764, SynchWith=(UserID=5764 in Context C1), ...Transport=H.223, ...); Add( RTP/?, SynchWith=RTP/1, ...); Add( RTP/?, SynchWith=RTP/2, ...); -- The video has to be synchronized with the audio. A question here: whether we should show a list of SynchWith terminations as shown in the first Add, or whether it would be sufficient to name the UserID and context as in the second Add. Both methods are shown for the reader to think about. MG->MGC: TransactionAccept (TransactionID=4); ContextID=C2; Add accepted (TerminationID=DS0/1/2, ...); Add accepted (TerminationID=DS0/2/2, ...); Add accepted (TerminationID=RTP/3, ...); Add accepted (TerminationID=RTP/4, ...) 3. Allow Lists Of Supporting Bearers For Terminations ---------------------------------------------------------------------------- --- This alternative has much of the logical structure of the first one. The bearer list is a shorthand notation for the separate context set up to indicate the multiplexing relationship. The Termination Class itself is a multiplexing class, with the type of multiplex indicated by the transport parameter. In general, we get a more compact version of the first alternative, with one drawback: the list of bearers has to be repeated (for regularity) for each context in which the multiplexing Termination participates. The contexts set up under this alternative are as follows: Context C1 (Audio) Context C2 (Video) |----------------------| |----------------------| | | | | | MUX/1 | | MUX/2 | | | | | | | | | | | | | | O | | O | | / \ | | / \ | | / \ | | / \ | | RTP/1 RTP/2 | | RTP/3 RTP/4 | | | | | |----------------------| |----------------------| The syntax for setting these up is as follows: MGC->MG: TransactionRequest (TransactionID=1); ContextID=? (Medium=audio); Add( MUX/?, Bearers=(DS0/1, DS0/2), ..., EventDescriptor=(EventID=1, Observe and report conference mode ))); Add( RTP/? ...); Add( RTP/? ...); MG->MGC: TransactionAccept (TransactionID=1); ContextID=C1; Add accepted (TerminationID=MUX/1, ...); Add accepted (TerminationID=RTP/1, ...); Add accepted (TerminationID=RTP/2, ...) MG->MGC: TransactionRequest (TransactionID=2); Notify( TerminationID=MUX/1, EventID=1, ConferenceMode=H.324) -- the MG has negotiated an H.324 conference. MGC->MG: TransactionAccept (TransactionID=2); Notify accepted; TransactionRequest (TransactionID=3); ContextID=C1; Modify( MUX/1( Transport=H.223)) -- The MGC indicates that H.223 is the particular multiplex in use. MG->MGC: TransactionAccept (TransactionID=3); ContextID=C1; Modify accepted MGC->MG: TransactionRequest (TransactionID=4); ContextID=? (Medium=video, Mixing=...); Add( MUX/?, SynchWith=MUX/1, ... Bearers=(DS0/1, DS0/2), Transport=H.223, ...); Add( RTP/?, SynchWith=RTP/1, ...); Add( RTP/?, SynchWith=RTP/2, ...); -- It seems most natural to create a separate MUX class Termination for each context. MG->MGC: TransactionAccept (TransactionID=4); ContextID=C2; Add accepted (TerminationID=MUX/2, ...); Add accepted (TerminationID=RTP/3, ...); Add accepted (TerminationID=RTP/4, ...) Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 736 0961 (ESN 396-1490) FAX: same number by prior arrangement (manual answer).

1 0

Draft H.246 Annex C
by Christian Groves 26 Apr '99

26 Apr '99

G'Day All, Attached is a draft copy of H.246 Annex C. As you can see it is Version 0.0 so it needs some work. It is based on Q.699 as is split into 4 main sections: 1 Overview/Introduction 2 ISUP to H225 message and parameter mapping 3 Outgoing Call - H.225 to ISUP Basic Call Services 4 Incoming Call - ISUP to H.225 Basic Call Services The services sections need some work to align with the 3pty/conference discussions. RAS hasn't been considered in the document yet. Comments/addition/amendments welcome. Regards, Christian Groves

1 0

RAS and CRVs
by Derks, Frank 26 Apr '99

26 Apr '99

Last week I went through the mechanisms described in H.225 to associate messages, calls and conferences. The thing that struck me as being odd was that only some of the RAS request messages (i.e. ARQ, BRQ and DRQ) carry a call reference and a call identifier. It would seem appropriate to only use these values in "call associated" messages, hence some of the request messages do not carry these elements (GRQ, RRQ, URQ, IRQ, LRQ) but why do I not see these elements in the response messages? How am I supposed to associate an ARQ with an ACF/ARJ? If this is done by some other means than the CRV, then this element should be removed. Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philip Business Communications |P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:f.derks@pbc.be.philips.com | WWW: http://www.business-comms.be.philips.com | -----------------------------------------------------

1 0

Re: Media Gateway Control Requirements
by Tom-PT Taylor 24 Apr '99

24 Apr '99

Thanks for noticing this. I will make sure it gets changed. > -----Original Message----- > From: Kumar, Vineet [SMTP:vineet.kumar@intel.com] > Sent: Wednesday, April 21, 1999 12:37 PM > To: 'Mailing list for parties associated with ITU-T Study Group 16'; > Taylor, Tom-PT [CAR:5V00-I:EXCH] > Subject: RE: Media Gateway Control Requirements > > Tom, > > Seems that multimedia is not a requirement in the Megacodraft. I would > assume that Multimedia would be a requirement from SG16 because that's > what > we do. > > vineet > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > Sent: Monday, April 19, 1999 7:41 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Media Gateway Control Requirements > > > If Megaco and SG 16 are to come up with a common Media Gateway control > protocol, we must agree on the requirements. I am attaching a zipped copy > of the latest draft of the Megaco requirements document, with the hope > that > SG 16 experts will feel free to comment on it. You can pass comments > either > to this list or to megaco(a)standards.nortelnetworks.com. > > A version of this document will be submitted as a Delayed Contribution to > the Santiago meeting. Depending on the number of comments we receive, > that > version may be the attached one or a revision of it. > > <<draft-ietf-megaco-reqs-02.zip>> > > Tom Taylor > E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) > Tel.: +1 613 736 0961 (ESN 396-1490) > FAX: same number by prior arrangement (manual answer). >

1 0

Re: Annex G and Roaming?
by Edgar Martinez [1] 23 Apr '99

23 Apr '99

I fully support the interworking between the legacy mobile network VLR/HLR applications and H.323 GK access via the SG to provide seamless roaming between PLMN and IP networks. This work will need to be addressed in Tiphon's WG7. Regards, Ed "Roy, Radhika R, ALCOO" wrote: > > Hi Everyone: > > Yes, I guess that the roaming has not been addressed in the present H.225.0 > AnnexG. To address roaming in a standard way, it will require to change the > scope of Annex G. > > Annex G addresses the inter-domain communications. > > We have not yet standardized the basic roaming schemes even for the simple > intra-domain communications. > > Last year, we discussed this problem, and some suggestions were made to > solve this using the home and visiting GK. The discussion did not go too far > to create a standard. > > It is an important topic, and let us create a standard in H.323 to support > roaming. > > Let us understand that, in H.323, we are talking in the application layer, > and not the networking layer. That is, roaming schemes have to be supported > in the H.323 application layer that can take advantage of the mobility > solutions provided in the network layer (e.g., mobile IP). > > Thanks, > Radhika R. Roy > AT&T > > > -----Original Message----- > > From: Espen Skjæran [SMTP:Espen.Skjaeran@ERICSSON.COM] > > Sent: Friday, April 23, 1999 8:55 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Annex G and Roaming? > > > > Hi all, > > > > I've recently heard (unofficially) that some claim Annex G > > (APC-1546/TD-20 in Monterey) > > also to support roaming of users between different domains. > > > > If this is true, I wonder how. > > > > I can see how the AccessRequest/ValidationRequest might be sent from a > > visiting domain to the home domain for per-call authorization. While > > this might work in simple cases, it will hinder the use of services > > while roaming. > > I can not either see any mechanism to authorize the roaming > > registration. > > > > I am sorry to post based on "rumors", but this may change the scope of > > Annex G significally, and I worry if this might affect future work on > > roaming. As Tiphon has just started their work on roaming by analysing > > existing roaming techniques in telco and datacom/IETF work,and not yet > > reached any conclusion, it seems premature to use annex G > > in its current state for roaming. > > > > Espen -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 TIPHON & Other Stds -- http://www.cig.mot.com/~martinze/

2 1

Re: Annex G and Roaming?
by Roy, Radhika R, ALCOO 23 Apr '99

23 Apr '99

Hi Everyone: Yes, I guess that the roaming has not been addressed in the present H.225.0 AnnexG. To address roaming in a standard way, it will require to change the scope of Annex G. Annex G addresses the inter-domain communications. We have not yet standardized the basic roaming schemes even for the simple intra-domain communications. Last year, we discussed this problem, and some suggestions were made to solve this using the home and visiting GK. The discussion did not go too far to create a standard. It is an important topic, and let us create a standard in H.323 to support roaming. Let us understand that, in H.323, we are talking in the application layer, and not the networking layer. That is, roaming schemes have to be supported in the H.323 application layer that can take advantage of the mobility solutions provided in the network layer (e.g., mobile IP). Thanks, Radhika R. Roy AT&T > -----Original Message----- > From: Espen Skjæran [SMTP:Espen.Skjaeran@ERICSSON.COM] > Sent: Friday, April 23, 1999 8:55 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Annex G and Roaming? > > Hi all, > > I've recently heard (unofficially) that some claim Annex G > (APC-1546/TD-20 in Monterey) > also to support roaming of users between different domains. > > If this is true, I wonder how. > > I can see how the AccessRequest/ValidationRequest might be sent from a > visiting domain to the home domain for per-call authorization. While > this might work in simple cases, it will hinder the use of services > while roaming. > I can not either see any mechanism to authorize the roaming > registration. > > I am sorry to post based on "rumors", but this may change the scope of > Annex G significally, and I worry if this might affect future work on > roaming. As Tiphon has just started their work on roaming by analysing > existing roaming techniques in telco and datacom/IETF work,and not yet > reached any conclusion, it seems premature to use annex G > in its current state for roaming. > > Espen

1 0

Re: FW: RRQ Registration in H.323 V2
by Chris Purvis 23 Apr '99

23 Apr '99

Rob, What I'm struggling for here is to understand what this common alias ("something like voip-gw.hotmail.com") is used for, and why you have it at all. Until I understand that I can not suggest how you solve your problem. As for the issue of multiple aliases in RRQ, please find enclosed my musings on the subject, sent to the IMTC h323implementer's reflector just two days ago! Regards, Chris > -----Original Message----- > From: Rob B [mailto:robb112@HOTMAIL.COM] > Sent: 23 April 1999 2:46 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: FW: RRQ Registration in H.323 V2 > > > Chris, > > H.323 V2 specifically says that each alias address should > map to a unique transport address. So, as you pointed out > my second RRQ would get rejected because alias is the > same "voip-gw.hotmail.com" but a different transport > address is registered :-( > > So, the only option left for me is to choose some dummy > alias in my RRQs. > > Section 7.2.2 H.323V2 > "A Gateway or MCU may register a single Transport address or > multiple transport addresses. The use of multiple transport > addresses may simplify the routing of calls to specific ports" > > How can a _single_ gateway achieve the above stated. (Because > what I am doing by sending multiple RRQs with different aliases > is essentially simulating multiple logical gateways in the network.) > > Btw, one another related question. What is the meaning of > multiple callSignalAddresses of _same_ transport type in > RRQ.callSignalAddress. Is this possible and if possible how will > the gatekeeper use them? I have a private mail from one vendor that > multiple callSignalAddresses of the same transport type are > possible in RRQ but no one uses them. I think I have to > agree with him. > > Thanks for your time. > -Chris. > > > >From this description it seems fairly clear that you (logically, > from a > >protocol point of view) have two gateways that happen to be > collocated. The > >only alias you're passing around is the phone number, and that wants > to go > >to different places according to how it starts. However in an > earlier mail > >you said you only had a single gateway because you only have a single > >terminalAlias ("something like voip-gw.hotmail.com"). As this alias > appears > >not to be passed around at any point during call setup it appears > >irrelevant, although registering the same alias to different > (logical) > >gateways to the same gatekeeper at the same time may cause problems > to some > >gatekeepers. > > > >Regards, > >Chris > > > >> -----Original Message----- > >> From: Rob B [mailto:robb112@HOTMAIL.COM] > >> Sent: 21 April 1999 7:10 > >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> Subject: Re: FW: RRQ Registration in H.323 V2 > >> > >> > >> Chris, > >> > >> > > >> >Just trying to understand the problem fully before jumping in with > a > >> >suggested solution: > >> >How are you expecting people to call via this gateway? > >> >Is the intention to place a call to multiple destionationInfos, > >> specifying > >> >first an alias that identifies the gateway, followed by a full > phone > >> number > >> >starting 408 or 409? If not, what is the intended action from an > >> endpoint > >> >attempting to call through this gateway? > >> > > >> > >> My customers would have something like Netmeeting. They would > >> make calls with an area code, say like 1-408-555-6666. > >> > >> Let us say I have GW1 and GK. GW1 supports area codes 408 and > >> 409. It registers these two voice call prefixes (1408 and 1409) > >> with GK along with port numbers 2000 and 3000. Any incoming > >> calls on port 2000 are automatically assumed to be outgoing > >> calls to area code 408 (so that GW1 need not again parse the > >> calledPartyNumber in the incoming message). Parsing of the > >> remaining number would be done at much later point in time. > >> > >> Now, when a call originates from netmeeting, the ARQ would contain > >> the destination telephone number (1408555666) in the > >> "destinationInfo". GK receives this ARQ and figures out > >> that it has GW1 which registered the prefix 1408. So, GK returns > >> the <GW1 IP Address + 2000> to netmeeting. And netmeeting would > >> directly send the Q.931 SETUP message GW1's port 2000. > >> > >> This is what I am looking for. > >> > >> Thanks, > >> -Chris (R) > >> > >> > >> >> >I have a question on RRQ registration in H.323V2. Let us say > >> >> >I have a gateway that supports area codes 408, 409. I want > >> >> >my gatekeeper to route calls to area codes 408 and 409 > >> >> >to my local TCP ports 2000 and 3000 respectively. How should > >> >> >I construct my RRQ message? > >> >> > > >> >> >Shall I send two RRQs with same endpoint identifier > >> >> >(because I have only one gateway) with tuples > >> >> ><408, 2000> and <409, 3000>. > >> >> > > >> >> ><x,y> means: x: carried in SupportedProtocols.prefix > >> >> > y: carried in callSignallingAddress of RRQ > message > >> >> > > >> >> >Is my understanding correct? > >> >> > > >> >> >-Chris Rob > >> >> > > >> >> > > >> > >> > >> _______________________________________________________________ > >> Get Free Email and Do More On The Web. Visit http://www.msn.com > >> > > > _______________________________________________________________ > Get Free Email and Do More On The Web. Visit http://www.msn.com >

1 0