- sg16-avd - lists.packetizer.com

Re: H.323 Annex E
by Bell, Bob 25 Nov '98

25 Nov '98

I would second this proposal. The exchange of signalling transport requirements belongs in a CAPS type exchange. -----Original Message----- From: Yoav Medan [mailto:MEDAN@HAIFA.VNET.IBM.COM] Sent: Saturday, November 21, 1998 9:52 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Annex E Kishore, IMHO this is more than just an interesting approach. I can see a backward compatibility problem only when endpoints are trying to engage in a peer-to-peer call setup (no GK, thank you). But in a GK routed call setup, why not negotiate UDP or TCP as part of the initial caps exchange? This applies to both endpoint-GK and to GK-GK communications, as you cleverly pointed out. I think we ought to design Internet "Green" (i.e. friendly) protocols that do not flood the network with redundant information unnecessarily. Let's be clever about it rather than smart. Regards Yoav Medan IBM Research, Haifa Lab, Israel Kishore Ramisetty <kish(a)TRILLIUM.COM> on 20-11-98 09:57:50 PM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)MAILBAG.INTEL.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM cc: (bcc: Yoav Medan/IBMHAIFA) Subject: H.323 Annex E H.323 Annex E proposes using simultaneous (or a little later) TCP and UDP transport connections to provide seamless interoperability with non-Annex E devices. This results in inefficiencies because we now have to transmit two kinds of PDUs for the same call. (Q.931 headers are present for TCP transport and they are absent for UDP). This again has the unfortunate consequence of mandating higher layers to be aware of the transport because upper layers have to deal with duplicates arriving from TCP and UDP connections. (Section E.5.3 para 4 and 5) A simpler solution to this problem is, Annex E compliant end points should register with gatekeeper about their capability of supporting Annex E in RRQ message and gatekeeper propogates this in ACF messages. So, it is easy to determine apriori whether to attempt UDP/TCP connection to the destination end points (because non Annex E devices won't register anything with gatekeepers). This will also require some additions to GK-GK communication so that such kinds of profiles can be communicated across zones. This solution of course requires V3 GKs. If a V3 GK (or GK itself) is absent, then end points could have the option of trying simultaneous connections or simply falling back to TCP. This solution would make sure that going forward to V3 we can get rid of this simultaneous connection establishment procedures. I would like some comments from the group. Thanks, -Kishore. ------------------------------------------------------------------ This message was spam-checked by an evaluation copy of MailShield. See http://www.mailshield.com for more information.

1 0

Rev..3 RE: [wg5-3: 2134] q11h17/apc1457 rev. 2
by Yoshihiro Kikuchi 25 Nov '98

25 Nov '98

Dear Q.11-15 experts, Attached find please the rev.3 of H.245 codepoints for MPEG-4 visual (q11h17/apc1457). The change from rev.2 is only on the default value of the drawingOrder as in the Q.11 meeting report. In the determination version (and in rev.2), the default value of the drawingOrder was 0. It is equal to the minimum value of the drawingOrder. It makes a limitation that a logical channel cannot has the smaller drawingOrder value than that of the logical channel formally opened without indicating drawingOrder. This means that a visual object cannot drawn Behind the visual object associated with the formally opened logical channel with default drawingOrder. I changed the default value to 32768, which is the middle of maximum and minimum values. Please note that the format of rev.3 is quit changed form rev.2 as the delta from H.245 ver.4, but the contents should be the same expect for the above change. If you have any comment on it, please send a message until the end of this week. I will make changes with reflecting all comments, and will send it to the H.245 editor (Mr. Mike Nilsson) next week. Best regards, Yoshihiro -----Original Message----- From: Yoshihiro Kikuchi <kiku(a)eel.rdc.toshiba.co.jp> To: itu-adv-video(a)mack.iterated.com <itu-adv-video(a)mack.iterated.com>; sg16.lbc(a)research.kpn.com <sg16.lbc(a)research.kpn.com> Cc: Yoshihiro Kikuchi <kiku(a)eel.rdc.toshiba.co.jp> Date: Sunday, November 22, 1998 6:47 PM Subject: [wg5-3: 2134] q11h17/apc1457 rev. 2 >Dear Gary, Mike and Q.11-15 experts, > >The attached mail is the one I tried to send last week during the Torino >meeting but not accomplished by a network trouble. I'm sending this >again. I'm also attaching the 2nd. revision of q11h17/apc1457 which is >the >last revision reviewed in the Torino meeting. > >As in the Q.11 meeting report, I should make another revision on the >default value of the drawingOrder. I will send the revised document >soon. > >Best regards, >Yoshihiro > >---- > Yoshihiro Kikuchi > E-mail: kiku(a)eel.rdc.toshiba.co.jp >Research and Development Center TEL: +81 +44 549 2151 >Toshiba Corp. FAX: +81 +44 520 1308 > > >

1 0

FW: Proposed IETF Working Group: MEdia GAteway COntrol (megaco)
by Tom-PT Taylor 24 Nov '98

24 Nov '98

This message has been cross-posted to the Bellcore SGCP list, the ITU SG16 AVC list, and the TIPHON list. All follow-ups to navdec(a)BayNetworks.COM, please. To join the navdec list (probably soon to be renamed megaco), send a message to majordomo(a)baynetworks.com with "subscribe navdec" (no quotes) in the body. At the bottom of this message is the device control working group charter as it currently stands. We can tweak it a bit in the December meeting. I am still working up the agenda and document list for that meeting, which will be on Friday morning, Dec. 11. In the meantime, I would like consideration given to the following: 1. What is the minimum we can put into a first protocol draft? I don't want us to drag this out for two years before we get our first standards-track RFC. Let me put this on the table: the core functionality is connection making and media stream manipulation. Event detection, insertion, and scripting are follow-up items. We might spend some of our time considering what kinds of connections and what kinds of media stream transformations the first protocol RFC should support. If people want to work in parallel on RFCs for specific applications, that's fine. 2. Scott appointed me partly because of my strong interest in trying to keep ETSI TIPHON, ITU-T Study Group 16, and our own working group working together. The other groups are particularly interested in trunking gateways in an H.323 context. SG 16 is interested in multimedia, not just audio. I would like suggestions on how we and they can organize our work to minimize conflict and maximize commonality. 3. Nancy Greene has done a lot of work on architecture and requirements in the past. I propose that she be Document Editor for the architecture and requirements RFC on our work list. More later. Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 765-4167 > -----Original Message----- > From: Steve Coya [SMTP:scoya@ns.cnri.reston.va.us] > Sent: Monday, November 23, 1998 12:05 PM > To: IETF-Announce > Cc: new-work(a)ietf.org > Subject: Proposed IETF Working Group: MEdia GAteway COntrol (megaco) > > A new IETF working group has been proposed in the Transport Area. > The IESG has not made any determination as yet. > > The following Description was submitted, and is provided for > informational purposes: > > > The working group will develop an informational RFC detailing the > architecture and requirements for controlling Media Gateways from > external control elements such as a Media Gateway Controller. A media > gateway is a network element that provides conversion between the > information carried on telephone circuits and data packets carried over > the Internet or over other IP networks. This work will be done in > consultation with other IETF working groups looking at similar issues. > The working group will also ensure that good information conduits exist > with groups in other standards groups with expertise in the relevant > PSTN technology. Other IETF working groups include PINT, IPTEL and > SIGTRAN. In addition the working group will ensure that reasonable > liaisons exist with similar activities in other standards bodies such as > the ITU-T and ETSI. > > This working group will also define standards track protocol(s) for > controlling media gateways from external control elements such as a > media gateway controller. > > Examples of media gateways are: > > * Trunking gateways that interface between the telephone > network and a Voice over IP network. Such gateways > typically manage a large number of digital virtual circuits. > * Access gateways that provide traditional analog or Primary > Rate (PRI) line interfaces to a Voice over IP network. > * Network Access Servers that can attach a "modem" to a > telephone circuit and provide data access to the > Internet. > > This working group assumes a separation of call control so the call > control "intelligence" is outside the media gateways and handled by a > media gateway controller. This group will NOT work on media gateway > controller to media gateway controller protocols, nor on media gateway > to media gateway protocols. > > Planned output: > > * Architecture & Requirements informational RFC > > * Standards Track RFC for the protocol between a media > gateway controller and a media gateway. > > * Standards Track RFC for the MG and MC MIBs > > * Informational RFC for application programming interface > for the MC to MG protocol

1 0

Re: H.323 Annex E
by Kaynam Hedayat 24 Nov '98

24 Nov '98

Kishore, It was decided at the last meeting that Q.931 headers will be present for UDP call signaling. The absence of Q.931 headers was an oversight by the members of the group. Kaynam Kishore Ramisetty <kish(a)TRILLIUM.COM> on 11/20/98 02:57:50 PM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Kaynam Hedayat/PicTel) Subject: H.323 Annex E H.323 Annex E proposes using simultaneous (or a little later) TCP and UDP transport connections to provide seamless interoperability with non-Annex E devices. This results in inefficiencies because we now have to transmit two kinds of PDUs for the same call. (Q.931 headers are present for TCP transport and they are absent for UDP). This again has the unfortunate consequence of mandating higher layers to be aware of the transport because upper layers have to deal with duplicates arriving from TCP and UDP connections. (Section E.5.3 para 4 and 5) A simpler solution to this problem is, Annex E compliant end points should register with gatekeeper about their capability of supporting Annex E in RRQ message and gatekeeper propogates this in ACF messages. So, it is easy to determine apriori whether to attempt UDP/TCP connection to the destination end points (because non Annex E devices won't register anything with gatekeepers). This will also require some additions to GK-GK communication so that such kinds of profiles can be communicated across zones. This solution of course requires V3 GKs. If a V3 GK (or GK itself) is absent, then end points could have the option of trying simultaneous connections or simply falling back to TCP. This solution would make sure that going forward to V3 we can get rid of this simultaneous connection establishment procedures. I would like some comments from the group. Thanks, -Kishore.

1 0

Torino meeting report
by Sakae OKUBO 22 Nov '98

22 Nov '98

Dear Torino meeting participants, The outcome of the closing session last Friday has been placed at the /incoming directory: ftp://standard.pictel.com/avc-site/Incoming/ or http://standard.pictel.com/ftp/avc-site/Incoming TD-12b.doc Genral TD-18b.doc Q.12 TD-19a.doc Q.13 TD-07a.doc Q.14 TD-15a.doc LS to SG15 TD-20a.doc LS to MPEG re MPEG-4 TD-22a.doc LS to MPEG re MPEG-2 These and other materials will later be integrated into APC-1485. PS - Please note that our mailserver(a)giti.or.jp will temporarily be shut down till around 1 AM (GMT) on Tuesday. Please use okubo(a)mxz.meshnet.or.jp if there is any message to me during that time. 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: Gateway Decomposition Requirements
by Dale L. Skran 21 Nov '98

21 Nov '98

At 07:54 PM 11/19/98 -0500, Tom-PT Taylor wrote: >I have been told that APC-1466 states enough requirements for the device >control interface A, but that we should have requirements for the signalling It would be more accurate to say that it is a very good start. As mentioned at the meeting, and as discussed below, the terms of reference are not fully reflected in the requirements. >interfaces B, C, and D before committing ourselves to protocol design. I >just don't have the same feeling for detailed requirements in those areas >that I have for interface A. I can only think of two requirements: these >interfaces must >- pass all the signalling content offered to them Not sure what you mean. >- do it quickly and reliably. Of course. I suggest looking at what IPDC does, but this is what comes to mind: B Interface: 1)It must be possible to request that the MGW do H.323 signaling to a specified IP address, which might, for example, be a composed GW. Of course, this is an optional feature. 2)It must be possible to do this call by call, ie. for one call request 323 signaling and for the next not request it. 3)Point 2 strongly suggests that the protocol for B and A should be the same, for example, as in IPDC. C Interface: 1)It must be possible to bring call signaling up to the controller so that signaling can be terminated there (optionally). This suggests a need to map different types of call signaling into a single protocol. Q.931 is an obvious solution. See Ascend's "Reliable Gateway Signaling Protocol" for an example. 2)It must be possible to terminate/generate the Q.931, etc. call signaling on the gateway (optionally). This is equivalent to having the MGW signal 323 on the packet size. This allows a call from a MGW with IMT trunks to talk to a MGW with PRI/T1 trunks under SS7 control. 3)(1) is a kind of tunneling for Q.931, so it is not so clear that this should be the same protcol as A/B. 4)(2) seems like it should be a part of the A/B protcol. X requirements(common requirements on A/B/C): 1)A/B/C signaling must all travel over the same data network to the MGW. 2)It must be possible to use both UDP and TCP 3)Either the protocol is Message/ACK or we must use a reliable UDP like Annex E. 4)Given the similiarity of B/C to A, all should use a similar message format, the same ports, etc. to ease implementation. Note that both B/C parts are probably optional, but they are part of the same protocol as A. The only exception is the case where you want to put SCN call signaling(Q.931, FAS SS7) in the controller, and you need to tunnel it up. This stuff might be tunneled through the A/B/C protocol, or it might be a separate protocol/port, i.e. Q.931 on Annex E with a different port. 5)Part of the A/B/C message set must include an MGW cap set so the controller knows what to expect As noted at the meeting, you need to reflect the terms of reference in the A requirements. A couple of obvious ones: A Interface 1)Must include video/data (i.e. consider the possibility of incoming H.320/H.324 calls). 2)Must not duplicate H.323 functions, eg. cap exchange, conference management, etc. 3)Must be elemental. This goes along with (2). cap exchange is not an elemental function. 4)Must be suitable for connecting an MC (MultiPoint Controller) to an MP (Media Processer) as defined in H.323. This implies a need for elemental conferencing primatives, but broken out by media stream, ie. data MP, voice MP, video MP. I'm sure there is more that could be added by a careful review of the terms of reference. Dale Skran Rapporteur, Q13 WP2 SG16 ITU-T > >Can anyone get us down to another level of detail? > >Tom Taylor >E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) >Tel.: +1 613 765 4167 (internally 395-4167) >FAX: +1 613 763 7236 (internally 393-7236) >

1 0

Re: H.323 Annex E
by Yoav Medan 21 Nov '98

21 Nov '98

Kishore, IMHO this is more than just an interesting approach. I can see a backward compatibility problem only when endpoints are trying to engage in a peer-to-peer call setup (no GK, thank you). But in a GK routed call setup, why not negotiate UDP or TCP as part of the initial caps exchange? This applies to both endpoint-GK and to GK-GK communications, as you cleverly pointed out. I think we ought to design Internet "Green" (i.e. friendly) protocols that do not flood the network with redundant information unnecessarily. Let's be clever about it rather than smart. Regards Yoav Medan IBM Research, Haifa Lab, Israel Kishore Ramisetty <kish(a)TRILLIUM.COM> on 20-11-98 09:57:50 PM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)MAILBAG.INTEL.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM cc: (bcc: Yoav Medan/IBMHAIFA) Subject: H.323 Annex E H.323 Annex E proposes using simultaneous (or a little later) TCP and UDP transport connections to provide seamless interoperability with non-Annex E devices. This results in inefficiencies because we now have to transmit two kinds of PDUs for the same call. (Q.931 headers are present for TCP transport and they are absent for UDP). This again has the unfortunate consequence of mandating higher layers to be aware of the transport because upper layers have to deal with duplicates arriving from TCP and UDP connections. (Section E.5.3 para 4 and 5) A simpler solution to this problem is, Annex E compliant end points should register with gatekeeper about their capability of supporting Annex E in RRQ message and gatekeeper propogates this in ACF messages. So, it is easy to determine apriori whether to attempt UDP/TCP connection to the destination end points (because non Annex E devices won't register anything with gatekeepers). This will also require some additions to GK-GK communication so that such kinds of profiles can be communicated across zones. This solution of course requires V3 GKs. If a V3 GK (or GK itself) is absent, then end points could have the option of trying simultaneous connections or simply falling back to TCP. This solution would make sure that going forward to V3 we can get rid of this simultaneous connection establishment procedures. I would like some comments from the group. Thanks, -Kishore.

1 0

H.323 Annex E
by Kishore Ramisetty 20 Nov '98

20 Nov '98

H.323 Annex E proposes using simultaneous (or a little later) TCP and UDP transport connections to provide seamless interoperability with non-Annex E devices. This results in inefficiencies because we now have to transmit two kinds of PDUs for the same call. (Q.931 headers are present for TCP transport and they are absent for UDP). This again has the unfortunate consequence of mandating higher layers to be aware of the transport because upper layers have to deal with duplicates arriving from TCP and UDP connections. (Section E.5.3 para 4 and 5) A simpler solution to this problem is, Annex E compliant end points should register with gatekeeper about their capability of supporting Annex E in RRQ message and gatekeeper propogates this in ACF messages. So, it is easy to determine apriori whether to attempt UDP/TCP connection to the destination end points (because non Annex E devices won't register anything with gatekeepers). This will also require some additions to GK-GK communication so that such kinds of profiles can be communicated across zones. This solution of course requires V3 GKs. If a V3 GK (or GK itself) is absent, then end points could have the option of trying simultaneous connections or simply falling back to TCP. This solution would make sure that going forward to V3 we can get rid of this simultaneous connection establishment procedures. I would like some comments from the group. Thanks, -Kishore.

1 0

signoff itu-g16
by Staffan Olsén 20 Nov '98

20 Nov '98

signoff itu-g16

1 0

Gateway Decomposition Requirements
by Tom-PT Taylor 19 Nov '98

19 Nov '98

I have been told that APC-1466 states enough requirements for the device control interface A, but that we should have requirements for the signalling interfaces B, C, and D before committing ourselves to protocol design. I just don't have the same feeling for detailed requirements in those areas that I have for interface A. I can only think of two requirements: these interfaces must - pass all the signalling content offered to them - do it quickly and reliably. Can anyone get us down to another level of detail? Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 765 4167 (internally 395-4167) FAX: +1 613 763 7236 (internally 393-7236)

1 0

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 17 Nov '98

17 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 16 Nov '98

16 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

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

16 Nov '98

H.225.0v2 CallID identifies the call with which the message is associated (all RAS and Call Signalling messages related to the same call). Is it allowed that the CallID value for a rerouted call (second Setup) may be the same as the CallID value used in the first call Setup message ? According to H.323v2 clause 7.5 second last sentence it is even recommended (e.g. reference to Fig. 19/H.323 where all messages shown in the figure shall use the same CallID) ? However, I would like this to be confirmed, since somebody might interpret this as contradicting with the definition of the call identifier. If we can confirm this, then I propose that such a usage of the CallID is also possible for H.450.x related call redirections (e.g. Call Diversion, Call Transfer). This would allow the calls (e.g. first call setup and diverted call) to be associated for applications. 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. Thanks, Karl ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL IP Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)vs.siemens.de

1 0

APC-1456.
by Yair Miranda 15 Nov '98

15 Nov '98

Dear Mr. Okubo, I have uploaded an updated version of APC-1456 to the Incoming directory. Best regards. Yair Miranda yair(a)radvision.rad.co.il Tel : +972-3-6455271 Fax : +972-3-6476669 Video : +972-3-6489010 http://www.radvision.com

1 0

Re: APC No for Contribution to Q14/SG16
by Sakae OKUBO 14 Nov '98

14 Nov '98

Dear Mike Buckley, Your request is very late. Let me consult with the meeting how to handle your contribution (APC numbered document or TD or other way). In the meantime please upload your document at the /Incoming directory with an appropriate file name and announce your uploading on the reflector for the interest of the group 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 *********************************************************** At 23:26 +0900 98/11/13, Mike Buckley wrote: > Mr Okubo, > > We would like to submit a contribution to next weeks Q11, Q12, Q13, Q14 > meeting in Turin. I realise that the deadline for submissions is now past, >and I > apologise for the lateness. The contribution relates to the Media Gateway > Control Protocol and will probably contain a number of companies names > including Lucent Technologies. > > I would be very grateful if you could allocate an APC number. > > Many Thanks, > > Mike Buckley > Lucent Technologies > +44-145-877718 (T) > +44-145-877721 (F) > mikebuckley(a)lucent.com

1 0

contribution to the ITU-T SG16 Q12-14/16 on H323/IN/TINA
by Martine.Lapierre＠ALCATEL.FR 14 Nov '98

14 Nov '98

Dear Sakae OKUBO, As Ameneh explained to you, we would like to discuss the attached contribution (itu.doc) at the next SG16 Q12-14/16 meeting. We realized today that is was not registered in your list, and feel very sorry for disturbing your preparation. We sincerly apologize for this very late presentation and will provide the copies on site. I am probably totally wrong with the contribution numbering (I understood that it could be 1444, but I am not sure if we got any confirmation). Can I insit on the fact that it is just a proposal for information and discussion, not more. We would be very happy to get some feed back on it. Gerald Roullet that will attend your 4 days meeting, could present quickly the concepts on the diagram attached (itu.ppt). Very best regards Martine Lapierre ---------------------------------------------------------------------- Vice President Products and Marketing Alcatel Switching Systems Division phone + 33 1 3077 0032 e-mail martine.lapierre(a)alcatel.com ----------------------------------------------------------------------

2 1

Uploaded apc -1448
by Jim Toga 13 Nov '98

13 Nov '98

All, I have uploaded APC-1448 to the 'Incoming' directory on the avc-site Regards, jimt. ***************************************************** *** +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