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

Re: subscribe
by Sebestyen Istvan ICN M CS 27 03 Apr '00

03 Apr '00

Dale, any news about the status of the August/September SG16 Q.11-14 Rapp. Meeting? Regards, Istvan -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M CS27, Hofmannstr. 51 D-81359 Munich Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de E-mail private: istvan_sebestyen(a)yahoo.com; Siemens Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de ---------------------------------------------------------------------------- ---------------- > ---------- > From: Skran, Dale[SMTP:DSkran@SONUSNET.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Monday, April 03, 2000 3:00 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: subscribe > > dskran(a)sonusnet.com > > Dale Skran >

1 0

NetMeeting & T.120
by Stevie Gray 03 Apr '00

03 Apr '00

Hi, I am currently implementing a program which essentially passes T.120 data from one endpoint to another. I am doing this over H.245 using dynamic ports. The program basically joins the two T.120 bi-directional channels together via Winsock and lets the two endpoints get on with it. What I have discovered so far is that NetMeeting only seems to initiate a T.120 conference if it originated the Q.931 call. I have a scenario where I initiate the calls to each of the NetMeeting endpoints and join them together. However, in this scenario NetMeeting does not initiate the T.120 conference, I'm assuming they are both waiting for the Q.931 call initiator (i.e. me) to initiate the T.120 conference. I have tried various combinations of the T120SetupProcedure flag in the OLC Ack but to no avail. Is this a limitation of NetMeeting or is there a way to get this working. Here are a list of scenarios I have working NetMeeting --> MyProg --> NetMeeting NetMeeting --> MYProg <-- NetMeeting The one I can't get working is NetMeeting <-- MyProg --> NetMeeting I am using NetMeeting 3.01. Regards, Stevie. ========================================================== Stevie Gray sgray(a)ridgeway-sys.com Senior Software Engineer Ridgeway Systems & Software www.ridgeway-sys.com Tel +441189381124 Fax +441189354444 ==========================================================

1 0

Use of IRR by Gateways
by Mohamed Mustafa 03 Apr '00

03 Apr '00

Hi All, H.323 requires all endpoints to transmit an IRR message in response to an IRQ message from a Gatekeeper (or some other entity), and also to send unsolicited IRR messages to the Gatekeeper's RAS address at specific intervals if requested by the Gatekeeper in the ACF or RCF messages. As I understand it, an endpoint must provide the details of all active calls in a single IRR response if the callReferenceValue field in the IRQ is set to 0. This is clearly not possible if the endpoint supports thousands (or even hundreds!) of simultaneous calls. Can anyone provide any guidance on what to do in such a situation? Also, in the case of unsolicited IRR messages, I can't find anything which states that an endpoint must provide details of all active calls in each unsolicited IRR message. Therefore, an endpoint can either send a separate IRR message for each call, or it combine details of a number of calls (but not necessarily all) into each IRR message. Is my interpretation correct? Thanks, Mohamed

5 11

[Fwd: Force remote to start H.245 session?]
by Chris Wayman Purvis 03 Apr '00

03 Apr '00

Reply intended for the list unintentionally sent to Paul personally, so here you all are! Chris Chris Wayman Purvis wrote: > > Paul, > > First of all, sorry for the fact that this seems to be a week-old mail I'm > finally responding to... > > I may have misunderstood, but I don't understand why this is necessary. If > both endpoints have expressed willingness to use tunnelled H.245, why can an > endpoint not simply start sending H.245 messages (of COURSE starting with TCS, > and potentially tunnelled in purpose-built FACILITY messages) when it wishes to > start a tunnelled H.245 session? I would have thought that would be a pretty > clear indication of intent to start a tunnelled H.245 session! > > FACILITY/reason=startH245 is required for separate H.245 connections because an > endpoint may not know an address at its interlocutor to use to initiate an > H.245 connection. This problem doesn't exist in tunnelled H.245, so I see no > necessity for the extra interpretation! > > We may want some extra text specifying behaviour at the start of an H.245 > session, to ensure that the destination of the initial tunnelled H.245 message > actually does something constructive (sends a TCS) rather than non-constructive > (merely Acking the TCS it's been sent and not advancing anything useful). > > Regards, > Chris > > Paul Long wrote: > > > > How does an EP force the remote EP to bring up a tunneled H.245 session? > > > > Consider this call scenario: Fast Connect was enough to establish the > > desired media between two EPs. Both support H.245 Tunneling but neither has > > initiated an H.245 session because neither had any need to. One EP now needs > > to use H.245 procedures. It doesn't matter, but reasons include DTMF > > transmission via UII and requesting a different video format or different > > audio bit-rate via RequestMode. That EP can initiate its own H.245 > > procedures, e.g., TCS and MSD, but how does it force the other EP to bring > > up an H.245 session? > > > > H.323 and H.225.0 say that Facility/reason=startH245 is just for switching > > from Fast Connect or H.245 Tunneling to a separate H.245 channel, not for > > initiating an H.245 session via tunneling. Is it just hoped that when an EP > > sees that the other EP is bringing up an H.245 session, it will do the same? > > Seems like a pretty weak assumption. It would be nice if > > Facility/reason=startH245 without an h245Address meant to bring up an H.245 > > session on whatever transport is already established, i.e., tunneled or > > separate channel. Seems like we could do this in v4 because startH245 > > without an h245Address currently has no meaning. Whadya think? -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001

1 0

subscribe
by Skran, Dale 03 Apr '00

03 Apr '00

dskran(a)sonusnet.com Dale Skran

1 0

Re: Mob ad hoc group progress
by Kumar, Vineet 03 Apr '00

03 Apr '00

Paul, I think that we should look at both intra- and inter-network scenarios together. I don't see anything special in the intra-network scenario that would require us to look for its solution first. vineet -----Original Message----- From: Guram Paul-LPG019 [mailto:lpg019@EMAIL.MOT.COM] Sent: Sunday, April 02, 2000 12:52 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Mob ad hoc group progress Radhika, Conf call is for Annex H only as before...nothing has changed...change can only take place when the group agrees. Please do not read into the email more than what it says. I was only trying to highlight, in a high level report, the plight of Annex I since nothing much has moved in it, and it is an Annex which together with Annex H covers the mobility aspects. As far as Annex E is concerned, the point was that the mapping was the work of one individual or one company, thus could have errors or omissions (more than likely)...again only highlighting to people to check out this mapping. Contributions for next conf call to be for All H.323 intra-network scenario for: Registration procedures, Gatekeeper discovery, Location update, Call establishment, Mid-Call scenarios (e.g. supplementary services, user interaction), Call release. Also contributions on any impacts on the already specified architecture in the light of the present work are welcome. Paul -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: 01 April 2000 00:00 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Mob ad hoc group progress Hi, Paul and Mobility Group: I like to see that it should be clarified via emails whether H.323 Annex I and H.246 Annex E will be a part of the conference call. My personal preference is not to discuss annexes I and E during the conference call although email discussions will be preferred. If Annex I and E are included in the conference call, I like to see the actual time in the agenda when these items will be discussed so that people can best use their time in joining the particular time slot for each Annex. The proposal is as follows: 1. The upcoming conference call to be dedicated for H.323 Annex H. 2. Let both editors of H.323 Annex I and H.246 Annex E propose via emails whether any issues to addressed. 3. If annex I and E are included in the agenda of the upcoming conference call, I like to the time slots when these annexes will be discussed so that people can join the particular time slots of interest. Alternatively, separate conference calls can be arranged for annexes I and E. 4. Are editors or any members of the mobility group sure what would be the scope of work (I guess that Annex E is stable for now - thanks to the editor) for those annexes? Paul: Would you please clarify what specific area that we need to discuss for the next conference call for H.323 Annex H? My guess is that we may start with intra-zone communication first. I am planning to bring contribution(s) describing this for mobility management: Discovery, Registration, Location Updates, and Call Establishment. I would appreciate comments form all members. Best regards, Radhika R. Roy AT&T H.323 Ad Hoc Mobility Group

1 0

Re: Mob ad hoc group progress
by Guram Paul-LPG019 02 Apr '00

02 Apr '00

Radhika, Conf call is for Annex H only as before...nothing has changed...change can only take place when the group agrees. Please do not read into the email more than what it says. I was only trying to highlight, in a high level report, the plight of Annex I since nothing much has moved in it, and it is an Annex which together with Annex H covers the mobility aspects. As far as Annex E is concerned, the point was that the mapping was the work of one individual or one company, thus could have errors or omissions (more than likely)...again only highlighting to people to check out this mapping. Contributions for next conf call to be for All H.323 intra-network scenario for: Registration procedures, Gatekeeper discovery, Location update, Call establishment, Mid-Call scenarios (e.g. supplementary services, user interaction), Call release. Also contributions on any impacts on the already specified architecture in the light of the present work are welcome. Paul -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: 01 April 2000 00:00 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Mob ad hoc group progress Hi, Paul and Mobility Group: I like to see that it should be clarified via emails whether H.323 Annex I and H.246 Annex E will be a part of the conference call. My personal preference is not to discuss annexes I and E during the conference call although email discussions will be preferred. If Annex I and E are included in the conference call, I like to see the actual time in the agenda when these items will be discussed so that people can best use their time in joining the particular time slot for each Annex. The proposal is as follows: 1. The upcoming conference call to be dedicated for H.323 Annex H. 2. Let both editors of H.323 Annex I and H.246 Annex E propose via emails whether any issues to addressed. 3. If annex I and E are included in the agenda of the upcoming conference call, I like to the time slots when these annexes will be discussed so that people can join the particular time slots of interest. Alternatively, separate conference calls can be arranged for annexes I and E. 4. Are editors or any members of the mobility group sure what would be the scope of work (I guess that Annex E is stable for now - thanks to the editor) for those annexes? Paul: Would you please clarify what specific area that we need to discuss for the next conference call for H.323 Annex H? My guess is that we may start with intra-zone communication first. I am planning to bring contribution(s) describing this for mobility management: Discovery, Registration, Location Updates, and Call Establishment. I would appreciate comments form all members. Best regards, Radhika R. Roy AT&T H.323 Ad Hoc Mobility Group

1 0

[Robustness] telecon -- April 6 9AM EST USA
by Maureen Stillman 02 Apr '00

02 Apr '00

The next robustness teleconference will be held on Thursday, April 6 at 9AM EST USA. Please send me e-mail at maureen.stillman(a)nokia.com if you plan to attend (some have sent e-mail already). The number to call is: (613)688-2795 the passcode is 8689# You must enter the pound sign after the passcode. The agenda is: * Terry Anderson will provide H.225 and H.245 state machines for us to review. * Randy Stewart and Qiaobing Xie of Motorola will join us to discuss SCTP and DDP and answer questions. * Discuss the SDL for the robustness procedure produced by Sasha Ruditsky of Radvision (attached). This SDL is for the Geneva SG-16 document from the February 2000 meeting, document TD87 from WP2. SCTP (Simple Control Transmission Protocol) (http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-07.txt) DDP (Distributed Data protocol) http://www.ietf.org/internet-drafts/draft-xie-stewart-sigtran-ddp-00.txt -- maureen <<RobustnessSDL.ZIP>> Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 IP Voice Networks Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

3 2

Missing FastConnectRefused flag in PROGRESS message
by <Karl Klaghofer> 02 Apr '00

02 Apr '00

In the Geneva 2/2000 meeting, we introduced the fastConnectRefused flag into some H.225.0v3 (Imple Guide) and v4 messages. We forgot to put this new field into PROGRESS as well (especially required for GWY interworking). Otherwise, it is difficult to comply with the following statement: ".....fastConnectRefused - A called endpoint should return this element in any message up to and including the Connect message when establishing a call to indicate that it refuses the Fast Connect procedure. ....." Note: The original contribution D.459 from Orit proposed to add this flag to the H323-UU-PDU structure, which would have enabled the flag for PROGRESS as well as for any other message. I guess we changed this in order to only put the flag to the messages where it makes sense (which should be backwards messages) and missed the PROGRESS. I consider this an an error and propose that the editor should add the missing field to PROGRESS to the next updated draft of H.225.0v4 (I assume that no APC is required for Osaka for this ?). Is there a way to correct this also for H.323/H.225.0v3 ? Thanks and Regards, Karl ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN SIB NL D1 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)icn.siemens.de

2 1