April 1999 - sg16-avd - lists.packetizer.com

Re: Draft H.246 Annex C
by Edgar Martinez [1] 07 May '99

07 May '99

Hi Christian, Good timing, In the study D meeting in Washington dc I was asked to put my contribution as a proposal for new annex in h.246. In the contribution I show one example in Annex-A of the RAS messages mapping into ITU INAP other example may include HLR/VLR, MAP and WIN messages. I did not include the parameters mapping. Because, I did not want to do all that work until the concept is approved. (document attached) In any case I have proposed the lower layer sigtran transport (CTP) to carry upper layer protocol for tunneling and interworking. Which should not be any issue with h.246 or the work you are doing..I hope? I will read your contribution as a framework going forward on SS7 interworking. We both/all need to resolve the Transport problem where to terminate the Lower SS7 layers (MTP 1,2,3). That is, where does SS7 ends and IP begins? in the H.323 network i.e., tiphon. Regards, Ed Christian Groves wrote: > > 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 > > ------------------------------------------------------------------------ > Name: h246_annex_c_v_0-0.zip > h246_annex_c_v_0-0.zip Type: Winzip32 File (application/x-zip-compressed) > Encoding: base64 -- 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

flowControlCommand and packet overhead
by Paul Long 06 May '99

06 May '99

In response to a private query, I discovered that there is a minor oversight in H.323 regarding whether the flowControlCommand includes packet overhead. Here's what it says about the open logical channel bitrate and ARQ bandwidth parameters, respectively, which can be used to determine the intent for FlowControlCommand: 6.2.11.2/H.323v2: "The limit applies to the information streams which are the content of the logical channel(s), not including RTP headers, RTP payload headers and network headers and other overhead." 7.2.4/H.323v2: "This is an upper limit on the aggregate bitrate for all transmitted and received, audio and video channels excluding any RTP headers, RTP payload headers, network headers, and other overhead." Therefore, clarification text to the following effect should be added to 6.2.11.2 (in v2) of H.323: "flowControlCommand applies to the information streams which are the content of logical channel(s), not including RTP headers, RTP payload headers, network headers and other overhead." Practically speaking, though, it appears that most vendors violate H.323 by ignoring this command altogether, so one is doing very well indeed at least attempting to obey it with or without counting overhead. Note that in H.324 the limit includes packet overhead when applied to the entire mux but not when applied to an individual channel; however, in H.323 the limit never includes overhead. IMO, H.324 makes more sense, but I suppose in H.323 one may not know exactly how much overhead is added by a lower layer, e.g., the UDP/IP headers added by the sockets layer, and also because H.323 is ostensibly transport-layer independent. Paul Long Smith Micro Software, Inc.

2 1

Implementers Guide Edits
by Jim Toga 05 May '99

05 May '99

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

3 4

Re: Megaco/H.gcp call
by Tom-PT Taylor 30 Apr '99

30 Apr '99

Make that EDT, not EST. > -----Original Message----- > From: Bryan Hill [SMTP:bhill@VIDEOSERVER.COM] > Sent: Friday, April 30, 1999 7:41 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Megaco/H.gcp call > > 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 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] 24 Apr '99

24 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

Re: ITU-T Santiago Contributions
by Sakae OKUBO 23 Apr '99

23 Apr '99

Dear Mr. Moscovici, Interim Rapporteur meetings are autonomously organized by the interested experts, but the SG16 meeting in Santiago is official and managed by Mr. Fabio Bigi, ITU-TSB. In addition to White Contributions, input documents can only be submitted as follows: - Delayed Contributions from member organizations. They go through national procedures and shall reach ITU-TSB not later than 5 May 1999 as described in Collective-letter 5/16. You con find this and relevant TSB Circular 173 at the ITU Web site. - Temporary Documents from Rapporteurs. They can be accepted even just before the meeting. Please also note that only ITU-T memebers can attend the Santiago meeting. LM> I would like to submit two contributions to the Santiago meeting: LM> 1. "Modifications to H.225.0 Annex G" from Israel, VocalTec as source. LM> 2. "Editorial Corrections to H.225.0 Annex G" from Editor (myself). LM> Note these two are proposals that affect the white draft for decision at LM> this meeting. So, the first should go through Israel process as a Delayed Contribution. The source can either be Israel Administration or ITU-T Sector Member (company). Please do not forget about the deadline, 5 May, otherwise Mr. Bigi will not accept your contribution. The second should go through Dale. LM> Since I am not familiar with the procedures at the plennary meetings, LM> please advise: do I need APC allocations? Are there other things I LM> should do? There is no need for APC numbers, they are only for self organized Rapporteur meetings. LM> I will have these two contributions available on the AVC site by next LM> week. Your posting is appreciated. Whatever made available will be moved to 9905_San directory without APC numbers for the expert convenience. LM> As for ordinary rapporteur contributions - VocalTec intends to submit LM> two other contributions. Do they have to be on a national basis (i.e. LM> Israel), or on a company basis, as in a Rapporteur meeting. LM> Do we need APCs? Even if your contributions are for the Rapporteur meeting portion of the Santiago week, they are managed by Mr. Bigi. No need for APC numbers. You need to submit them as Delayed Contributions. Again, the source can be VocalTec if it is an ITU-T Sector member. Otherwise, they may be submitted as Israel contributions subject to your national process. Please allow me copy this response to all the memebers registered to the Q.12-14 group reflector for their information. 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

Re: FW: RRQ Registration in H.323 V2
by Rob B 23 Apr '99

23 Apr '99

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

2 1

Megaco reqs draft is 01, not 02...: I-D ACTION:draft-ietf-megaco- reqs-01.txt
by Nancy-M Greene 22 Apr '99

22 Apr '99

Everyone, Since the requirements draft we just issued was the first revision that the IESG saw, the number of it is -01 instead of -02 as I previously announced. So, if you are looking for the latest megaco requirements draft, the one to look for is draft-ietf-megaco-reqs-01.txt, dated April 18/99. (See below). It is identical to the -02 version at ftp://standards.nortelnetworks.com/megaco/docs/oslo99 (at some point I will rename the -02 to -01 on that site...) Sorry for the mixup. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Internet-Drafts@IETF.ORG[SMTP:Internet-Drafts@IETF.ORG] > Sent: Wednesday, April 21, 1999 1:10 PM > To: MEGACO(a)standards.nortelnetworks.com > Subject: I-D ACTION:draft-ietf-megaco-reqs-01.txt > > <<Message: Microsoft Exchange Message>> > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Media Gateway Control > Working Group of the IETF. > > Title : Media Gateway Control Protocol Architecture > and Requirements > Author(s) : N. Greene, M. Ramalho, B. Rosen > Filename : draft-ietf-megaco-reqs-01.txt > Pages : 35 > Date : 20-Apr-99 > > This document describes protocol requirements for the Media Gateway > Control protocol between a Media Gateway Controller and a Media Gateway. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-01.txt > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-megaco-reqs-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv(a)ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-megaco-reqs-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >

1 0

Re: Media Gateway Control Requirements
by Gunnar Hellstrom 22 Apr '99

22 Apr '99

I checked the Megaco requirements mainly from the point of view of how well it covers gatewaying between different forms of real time text conversation facilities. The most apparent need is between the current analogue network based text telephones and IP text phones that are in the process of being defined in SG16. The current textphones are working with different types of modem-like signalling ( that all can be joined by the V.18 modem in the gateway) while in IP networks it is T.140 carried by a data protocol. With the current efforts in the US to arrange some kind of gateway between land based text telephony and mobile text telephony, work in this direction is already going on. I found very little influence. And that might pose a question: Is Megaco too vague, does it need to get more specific in its requirements to really imply something? But that might be the next step - the protocols and functions. I want to suggest the following modifications to specifically mention the important real time text gatewaying: ----------------------------------------------------------------------------- 5.2 d : insert "text" together with the other media, to read "e.g. audio, text, video, T.120 ) 5.3 d : insert "text telephony" before FAX 11. Table 1. I am not sure what this table indicates. All multimedia protocols are missing. Is it some kind of very basic mandatory media requirements? Without really knowing, I recommend: For ISDN, add Multi-media to the applications. For Analogue, and Restricted, add Text telephony after FAX. Insert a new section 11.2.4 ( pushing the existing down one step) 11.2.4 Trunking/Access Gateway with text telephone access ports 11.2.10 IVR Unit Insert a requirement: IVR should never be the only way to control the MG. Text based and web based control are important alternatives. Accepted? Gunnar Hellström At 10:41 1999-04-19 -0400, Tom-PT Taylor wrote: >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). > > >Attachment Converted: "c:\_Omnitor\Attach\draft-ietf-megaco-reqs-02.zip" > ----------------------------------------------- Gunnar Hellstrom Representing Ericsson in ITU-T E-mail gunnar.hellstrom(a)omnitor.se Tel +46 751 100 501 fax +46 8 556 002 06

1 0

Re: Any news on new megaco draft ?
by Brian Rosen 22 Apr '99

22 Apr '99

A new version was put out to the MEGACO list on Monday. The draft should appear on the I-D ftp site in a day or two. If you would like I can send it to the SG16 list. Brian > -----Original Message----- > From: Boaz Michaely [mailto:Boaz_Michaely@vocaltec.com] > Sent: Thursday, April 22, 1999 7:11 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Any news on new megaco draft ? > > > Is there an update for the megaco protocol ? I thought one > was expected on > April 16 ? > Thanks, > > Boaz Michaely > Senior Program Manager, Advanced Technologies > VocalTec Communications Ltd > e-mail boaz(a)vocaltec.com >

1 0

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

22 Apr '99

Chris (R) [Why do your mails come from RobB???], >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 >

1 0

RRQ Registration in H.323 V2
by Rob B 22 Apr '99

22 Apr '99

Is the implementors mailing list down, apparently no one got this message. If anybody from SG16 can explain ... Thanks From: "Rob B" <robb112(a)hotmail.com> To: h323implementors(a)imtc.org CC: robb112(a)hotmail.com Date: Thu, 15 Apr 1999 14:30:50 PDT SG16 experts, 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

2 1

Any news on new megaco draft ?
by Boaz Michaely 22 Apr '99

22 Apr '99

Is there an update for the megaco protocol ? I thought one was expected on April 16 ? Thanks, Boaz Michaely Senior Program Manager, Advanced Technologies VocalTec Communications Ltd e-mail boaz(a)vocaltec.com

1 0

Re: FW: RRQ Registration in H.323 V2
by Rob B 21 Apr '99

21 Apr '99

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

1 0

Re: Media Gateway Control Requirements
by Kumar, Vineet 21 Apr '99

21 Apr '99

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: Media Gateway Control Requirements
by Roni Even 21 Apr '99

21 Apr '99

Tom, I agree with Vineet. I also like to point out that in The H.GCP documents in paragraph 6.1 the requiremenst section 2 specify audio only. On the other hand there is a multimedia hints in number 3 and 5. Roni Even -----Original Message----- From: Kumar, Vineet <vineet.kumar(a)INTEL.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: יום רביעי 21 אפריל 1999 19:36 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: FW: RRQ Registration in H.323 V2
by Chris Purvis 21 Apr '99

21 Apr '99

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? Regards, Chris (P) -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis(a)madge.com > -----Original Message----- > From: Rob B [mailto:robb112@HOTMAIL.COM] > Sent: 21 April 1999 12:17 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: FW: RRQ Registration in H.323 V2 > > > Gaurav, > > Nope, it is one single logical gateway. It has only one > terminalAlias (something like voip-gw.hotmail.com) But it > supports outgoing voice calls to area codes 408 and 409. > > As specified in section 7.2.2 of H.323 V2 spec para 2 > "The use of multiple transport addresses may simplify > the routing of calls to specific ports". I am trying to > simplify routing in my gateway. > > Is the above statement in H.323 V2 correct now? Is there > anyone on the list who has tried to do something like > above? > > Or is it that, to acheive my goal I have to divide > my gateway into logical H.323 entities which I am > not sure is needed. > (if each registration of RRQ is allocated a different > endpoint identifier then from GK perspective there are > multiple H.323 entities). > > Regards, > -Chris > > PS: Endpoint identifier is allocated by GK and returned > to endpoint via RCF. (The same endpoint identifier will > be used in keep alive RRQs.) If multiple RRQ's like I proposed > in my original mail is allowed by H.323 V2 then the > second RRQ would copy the endpoint identifier from > first RCF. > > >Hi Chris, > > As per my understanding, you are talking of different logical > gateways > >that > >are bundled together into a single *box*. Each such logical gateway > must > >register with the gatekeeper. The terminalAlias could be used to > identify > >the > >logical GW and the callSignalAddress would specify the contact point. > Hence, > >you > >would have to send 2 RRQs. Also, the endpointIdentifier is generated > by the > >GK > >and returned in the RCF and so cannot be specified by the GW at time > of > >registration. > > > > Any comments? > > > >Regards, > >Gaurav Makkar > > > > > > > >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

lost mail
by Sergei Koren 21 Apr '99

21 Apr '99

Hi, because of problem with our mail server 16-17 of April 1999 Your mail, you sent in these days to email address elid(a)radvision.rad.co.il was lost. I would like to ask you to resend the email. Regards, Postmaster, RADVision ltd.

1 0

Santiago meeting information
by Sakae OKUBO 21 Apr '99

21 Apr '99

Dear SG16 colleagues, Attached please find Mr. Tosco's additional information on the Santiago meeting. 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 *********************************************************** Date: Tue, 20 Apr 1999 13:53:11 +0200 From: Tosco Federico <Federico.Tosco(a)CSELT.IT> To: "Blaschitz, Michael" <michael.blaschitz(a)infonova.at>,"DeGrasse, Bruce" <b.degrasse(a)cwix.com>, Freundlich <ggf(a)lucent.com>,"Geary, Tom" <tom.geary(a)CONEXANT.COM>,"Okubo, Sakae" <okubo(a)giti.or.jp>,"Robin-Champigneul, Yves" <yves.robinchampigneul(a)cnet.francetelecom.fr>,"Skran, Dale" <Dale.Skran(a)ascend.com>,"Thom, Gary" <gthom(a)delta-info.com> MIME-version: 1.0 Dear all, Returning from the coordination meeting held in Geneva on Saturday April 17, I give you some information about events connected to the SG16 meeting in Santiago. * It is confirmed that an International Workshop will be held on Monday, May 17 * There will be a conference dinner on Wednesday, May 19 * There will be a farewell lunch on Saturday, May 29, in a famous vineyard near Santiago (in the conference web site there is an incorrect indication about the date) * Please see the conference site (http://www.ict.uchile.cl/itut.sg16/) for further information Best regards Federico CSELT Via Reiss Romoli 274 10148 TORINO Italy Tel.: +39 0112285321 Fax: +39 0112285295 E_mail: federico.tosco(a)cselt.it

1 0

Re: FW: RRQ Registration in H.323 V2
by Rob B 20 Apr '99

20 Apr '99

Gaurav, Nope, it is one single logical gateway. It has only one terminalAlias (something like voip-gw.hotmail.com) But it supports outgoing voice calls to area codes 408 and 409. As specified in section 7.2.2 of H.323 V2 spec para 2 "The use of multiple transport addresses may simplify the routing of calls to specific ports". I am trying to simplify routing in my gateway. Is the above statement in H.323 V2 correct now? Is there anyone on the list who has tried to do something like above? Or is it that, to acheive my goal I have to divide my gateway into logical H.323 entities which I am not sure is needed. (if each registration of RRQ is allocated a different endpoint identifier then from GK perspective there are multiple H.323 entities). Regards, -Chris PS: Endpoint identifier is allocated by GK and returned to endpoint via RCF. (The same endpoint identifier will be used in keep alive RRQs.) If multiple RRQ's like I proposed in my original mail is allowed by H.323 V2 then the second RRQ would copy the endpoint identifier from first RCF. >Hi Chris, > As per my understanding, you are talking of different logical gateways >that >are bundled together into a single *box*. Each such logical gateway must >register with the gatekeeper. The terminalAlias could be used to identify >the >logical GW and the callSignalAddress would specify the contact point. Hence, >you >would have to send 2 RRQs. Also, the endpointIdentifier is generated by the >GK >and returned in the RCF and so cannot be specified by the GW at time of >registration. > > Any comments? > >Regards, >Gaurav Makkar > > > >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

H.323 Implementers Guide Edits
by Jim Toga 20 Apr '99

20 Apr '99

Greetings, After some delay, I have completed the edits coming out of the Monterey meeting for the Implementers Guide. Please review the changes and verify that everything is as expected. I have incorporated (I believel) all of the relevent text mentioned in the Meeting report namely: APCs 1511,1512, 1520, 1522, 1533, 1506, and TDs 10, 14, 33. If I do not have any comments back by 4/16/99 then I will integrate these changes with the complete document in preparation for the Chile meeting. 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

3 2

Register for e-mail reflector
by sgk 20 Apr '99

20 Apr '99

Please register me for e-mail reflector. Thank you.

1 0

RequestSeqNum for MessageNotUnderstood
by Mike Ely 19 Apr '99

19 Apr '99

The following is an excerpt from H.225 V3: 7.17 Message Not Understood This message is sent whenever an H.323 endpoint receives a RAS message it does not understand. RequestSeqNum - Shall be the requestSeqNum of the unknown message, if it can be decoded, and zero otherwise. But in the ASN.1 included, the range for the request sequence number is: Requestseqnum ::= INTEGER (1..65535) With my latest version of the OSS compiler, I get a constraint violation attempting to send a zero request identifier. Is zero still the correct value when unable to decode a received PDU? Mike Michael Ely mely(a)paknetx.com http:\\www.paknetx.com

1 0

Media Gateway Control Requirements
by Tom-PT Taylor 19 Apr '99

19 Apr '99

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: RRQ Registration in H.323 V2
by Gaurav Makkar 19 Apr '99

19 Apr '99

Rob B <robb112(a)HOTMAIL.COM> on 04/16/99 11:34:28 PM Hi Chris, As per my understanding, you are talking of different logical gateways that are bundled together into a single *box*. Each such logical gateway must register with the gatekeeper. The terminalAlias could be used to identify the logical GW and the callSignalAddress would specify the contact point. Hence, you would have to send 2 RRQs. Also, the endpointIdentifier is generated by the GK and returned in the RCF and so cannot be specified by the GW at time of registration. Any comments? Regards, Gaurav Makkar 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

1 0

H.323 Annex F - SET questions
by Gunnar Hellstrom 18 Apr '99

18 Apr '99

Dear Jörg and all, When preparing H.323 Annex G - Text SET, I studied the base SET document; Annex F as in TD11 from Monterey, and came across a few points raising questions. I hope I can get clarifications on these points. 1. In section 6. it is said that for the Audio SET, "Data-capability is optional - possibly support for facsimile transmission." If this section is as is stated - for the Audio SET, then "No Data Capability" should be specified. And I think that is a good structure - Then I can write that the Text SET has Media Capabilities as for the Audio Set but with Data Capability for text conversation according to T.140. 2. In section 7.3.2. the explanations of the abbreviations M O I N, refers to Audio SET devices. The rest of this section looks general, why I suggest that the word "Audio" should be deleted in these four explanations. 3. Media Exchange. Insert TCP among the allowed protocols, so that data transmission SET:s can be allowed. 4. In section 7.6.1, the last sentence is "The OpenLogicalChannel structure should offer the same audio encodings that were in use prior to call rerouting." Looking back to the discussions in the list the last few weeks, I find that this sentence is misleading and can safely be deleted. The result should be that coding changes and media additions shall be allowed to occur after the rerouting. 5. In section 7.6.2, change the word "resume" to "start" in the last sentence. Since media additions may occur, media streams may be new after the rerouting. 6. Terminal type for SET types. I want to discuss the "Endpoint Type" specification in H.225.0 as described among the additions to implementor´s guides, titled "Addition of a terminal type for Simple Endpoint Types"and in Annex F, section 7.1. Bit 0 =1 if the device is an Audio SET. My question is: Should this specifier rather mark available functions than complete SETs? Then, bit 0 could indicate "the device has Audio functions" and , bit 2 could indicate "the device has Text conversation features." A Text SET should set them booth. This would allow for a combined text - fax - audio -SET. Regards Gunnar Hellström ------------------------------------------------ Gunnar Hellström Omnitor AB Alsnögatan 7, 4tr S-116 41 Stockholm SWEDEN Tel +46 751 100 501 Fax +46 8 556 002 06 E-mail: gunnar.hellstrom(a)omnitor.se WWW: www.omnitor.se ------------------------------------------------

1 0