- sg16-avd - lists.packetizer.com

None
by Robert Webber 18 Nov '98

18 Nov '98

Please be advised that services at standard.pictel.com will be inaccessible for some period of time on both 19 and 21 November. This outage is due to a change in our Internet connection, and the change is expected to increase available bandwidth to the ftp repositories and WWW pages here. The first outage will be tomorrow night, 11/19, starting at approximately 5:00pm EST. This outage should last for about an hour. The second outage will be this Saturday, 11/21, starting at 9:00am EST. This outage will last for between three and four hours. Bob Webber PictureTel Corporation

1 0

subscribe
by Carl Yang 18 Nov '98

18 Nov '98

Carl Yang carl(a)shoretel.com

1 0

Re: Usage of CallID in H.323v2 for rerouted (diverted, transferre d,.. .) calls
by Santo Wiryaman 17 Nov '98

17 Nov '98

Hi Karl, Chris: >From the very beginning there was Conference ID (CID) that was created to identify a "conference". There was also CRV which is used to associate call signalling. messages. However, since the RAS and H.225 CRV values are independent, a GK may not be able to associate the ARQ pair with the Setup message. The in version 2, the Call ID was created to associate the H.225.0 messages with the call. Karl is now proposing to add CallLegID to identify the leg of the call. It seems clear that as soon as we define a new ID to identify a particular thing, there is a need to identify yet another thing related to the thing. I am not saying that a new field called the CallLegID is a bad thing. However, perhaps we need to step back and think what is it that we are really trying to get a handle of. I propose that what we are dealing here is a call, a conference, and the connection legs to the call. A word can mean different things to different people, and the H.323 spec does not necessarily help either. My favorite definitions so far came from the ECTF CTI Encyclopedia Volume 3, p 10: Device - And endpoint Call - The association of one or more devices Connection - A device's representation in a given call Consider the example of device D1 in a call with device D2: D1 --------- C1 --------- D2 Call C1 associates devices D1 and D2. Call C1 consists of 2 connections: D1C1 and D2C2. H.450.2 (Call Transfer SS), for example, uses a similar notation. CT with consultaion figure 7/H.450.2 can be redrawn in ASCII art as: Before Service: A ----------- C1 ----------- B C (idle) Consultation: A ----h----- C1 -----h----- B ( A puts B on hold) A ----------- C2 ------------ C ( A makes a new call to C) Transfer A ----t----- C1 -----t----- B ( A transfers B to C) A ----t----- C2 -----t----- C After Service: A (idle) B ----------- C3 ----------- C The question is how do CID, CRV, CallID, CallLegID map to the above model. CID somewhat maps to the ID of the calls, e.g. C1, C2, C3. It breaks down, though, if an MCU calls out to A, B, C with the same CID. As far as the model goes, there are 3 calls: MCU ----------- C1 ----------- A MCU ----------- C2 ----------- B MCU ----------- C3 ----------- C As far as a device is concerned, the CRV is the ID for the connections. For a GK, however, the ID for the connections is (CRV plus the EndpointID). The ambiguity with CRV's is when an endpoint can make multiple calls. For example, A makes two simultaneous calls to B: 1. A sends ARQ to GK with CRV=1 2. A sends ARQ to GK with CRV=2 3. A sends Setup to GK with CRV= 17 4. A sends Setup to GK with CRV= 21 Since the CRV's of RAS and Q.931 are independent, the GK can not associate the Setup with the correct ARQ. Version 2 CallID was suppose to fix this since it associate the RAS and the Call Signalling for the same connection (i.e. connection leg). Section 7.5 of H.323v2 says that the CallID must be the same for the following call: A ----------- C1 ----------- B Specifically it says that the CallID of the AC1 connection must be the same as the BC1 connection and that in both connections, the RAS and Call Signalling messages CallID's must be the same. Karl is proposing that in the case of a rerouted call, as described in Fig 19/H.323, the second Setup uses the same CallID. I agree that this is fine. However, in the case of a call transfer as described above, during the Consultation phase when A makes a new call to C, the CallID for the AC2 connection leg shall be diferent than the AC1 leg, because by definition, this is a new call. Would you agree with that Karl? Otherwise, if the CallID of AC1 and AC2 are the same, then we'll make it impossible for the GK to match the RAS and CallSignalling messages once again. Or is this why you are proposing a new CallLeg field? Finally, I have a question on the After Service phase of the call transfer operation. At this phase we have a new call (C3) with CC3 and BC3 connections. If the SS-CT was done on the GK w/gk-routed model, the H.225 connections on CC3 and BC3 could remain connected during the whole procedure. At the end, though, we end up with a call (C3) and two different CallID's on CC3 (which was the same as AC2) and on BC3 (which was the same as AC1). This is permitted and should not cause any misoperations, correct? Should this be pointed out in an implementor's guide? A similar situation is true today with meet-me MCU's. In theory, all the calls in the same conference would use the same CID. However, in a meet-me MCU, the endpoints initiates the call each generating unique CID's. There are procedures to change CID's during a call, but I don't know if that happens in the field. Regards, Santo Wiryaman VideoServer Inc. > -----Original Message----- > From: Klaghofer Karl PN VS LP3 [SMTP:Karl.Klaghofer@VS.SIEMENS.DE] > Sent: Monday, November 16, 1998 8:34 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: AW: Usage of CallID in H.323v2 for rerouted (diverted, > transferre d,.. .) calls > > Chris, > > Thanks for your comment. > > CRV is unique just at one signalling link of a call (e.g. between EP A and > GK; and may be different between GK and EP2 of the same call) . > > Since CallID may be preserved when calls are redirected (incl. transfer, > forward,...), the CallID actually identifies the call scenario and not > exactly one call. I think this is fine. > > A CallLegID would be a new identifier that is somehow in between CallID > and > CRV by identifying exactly one call (or call attempt) between two > endpoints. > We might think about for H.225.0v3. > > Regards, > Karl > > > -----Ursprüngliche Nachricht----- > > Von: Chris Purvis [SMTP:CPurvis@MADGE.COM] > > Gesendet am: Montag, 16. November 1998 12:52 > > An: ITU-SG16(a)mailbag.cps.intel.com > > Betreff: Re: Usage of CallID in H.323v2 for rerouted (diverted, > > transferre d,.. .) calls > > > > Karl, > > > > I agree with your comments on CallID being preserved when calls are > > transferred. However... > > > > > > >As an alternative, we might add a new multilevel CallID (e.g. > > >to H.225.0 v3) > > >that consists of an identifier that indicates the "overal > > >call" and a second > > >identifier that indicates the call leg. > > > Isn't this the CRV, that's always been there? > > > Regards, > > 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

1 0

APC 1436 was uploaded
by Sasha Ruditsky 17 Nov '98

17 Nov '98

Dear Mr. Okubo, I have uploaded APC-1436 to the Incoming directory. Best regards. Sasha *********************************************** Alexander(Sasha) Ruditsky RADVision Ltd. 24 Raul Wallenberg St. Tel Aviv 69719 Israel Tel: +972-3-645-5220 Fax: +972-3-647-6669 Direct: +972-3-645-5273 sasha(a)radvision.rad.co.il ***********************************************

1 0

H.225 Status Enquiry CRV length
by Srinivasa Reddy 17 Nov '98

17 Nov '98

H.225 V2 & V3 "Section 7.3.13 Status Enquiry" says the call reference IE length is 3 bytes. I guess it should be 2 bytes. thanks, Srinivasa Beereddy, Trillium Digital Systems, Inc.

1 0

APC-1455
by Naomi Frid 16 Nov '98

16 Nov '98

> Dear Mr. Okubo, > > I have uploaded APC-1455 to the Incoming directory. > > Best regards. > > Naomi > -------------------------------------------- > Naomi Frid Ruppin > Gatekeeper Project Manager > RadVision > Tel. 972-3-7657505 > Fax. 972-3-6476669 > frid(a)radvision.rad.co.il > > >

1 0

Re: Mailing List Archive.
by Jim Toga 16 Nov '98

16 Nov '98

There are two places to get the archive from: When the list was hosted at Intel (about 5mos ago) it was archived to ftp://ftp.intel.com/pub/H.323/mailing-list/ After moving to the IMTC, it has taken a while to start the archives but they can be found at: http://www.imtc.org/mail/h323implementors/1998/ Regards, jimt. At 09:03 AM 11/13/98 +0900, you wrote: > >Please let me know the site address of this mailinig list archive. > >Thanks. > >------------------------------------------------------------------------- >for list subscription instructions, >send email to h323implementors-request(a)imtc.org with text "info" > ***************************************************** *** +1-503-264-8816(voice) Intel - Hillsboro, OR. *** *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** *****************************************************

1 0

IMTC Liaison
by Sebestyen Istvan ICN WN ES SP 4 16 Nov '98

16 Nov '98

Dear Mr. Okubo, unfortunately this time I can not be present at the Joint Rapp. Meeting due to collisions with other meetings. <<IMTC-lias>> However, please find attached a short Liason from IMTC in my capacity as IMTC BOD Member and SG16 Associated Rapp. I have promised to help Deepak Kamlani in organizing the February 1999 SG16 rapp. meeting that IMTC is planning to host. I have asked Bernard Hammer to present that paper at the ITU-T Sg16 rapp. meeting, who is going to attend at your meeting. Regards, Istvan Sebestyen -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN WN ES SP 4, Hofmannstr. 51 D-81359 Munich Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail: istvan.sebestyen(a)icn.siemens.de Intranet: http://www.pn.siemens.de/pngs/people/pngs9/ ---------------------------------------------------------------------------- ----------------

1 0

AW: Usage of CallID in H.323v2 for rerouted (diverted, transferre d,.. .) calls
by Klaghofer Karl PN VS LP3 16 Nov '98

16 Nov '98

Chris, Thanks for your comment. CRV is unique just at one signalling link of a call (e.g. between EP A and GK; and may be different between GK and EP2 of the same call) . Since CallID may be preserved when calls are redirected (incl. transfer, forward,...), the CallID actually identifies the call scenario and not exactly one call. I think this is fine. A CallLegID would be a new identifier that is somehow in between CallID and CRV by identifying exactly one call (or call attempt) between two endpoints. We might think about for H.225.0v3. Regards, Karl > -----Ursprüngliche Nachricht----- > Von: Chris Purvis [SMTP:CPurvis@MADGE.COM] > Gesendet am: Montag, 16. November 1998 12:52 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Re: Usage of CallID in H.323v2 for rerouted (diverted, > transferre d,.. .) calls > > Karl, > > I agree with your comments on CallID being preserved when calls are > transferred. However... > > > >As an alternative, we might add a new multilevel CallID (e.g. > >to H.225.0 v3) > >that consists of an identifier that indicates the "overal > >call" and a second > >identifier that indicates the call leg. > Isn't this the CRV, that's always been there? > Regards, > 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

1 0

Re: Usage of CallID in H.323v2 for rerouted (diverted, transferre d,.. .) calls
by Chris Purvis 16 Nov '98

16 Nov '98

Karl, I agree with your comments on CallID being preserved when calls are transferred. However... >As an alternative, we might add a new multilevel CallID (e.g. >to H.225.0 v3) >that consists of an identifier that indicates the "overal >call" and a second >identifier that indicates the call leg. Isn't this the CRV, that's always been there? Regards, 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

1 0