- sg16-avd - lists.packetizer.com

how many port pairs in a call/conference?
by grm＠ZURICH.IBM.COM 25 Jun '98

25 Jun '98

OK, I thought these were easy questions but maybe people wonder 'what does he mean by RTP Session?' Let me rephrase: (A) How many (RTP port, RTCP port) pairs does an H.323 endpoint allocate in a two-party call with two-way audio? (B) How many (RTP port, RTCP port) pairs does an H.323 endpoint allocate in an n-party conference with everybody sending and receiving audio and using distributed multi-unicast? Marcel Graf IBM Zurich Research Lab > I'm trying to find an answer to the question (… [View More]A) "how many RTP > Sessions are there for a two-party call with two-way audio?", and to > the related question (B) "how many RTP Sessions are there for an > n-party conference with each participant being an audio Source and an > audio Sink and using distributed multi-unicast?". > > What I already know is that, assuming unidirectional Logical > Channels, in the first case there are two Logical Channels, and in > the second case there are n*(n - 1) Logical Channels. > > H.245 says about the sessionID: "The sessionID is a unique RTP or > T.120 Session Identifier in the conference. It is used by the > transmitter to refer to the session to which the logical channel > applies. Only the master can create the session identification. By > convention, there are three primary sessions. The first primary > session with a session identification of 1 is the audio session, the > second primary session with a session identification of 2 is the > video session, and the third primary session with a session > identification of 3 is the data session." > > Can I interpret this paragraph as saying that in case (A) there is > only one RTP Session, and in case (B) there is only one RTP Session, > too? > > If that is correct, then the following paragraph from H.323 section > 6.2.8.2 "Logical channel signalling" comes into play: "If a > corresponding reverse channel is opened for a given existing RTP > session (identified by the RTP sessionID), the mediaControlChannel > transport addresses exchanged by the OpenLogicalChannel process shall > be identical to those used for the forward channel. Should a > collision occur where both ends attempt to establish conflicting RTP > sessions at the same time, the master endpoint shall reject the > conflicting attempt as described in Recommendation H.245. The > rejected OpenLogicalChannel attempt may then be retried at a later > time." > > What type of conflict does this paragraph refer to? Given there is a > single RTP Session, and (multi-)unicast is used, each endpoint > chooses the RTP and RTCP port it is listening on independently of the > others. (The paragraph can't be talking about multicast, because it > is the MCs responsibility to allocate multicast addresses.) > > I also made the following observation: The "primary session > convention" established in the cited H.245 paragraph seems to be > contradicted by the samples shown in H.323 Appendix I "Sample MC to > Terminal Communication Mode Command" which uses the sessionIDs 2 and > 3 differently. Maybe the convention is only meant for two-party calls? > > > Marcel Graf > IBM Zurich Research Lab [View Less]

2 1

Re: SNMP audio call
by Tom-PT Taylor 24 Jun '98

24 Jun '98

Please reserve a port for Nortel. Nicole Gallant will be taking part on our behalf. > -----Original Message----- > From: George Kajos [SMTP:gkajos@VIDEOSERVER.COM] > Sent: Tuesday, June 23, 1998 9:15 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: SNMP audio call > > Hello folks, > I'm resuming the Multimedia MIB audio call tomorrow, June 24 at 11-1:00 > EST. Please let me know if you desire a bridge number to attend the call. > My agenda is to discuss … [View More]

1 0

Re: conferenceListChoice
by Stewart, Glenn 23 Jun '98

23 Jun '98

Chris, Actually I agree with you, getting a list of conferences to Join in response to a create is kind of odd... The reason this occurs is that unlike T.120 there is no initial query function in H.323 call setup for the calling terminal to find out the nature of the called terminal. In general terminals (H.323 and H.320 for that matter) provide users a simple phone call model UI. The user provides an address and the terminal calls it. In this interface (unless the terminal requires or … [View More]caches information about the nature of the target) the terminal is not aware of the intent of the call. In fact the user may not be aware of the ultimate intent of the call. Much of the time the user just wants to make a simple point to point connection and so one model is that the calling terminal simply asks the called party/terminal to create a conference. If the called party does not want to create the conference it refuses the connection and provides potential information on how to proceed. One of these possible responses is a list of conferences the terminal software can present to the user allowing the user to select conference he or she would like to join. I should point out there are terminals that make the user determine a priori the nature of the call (i.e., the user must indicate they are calling an MCU (or conference service) and would like to join a conference). While obviously being technically clean and correct, I personally, find them difficult to use. The model provided above, although "strange", is actually more intuitive in my opinion. glenn > -----Original Message----- > From: Chris Purvis WVdevmt-WS [mailto:cpurvis@madge.com] > Sent: Tuesday, June 23, 1998 5:10 AM > To: gstewart(a)sonusnet.com > Cc: mbozier(a)madge.com; jim.toga(a)intel.com; gthom(a)delta-info.com; > gkajos(a)videoserver.com > Subject: RE: conferenceListChoice > > > Glenn, > > Thanks for the response. It still seems a little strange offering an > endpoint a choice of conferences to JOIN when it has asked to > CREATE a new > conference, but at least it now seems reasonably clear what > you intended. > Don't worry about lack of clarity, by the way - that's the > fault of everybody > who had a chance to comment on the text, not just the person > who submitted it > in the first place. > Would you like to squirt some clarification back out on the > reflectors? > > Jim: Can something go in the implementor's guide on this, please? > > Chris > ---------------------------------------------------- > Chris, > > The conferenceListChoice element is only to provide a list of > conferences that the calling endpoint can join. The ability of the > calling endpoint to create a conference at the MCU is a choice left to > the MCU manufacturer. Assuming the MCU will allow a "create" then use > of the supplied GCID is sufficient. > > Your second (more serious) point reveals a lack of clarity in the text > (supplied by me I'm afraid). Not explicitly stated is that the > "Facility" message is a routeCallToMC in which the MCU Call Signaling > Address and the conference list are supplied. The calling > endpoint then > sends new Setup to the supplied Call Signaling Address with > the selected > conference (see section 8.4.3.7). > > My apologies for not making this more clear in the originally supplied > text. > > glenn > > Glenn Stewart > ~~~~~~~~~~~~~~~~~~~~~~~ > gstewart(a)sonusnet.com > Sonus Networks > ~~~~~~~~~~~~~~~~~~~~~~~ > PS: Gary - I'm not sure if your still editing H.323, but I thought the > editor should have a copy of this. Can you please forward this as > appropriate? > > > -----Original Message----- > > From: Chris Purvis WVdevmt-WS [mailto:cpurvis@MADGE.COM] > > Sent: Thursday, June 18, 1998 1:07 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: conferenceListChoice > > > > > > All, > > > > H.323 version 2 states in 8.4.3.1 A2d) and 8.4.3.4 that an > MCU can use > > conferenceListChoice to give a version 2 endpoint the choice > > between a number > > of possible conferences of which one it would like to > > create(!). I have two > > points with regard to this: > > 1. Surely it would also be sensible to have a similar method > > for joining > > extant conferences (rather than just sending ReleaseComplete > > when CIDs don't > > match)? Would'nt this be an easy (no extra ASN.1!) and > > useful addition? > > 2. (more serious) I can't see how an endpoint tells the MCU > > which conference > > from the list it has chosen! > > Is it up to the endpoint to release the call and send a new > > setup message > > with the appropriate conference alias in, or does it send > > back a similar > > facility message to the one it was sent, with a single > > ConferenceList in > > rather than a sequence of same? > > > > Chris > > ---------------------------------------- > > Dr Chris Purvis - Senior Development Engineer, WAVE CC Software > > Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. > > Phone:+44 1753 661359 email: cpurvis(a)madge.com > [View Less]

1 0

Re: SNMP audio call
by Chris Gindel 23 Jun '98

23 Jun '98

George, Please send me a number for the call. Thanks, Chris > -----Original Message----- > From: George Kajos [SMTP:gkajos@VIDEOSERVER.COM] > Sent: Tuesday, June 23, 1998 9:15 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: SNMP audio call > > Hello folks, > I'm resuming the Multimedia MIB audio call tomorrow, June 24 at > 11-1:00 > EST. Please let me know if you desire a bridge number to attend the > call. > My agenda is to discuss the August IETF … [View More]

1 0

SNMP audio call
by George Kajos 23 Jun '98

23 Jun '98

Hello folks, I'm resuming the Multimedia MIB audio call tomorrow, June 24 at 11-1:00 EST. Please let me know if you desire a bridge number to attend the call. My agenda is to discuss the August IETF meeting and to get commitments for the 3 missing H.323 annexes - GW, MC, and MP. Thank you, George Kajos VideoServer 63 Third Avenue Burlington, MA 01803 tel: (781) 505-2193 fax: (781) 505-2101 email: gkajos(a)videoserver.com

1 0

how many RTP Sessions in a call/conference?
by grm＠ZURICH.IBM.COM 19 Jun '98

19 Jun '98

I'm trying to find an answer to the question (A) "how many RTP Sessions are there for a two-party call with two-way audio?", and to the related question (B) "how many RTP Sessions are there for an n-party conference with each participant being an audio Source and an audio Sink and using distributed multi-unicast?". What I already know is that, assuming unidirectional Logical Channels, in the first case there are two Logical Channels, and in the second case there are n*(n - 1) Logical Channels. … [View More] H.245 says about the sessionID: "The sessionID is a unique RTP or T.120 Session Identifier in the conference. It is used by the transmitter to refer to the session to which the logical channel applies. Only the master can create the session identification. By convention, there are three primary sessions. The first primary session with a session identification of 1 is the audio session, the second primary session with a session identification of 2 is the video session, and the third primary session with a session identification of 3 is the data session." Can I interpret this paragraph as saying that in case (A) there is only one RTP Session, and in case (B) there is only one RTP Session, too? If that is correct, then the following paragraph from H.323 section 6.2.8.2 "Logical channel signalling" comes into play: "If a corresponding reverse channel is opened for a given existing RTP session (identified by the RTP sessionID), the mediaControlChannel transport addresses exchanged by the OpenLogicalChannel process shall be identical to those used for the forward channel. Should a collision occur where both ends attempt to establish conflicting RTP sessions at the same time, the master endpoint shall reject the conflicting attempt as described in Recommendation H.245. The rejected OpenLogicalChannel attempt may then be retried at a later time." What type of conflict does this paragraph refer to? Given there is a single RTP Session, and (multi-)unicast is used, each endpoint chooses the RTP and RTCP port it is listening on independently of the others. (The paragraph can't be talking about multicast, because it is the MCs responsibility to allocate multicast addresses.) I also made the following observation: The "primary session convention" established in the cited H.245 paragraph seems to be contradicted by the samples shown in H.323 Appendix I "Sample MC to Terminal Communication Mode Command" which uses the sessionIDs 2 and 3 differently. Maybe the convention is only meant for two-party calls? Marcel Graf IBM Zurich Research Lab [View Less]

1 0

H.321/H.322
by Gary A. Thom 19 Jun '98

19 Jun '98

All, I am putting together a report on the maturity of some of the H-Series recommendations. I am trying to find out if anyone produces or plans to produce products which comply with H.321 or H.322. If you do, or if you know that someone else does, could you please drop me an e-mail. Thanks Gary ------------------------------------------------------ Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-… [View More]

1 0

conferenceListChoice
by Chris Purvis WVdevmt-WS 18 Jun '98

18 Jun '98

All, H.323 version 2 states in 8.4.3.1 A2d) and 8.4.3.4 that an MCU can use conferenceListChoice to give a version 2 endpoint the choice between a number of possible conferences of which one it would like to create(!). I have two points with regard to this: 1. Surely it would also be sensible to have a similar method for joining extant conferences (rather than just sending ReleaseComplete when CIDs don't match)? Would'nt this be an easy (no extra ASN.1!) and useful addition? 2. (more serious)… [View More]

1 0

Proposal for Common RDC Protocol is available
by Mark Duckworth 18 Jun '98

18 Jun '98

This proposal for work on a common RDC protocol is submitted to the Q3 meeting next week in Colorado Springs. I uploaded it to: ftp://ftp.imtc-files.org/imtc-site/incoming/Common_RDC_Proposal.zip Bruce DeGrasse, please move it to ftp://ftp.imtc-files.org/imtc-site/T120-top/t120_colorado98 Summary: This proposal continues the work of recent RDC audio conferences and the Q11-14/16 meeting in Cannes. The proposed approach is to use a common RDC protocol (V.RDC) which can be carried within a T.… [View More]

1 0

Re: GloballyUniqueID duplicates
by Douglas Clowes 17 Jun '98

17 Jun '98

At 18:43 16/06/98 -0700, you wrote: >>---------- >>From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU] >>On reading the text in H.225.0 describing the construction of a globally >>unique identifier, it seems to me that duplicates are possible if the clock >>has not advanced since the last identifier was generated. >That's what the clock sequence value is for. > >Paul Long >Smith Micro > Perhaps, but on my reading, it's not what the document says! … [View More]

2 1