- sg16-avd - lists.packetizer.com

Uploaded APC-1514 and APC-1515
by Callaghan, Robert 08 Feb '99

08 Feb '99

Corrected version of APC-1514 and APC-1515 have been uploaded as APC-1514b.zip and APC-1515b.zip. APC-1514a.zip failed during upload and should be deleted. 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

APC-1491
by Maenpaa Henri (Nokia/NWBC) 08 Feb '99

08 Feb '99

I have uploaded APC-1491.doc "GSM AUDIO PACKETIZATION IN H.323" into the incoming directory of avc-site. -- Henri Mäenpää, Nokia Wireless Business Communications henri.maenpaa(a)nokia.com

1 0

Implementers Guide- pls review
by Derks, Frank 08 Feb '99

08 Feb '99

Hi Jim, I just had a quick look at the text that you included for the description of TPKT. I would like to suggest the following text as a replacement: "A TPKT is a packet format as defined in IETF RFC1006. It is used to delimit individual messages (PDUs) within the TCP stream, which itself provides a continuous stream of octets without explicit boundaries. A TPKT consists of a one octet version number field, followed by a one octet reserved field, followed by a two octet length field, followed by the actual data. The version number field shall contain the value "3", the reserved field shall contain the value "0". The length field shall contain the length of the entire packet including the version number, the reserved and the length fields as a 16-bit big-endian word." 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 | ----------------------------------------------------- <<Frank Derks (E-mail).vcf>>

1 0

APC-1534
by Christian Groves 07 Feb '99

07 Feb '99

Dear Mr. Okubo, Please find attached contribution: APC-1534 - Generic Mechanism for SS7 Transport in H323 based networks (APC-1534.doc) Regards, Christian Groves

1 0

Documents for the Monterey meeting
by Sakae OKUBO 07 Feb '99

07 Feb '99

Dear Q.12-14/16 experts, Attached please find the current list of input documents for the next week Rapporteur meeting in Monterey. This is very close to final unless I have lost your requests. 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 *********************************************************** Documents for the Q.12-14/16 Monterey meeting (15-18 February 1999) ---------------------------------------------------------------------- APC- Source Title ---------------------------------------------------------------------- 1486 SG11 Q.20/11 DSS2 protocol provision of adaptive timing recovery used for transmitting clock 1487 SG9 Q.31/9 Progress report on Webcasting 1488 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q 11, 12, 13 and 14 on MPEG-4 Systems on H.32X 1489 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q11, 12, 13, and 14 on MPEG-4 Audio on H.32X 1490 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q12 on Common Text Recommendations 1491 Nokia GSM in H.323 1492 AT&T H.323 Differentiated Services and Their Protocol Architectures 1493 AT&T Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" 1494 AT&T TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 1495 Editor (G Kajos) Changes to H.341 Annexes 1496 Editors (D Gurle, G Kimchi) Editorial changes to H.323 Annex E text 1497 TIPHON Requirements for a Protocol at Reference Point N: Media Gateway Controller to Media Gateway 1498 VTEL H.323 QoS (Quality of Service) in the Policy Based Network 1499 VTEL Slides Presentation for H.323 QoS (Quality of Service) in the Policy Based Network 1500 Editor (B Hill) Gateway Control Protocol H.GCP 1501 Editor (J Ott) H.323 Annex F White Paper (for a final review) 1502 Teles OpenLogicalChannel structures for Annex F 1503 PTS Sweden H.323 Annex "Text", Text Conversation Capable SUD 1504 PTS Sweden Text conversation in H.323 1505 Editor (M Korpi) Draft H.450.8 - Conference out of Consultation Supplementary Service for H.323 1506 Siemens CallIdentifier and ConferenceIdentifier value setting in H.450.2and H.450.3 1507 PictureTel Fixing inconsistency between Annex E and H.283 and Annex G 1508 Chairman WP2/13 Status report on AAL2 signalling and switching 1509 Q12 Rapporteur Draft H.321 Implementors Guide 1510 Madge Networks cryptoTokens in H.225.0 Annex G 1511 Madge Networks Master/slave determination for inter-zone calls in H.323 environments where gatekeepers are routing H.245 signalling 1512 Madge Networks Submissions for the H.323 implementer's guide 1513 Ascend Extension Proposals for Gateway MIB of H.341 revison 2 1514 Siemens Comparison of Tunneling and Interworking 1515 Siemens H.450.x - Tunneling of External protocols 1516 ATMF "H.323 Over ATM Media Transport" specification 1517 ATMF H.245 codepoint for transport of compressed RTP over AAL5 1518 ATMF GIT for the transporting the portNumber 1519 Korea Telecom Dynamic Multicast Tree Building Procedure 1520 Nortel Networks Corrections to H.323 and H.245 regarding fast start procedures 1521 Bosch, Ericsson, NTT DoCoMo Request to support full MPEG-4 functionality in H.324 terminals 1522 Mitel Additions to the H.323 Implementors Guide 1523 Mitel Comments on H.323 Annex F 1524 BT, Mitel H.245 Pre-Opened Channels 1525 Editor (G Fruendlich) H.225.0 Annex G white draft from the editor 1526 Editor (G Fruendlich) H.225.0 Annex G Clarifications and Improvements 1527 Lucent Caller ID Support 1528 Lucent Name Identification Features 1529 Lucent Media Device Control Protocol (MDCP) 1530 Lucent Support for Wireless Coders in H.323 1531 Lucent ISUP-Based Signaling for H.225 Control 1532 TAO Consideration of MPEG-2 stream packetization 1533 Editor (J Toga) Proposed text for H.323 Implementers Guide 1534 LM Ericsson Generic Mechanism for SS7 Transport in H323 based networks 1535 Siemens Need for Services and Procedures for Charging, Accounting and Advice of Charge in H.323 1536 NEC Layered coding and bitrate/bandwidth scalability for speech/audio coding 1537 Nortel Networks Requirements Across the B, C, and D Interfaces of a Decomposed Gateway 1538 Nortel Networks Requirements For Tunneling of ISUP and Other Protocols 1539 for reuse 1540 LM Ericsson Adding pricing information to terminals in call 1541 LM Ericsson Use of GRQ for inter-gatekeeper discovery 1542 LM Ericsson Extending the pregranted ARQ 1543 LM Ericsson Indication of H.323 Annex E capabilities to gatekeeper 1544 Editor (G Freundlich) Draft H.225.0 V3 1545 Lucent Internal Connection Model for Generic Media Gateways 1546 Ascend, ITXC, Lucent, OzEmail Interline, Siemens, VocalTec Comments on H.225.0 Annex G 1547 Chairman, IETF Megaco Working Group Media Gateway Control Protocol Architecture and Requirements 1548 PictureTel Suggested changes to H.341(H.MediaMIB) 1549 PictureTel, VideoServer Correction of problems related to MCV in H.230 and H.243 1550 Bellcore Media Gateway Control Protocol (MGCP) 1551 Nokia Comments to Annex G 1552 VocalTec Token OID for Crypto Tokens ----------------------------------------------------------------------

1 0

Re: Contribution For Monterry Meeting
by Sakae OKUBO 07 Feb '99

07 Feb '99

Dear Lior Moscovici, APC-1552 has been allocated to your VocalTec contribution "Token OID for Crypto Tokens." 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

APC-1520
by Francois Audet 06 Feb '99

06 Feb '99

I have uploaded APC-1520R1.zip in the incoming directory. Please disregard APC-1520.doc and APC-1520.zip: they are empty files. Regards, ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com

1 0

Allocation of APC document numbers
by Sakae OKUBO 06 Feb '99

06 Feb '99

Dear Espen Skjaeran, Glen Freundlich, Patrick Luthi, Tom Taylor, Hong Liu, Senthil Sengodan, In response to your requests, APC numbers have been collectively allocated to your contributions as attached. This list is close to final. I hope I caught all the requests. Please advise me if your contribution is not included there. 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 *********************************************************** ---------------------------------------------------------------------- APC- Source Title ---------------------------------------------------------------------- 1486 SG11 Q.20/11 DSS2 protocol provision of adaptive timing recovery used for transmitting clock 1487 SG9 Q.31/9 Progress report on Webcasting 1488 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q 11, 12, 13 and 14 on MPEG-4 Systems on H.32X 1489 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q11, 12, 13, and 14 on MPEG-4 Audio on H.32X 1490 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q12 on Common Text Recommendations 1491 Nokia GSM in H.323 1492 AT&T H.323 Differentiated Services and Their Protocol Architectures 1493 AT&T Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" 1494 AT&T TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 1495 Editor (G Kajos) Changes to H.341 Annexes 1496 Editors (D Gurle, G Kimchi) Editorial changes to H.323 Annex E text 1497 TIPHON Requirements for a Protocol at Reference Point N: Media Gateway Controller to Media Gateway 1498 VTEL H.323 QoS (Quality of Service) in the Policy Based Network 1499 VTEL Slides Presentation for H.323 QoS (Quality of Service) in the Policy Based Network 1500 Editor (B Hill) Gateway Control Protocol H.GCP 1501 Editor (J Ott) H.323 Annex F White Paper (for a final review) 1502 Teles OpenLogicalChannel structures for Annex F 1503 PTS Sweden H.323 Annex "Text", Text Conversation Capable SUD 1504 PTS Sweden Text conversation in H.323 1505 Editor (M Korpi) Draft H.450.8 - Conference out of Consultation Supplementary Service for H.323 1506 Siemens CallIdentifier and ConferenceIdentifier value setting in H.450.2and H.450.3 1507 PictureTel Fixing inconsistency between Annex E and H.283 and Annex G 1508 Chairman WP2/13 Status report on AAL2 signalling and switching 1509 Q12 Rapporteur Draft H.321 Implementors Guide 1510 Madge Networks cryptoTokens in H.225.0 Annex G 1511 Madge Networks Master/slave determination for inter-zone calls in H.323 environments where gatekeepers are routing H.245 signalling 1512 Madge Networks Submissions for the H.323 implementer's guide 1513 Ascend Extension Proposals for Gateway MIB of H.341 revison 2 1514 Siemens Comparison of Tunneling and Interworking 1515 Siemens H.450.x - Tunneling of External protocols 1516 ATMF "H.323 Over ATM Media Transport" specification 1517 ATMF H.245 codepoint for transport of compressed RTP over AAL5 1518 ATMF GIT for the transporting the portNumber 1519 Korea Telecom Dynamic Multicast Tree Building Procedure 1520 Nortel Networks Corrections to H.323 and H.245 regarding fast start procedures 1521 Bosch, Ericsson, NTT DoCoMo Request to support full MPEG-4 functionality in H.324 terminals 1522 Mitel Additions to the H.323 Implementors Guide 1523 Mitel Comments on H.323 Annex F 1524 BT, Mitel H.245 Pre-Opened Channels 1525 Editor (G Fruendlich) H.225.0 Annex G white draft from the editor 1526 Editor (G Fruendlich) H.225.0 Annex G Clarifications and Improvements 1527 Lucent Caller ID Support 1528 Lucent Name Identification Features 1529 Lucent Media Device Control Protocol (MDCP) 1530 Lucent Support for Wireless Coders in H.323 1531 Lucent ISUP-Based Signaling for H.225 Control 1532 TAO Consideration of MPEG-2 stream packetization 1533 Editor (J Toga) Proposed text for H.323 Implementers Guide 1534 LM Ericsson Generic Mechanism for SS7 Transport in H323 based networks 1535 Siemens Need for Services and Procedures for Charging, Accounting and Advice of Charge in H.323 1536 NEC Layered coding and bitrate/bandwidth scalability for speech/audio coding 1537 Nortel Networks Requirements Across the B, C, and D Interfaces of a Decomposed Gateway 1538 Nortel Networks Requirements For Tunneling of ISUP and Other Protocols 1539 Nortel Networks Proposed Changes to H.225.0v3 to Clarify TPKT References 1540 LM Ericsson Adding pricing information to terminals in call 1541 LM Ericsson Use of GRQ for inter-gatekeeper discovery 1542 LM Ericsson Extending the pregranted ARQ 1543 LM Ericsson Indication of H.323 Annex E capabilities to gatekeeper 1544 Editor (G Freundlich) Draft H.225.0 V3 1545 Lucent Internal Connection Model for Generic Media Gateways 1546 Ascend, ITXC, Lucent, OzEmail Interline, Siemens, VocalTec Comments on H.225.0 Annex G 1547 IETF Working Group Megaco Media Gateway Control Protocol Architecture and Requirements 1548 PictureTel Suggested changes to H.341(H.MediaMIB) 1549 PictureTel, VideoServer Correction of problems related to MCV in H.230 and H.243 1550 Bellcore Media Gateway Control Protocol (MGCP) 1551 Nokia Comments to Annex G ----------------------------------------------------------------------

1 0

APC-1498 and APC-1499
by Joon Maeng 05 Feb '99

05 Feb '99

The documents APC-1498 and APC-1499 have been uploaded to the directory, ftp://standards.pictel.com/avc-site/incoming. Regards, Joon Maeng VTEL Corp.

1 0

Implementers Guide- pls review
by Jim Toga 05 Feb '99

05 Feb '99

All, Attached is the additions to the Implementers Guide so far... I know that there are a number of APCs related to entries contained in this document. I would like to have any relevent text _in_ the document by next week. The goal is to have _no_ editing or changes (:-)) to this text during the meeting- simply review it and ratify it. I would ask the following of interested parties: If you have text that relates to one of the changes already in the document and you do not agree with the current form - send to me directly the requested changes (exactly as you want them entered!) and I will (most likely) correct the document. If you have text that is _not_currently in the document and you feel as though it _really_ is editorial - send to me directly the requested changes (exactly as you want them entered!) and I will (most likely) correct the document. If you violently _disagree_ with what you see in the document, do not respond to me - this should be left for open discussion during the meeting. You have until close of business (US west coast) 2/8. The one issue I did _not_ include because I could navigate to a conclusive answer, was the issue with reslolving multiple aliases in an ARQ message. Best 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

Question
by Juan C Uribe G 05 Feb '99

05 Feb '99

Hi, Is there any organization that test an application that claims to be H323 compatible? For example: NetMeeting is sending me a Release complete message without the Cause IE or the ReleaseCompleteReason wich I believe is ruled out in H225 section 7.3.10 Thanks, Juan C Uribe G

3 2

Re: APC Numbers Requested
by Sakae OKUBO 05 Feb '99

05 Feb '99

Dear Mr. Taylor, APC-1537, 1538, 1539 have been allocated to your three contributions as attached. 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 *********************************************************** ---------------------------------------------------------------------- APC- Source Title ---------------------------------------------------------------------- 1486 SG11 Q.20/11 DSS2 protocol provision of adaptive timing recovery used for transmitting clock 1487 SG9 Q.31/9 Progress report on Webcasting 1488 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q 11, 12, 13 and 14 on MPEG-4 Systems on H.32X 1489 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q11, 12, 13, and 14 on MPEG-4 Audio on H.32X 1490 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q12 on Common Text Recommendations 1491 Nokia GSM in H.323 1492 AT&T H.323 Differentiated Services and Their Protocol Architectures 1493 AT&T Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" 1494 AT&T TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 1495 Editor (G Kajos) Changes to H.341 Annexes 1496 Editors (D Gurle, G Kimchi) Editorial changes to H.323 Annex E text 1497 TIPHON Requirements for a Protocol at Reference Point N: Media Gateway Controller to Media Gateway 1498 VTEL H.323 QoS (Quality of Service) in the Policy Based Network 1499 VTEL Slides Presentation for H.323 QoS (Quality of Service) in the Policy Based Network 1500 Editor (B Hill) Gateway Control Protocol H.GCP 1501 Editor (J Ott) H.323 Annex F White Paper (for a final review) 1502 Teles OpenLogicalChannel structures for Annex F 1503 PTS Sweden H.323 Annex "Text", Text Conversation Capable SUD 1504 PTS Sweden Text conversation in H.323 1505 Editor (M Korpi) Draft H.450.8 - Conference out of Consultation Supplementary Service for H.323 1506 Siemens CallIdentifier and ConferenceIdentifier value setting in H.450.2and H.450.3 1507 PictureTel Fixing inconsistency between Annex E and H.283 and Annex G 1508 Chairman WP2/13 Status report on AAL2 signalling and switching 1509 Q12 Rapporteur Draft H.321 Implementors Guide 1510 Madge Networks cryptoTokens in H.225.0 Annex G 1511 Madge Networks Master/slave determination for inter-zone calls in H.323 environments where gatekeepers are routing H.245 signalling 1512 Madge Networks Submissions for the H.323 implementer's guide 1513 Ascend Extension Proposals for Gateway MIB of H.341 revison 2 1514 Siemens Comparison of Tunneling and Interworking 1515 Siemens H.450.x - Tunneling of External protocols 1516 ATMF "H.323 Over ATM Media Transport" specification 1517 ATMF H.245 codepoint for transport of compressed RTP over AAL5 1518 ATMF GIT for the transporting the portNumber 1519 Korea Telecom Dynamic Multicast Tree Building Procedure 1520 Nortel Networks Corrections to H.323 and H.245 regarding fast start procedures 1521 Bosch, Ericsson, NTT DoCoMo Request to support full MPEG-4 functionality in H.324 terminals 1522 Mitel Additions to the H.323 Implementors Guide 1523 Mitel Comments on H.323 Annex F 1524 BT, Mitel H.245 Pre-Opened Channels 1525 Editor (G Fruendlich) H.225.0 Annex G white draft from the editor 1526 Editor (G Fruendlich) H.225.0 Annex G Clarifications and Improvements 1527 Lucent Caller ID Support 1528 Lucent Name Identification Features 1529 Lucent Media Device Control Protocol (MDCP) 1530 Lucent Support for Wireless Coders in H.323 1531 Lucent ISUP-Based Signaling for H.225 Control 1532 TAO Consideration of MPEG-2 stream packetization 1533 Editor (J Toga) Proposed text for H.323 Implementers Guide 1534 LM Ericsson Generic Mechanism for SS7 Transport in H323 based networks 1535 Siemens Need for Services and Procedures for Charging, Accounting and Advice of Charge in H.323 1536 NEC Layered coding and bitrate/bandwidth scalability for speech/audio coding 1537 Nortel Networks Requirements Across the B, C, and D Interfaces of a Decomposed Gateway 1538 Nortel Networks Requirements For Tunneling of ISUP and Other Protocols 1539 Nortel Networks Proposed Changes to H.225.0v3 to Clarify TPKT References ----------------------------------------------------------------------

1 0

contributions uploaded
by Glen Freundlich 05 Feb '99

05 Feb '99

Dear Mr. Okubo, I have placed the following documents in the Incoming directory of the avc ftp site: APC-1525 - Annex G white draft APC-1529 - Media Device Control Protocol (MDCP) Best Regards, Glen Freundlich -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

Re: Relationship of H.323 and H.245 versions
by Santo Wiryaman 05 Feb '99

05 Feb '99

Jim, I do support this position. Thanks. -santo > -----Original Message----- > From: Jim Toga [SMTP:jim.toga@INTEL.COM] > Sent: Thursday, February 04, 1999 6:29 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Relationship of H.323 and H.245 versions > > Chris (and others) > > I'm penning up text (proposed) for the implementers guide. (Which I will > post here for comments by tommorow) At this point I'm going to go with > Paul's suggestion below even in light of your comments. Here's the > reasoning: > > If the GK is routing H.225.0 and _not_ H.245 (which is for further study, > btw) then is should _not_ be messing with any syntax/encoding that it > absolutely does not understand (for exactly this reason). If it is > routing > both, then it can 'proxy' and give what-ever 'face' revision to the > protocol that it wants (as long as it is consistent). > > I think what we gain by constraining the mix'n-match is consistency and > predictability. The cost is that, as we revise the 'umbrella' H.323 > Recommendation - products may have to support 'sets' of H.225.0/H.245 to > play in multiple worlds. I don't see any great _system_ advantage to > allowing vendors to provide a complete hodge-podge of stack revisions. > (This is orthogonal to allowing vendors to provide a hodge-podge of stack > support - H.235, annex E, annex G etc...) > > Regards, > jimt. > > > At 12:36 PM 2/1/99 -0000, you wrote: > >Paul (and others), > > > >Consider the case of a v1 gatekeeper routing H.225.0 and NOT H.245 in a > call > >between two v2 endpoints. The gatekeeper certainly MAY relegate the > H.225.0 > >messages to v1. This may be a policy decision, or it may be due to stack > >capabilities. Note that the gatekeeper may not always desire to relay > >messages entirely transparently, and is entirely within its rights to > make > >this sort of alteration (although people writing H.323 stacks for > >gatekeepers would probably be well advised to implement relaying of > messages > >or message fragments). Certainly the standard should not mandate that > >message relay should be entirely transparent. Anyway, the upshot of this > is > >that all H.225.0 messages in the call will be relegated to v1 by the > >gatekeeper. The H.245 session runs directly end-to-end and will hence be > >version 3, so both endpoints in the call need to be able to cope with an > >H.245 session of a different version from that implied by the H.225.0 > >session. > > > >Similar discrepancies may occur in the opposite direction (later version > of > >H.225.0 than H.245) for similar, but marginally more complex reasons. > > > >So what do we gain by insisting on an endpoint supporting EXACTLY version > 3 > >of H.245 if it happens to be EXACTLY version 2 of H.225.0 and vice versa? > >Although I agree that it is what is currently specified I'm unconvinced > it > >buys us anything. > > > >Regards, > >Chris > > > >> -----Original Message----- > >> From: Paul Long [mailto:Plong@SMITHMICRO.COM] > >> Sent: 29 January 1999 8:09 > >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> Subject: Re: Relationship of H.323 and H.245 versions > >> > >> > >> Gary, > >> > >> You be the judge: > >> > >> Summary/H.323v2: "Products claiming compliance with Version 2 > >> of H.323 shall > >> comply with all of the mandatory requirements of this > >> document, H.323 (1998), > >> which references H.225.0 (1998) and H.245 (1998). Version 2 > >> products can be > >> identified by H.225.0 messages containing a > >> protocolIdentifier = {itu-t (0) > >> recommendation (0) h (8) 2250 version (0) 2} and H.225.0 > >> messages containing a > >> protocolIdentifier = {itu-t (0) recommendation (0) h (8) 245 > >> version (0) 3}." > >> > >> Assuming this text is normative, H.323v2 uses H.225.0v2 and > >> H.245v3. Period. > >> > >> IMO, we will be asking for big trouble if we at some point > >> decide that one can > >> mix and match versions and even use subsets or supersets of a > >> particular > >> version. Whatever interoperability problems we have now will > >> be magnified many > >> times over if we head down that slippery slope. > >> > >> Paul Long > >> Smith Micro Software, Inc. > >> > >> -----Original Message----- > >> From: Gary A. Thom [SMTP:gthom@DELTA-INFO.COM] > >> Sent: Friday, January 29, 1999 1:37 PM > >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> Subject: Re: Relationship of H.323 and H.245 versions > >> > >> One more question???? > >> > >> > >> > Dave, > >> > > >> > Sorry, but I won't be in Monterey. > >> > > >> > I agree with what you say, except that I would go > >> further and state > >> that there > >> > is always a one-to-one mapping between H.225.0 and H.245 > >> protocolIdentifiers > >> > via H.323. For example, > >> > > >> > H.225.0v1 => H.323v1 => H.245v2 and H.245v2 => > >> H.323v1 => > >> H.225.0v1 > >> > H.225.0v2 => H.323v2 => H.245v3 and H.245v3 => > >> H.323v2 => > >> H.225.0v2 > >> > > >> > This is already implied by the Summary section of > >> H.323 starting > >> with version > >> > 2. I think it's clear, but you could add > >> clarification text if you > >> like. IOW, > >> > for example, an EP cannot use H.245v2 and H.225.0v2 > >> in the same > >> call. > >> > > >> > >> But can H.225.0 V2 (H.323 V2) and H.245V4 (or 5) be > >> used in the same > >> call??? > >> > >> Gary > >> > >> ------------------------------------------------------ > >> Name : Gary A. Thom > >> Company: Delta Information Systems, Inc. > >> Address: 300 Welsh Rd., Bldg 3 > >> Horsham, PA 19044 USA > >> Phone : +1-215-657-5270 Fax : +1-215-657-5273 > >> E-mail : gthom(a)delta-info.com > >> ------------------------------------------------------ > >> > > > +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

APC #
by Sakae OKUBO 05 Feb '99

05 Feb '99

Dear Jim Toga, Dear Christian Groves, APC numbers have been allocated to your contributions as attached. 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 *********************************************************** ---------------------------------------------------------------------- APC- Source Title ---------------------------------------------------------------------- 1486 SG11 Q.20/11 DSS2 protocol provision of adaptive timing recovery used for transmitting clock 1487 SG9 Q.31/9 Progress report on Webcasting 1488 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q 11, 12, 13 and 14 on MPEG-4 Systems on H.32X 1489 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q11, 12, 13, and 14 on MPEG-4 Audio on H.32X 1490 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q12 on Common Text Recommendations 1491 Nokia GSM in H.323 1492 AT&T H.323 Differentiated Services and Their Protocol Architectures 1493 AT&T Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" 1494 AT&T TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 1495 Editor (G Kajos) Changes to H.341 Annexes 1496 Editors (D Gurle, G Kimchi) Editorial changes to H.323 Annex E text 1497 TIPHON Requirements for a Protocol at Reference Point N: Media Gateway Controller to Media Gateway 1498 VTEL H.323 QoS (Quality of Service) in the Policy Based Network 1499 VTEL Slides Presentation for H.323 QoS (Quality of Service) in the Policy Based Network 1500 Editor (B Hill) Gateway Control Protocol H.GCP 1501 Editor (J Ott) H.323 Annex F White Paper (for a final review) 1502 Teles OpenLogicalChannel structures for Annex F 1503 PTS Sweden H.323 Annex "Text", Text Conversation Capable SUD 1504 PTS Sweden Text conversation in H.323 1505 Editor (M Korpi) Draft H.450.8 - Conference out of Consultation Supplementary Service for H.323 1506 Siemens CallIdentifier and ConferenceIdentifier value setting in H.450.2and H.450.3 1507 PictureTel Fixing inconsistency between Annex E and H.283 and Annex G 1508 Chairman WP2/13 Status report on AAL2 signalling and switching 1509 Q12 Rapporteur Draft H.321 Implementors Guide 1510 Madge Networks cryptoTokens in H.225.0 Annex G 1511 Madge Networks Master/slave determination for inter-zone calls in H.323 environments where gatekeepers are routing H.245 signalling 1512 Madge Networks Submissions for the H.323 implementer's guide 1513 Ascend Extension Proposals for Gateway MIB of H.341 revison 2 1514 Siemens Comparison of Tunneling and Interworking 1515 Siemens H.450.x - Tunneling of External protocols 1516 ATMF "H.323 Over ATM Media Transport" specification 1517 ATMF H.245 codepoint for transport of compressed RTP over AAL5 1518 ATMF GIT for the transporting the portNumber 1519 Korea Telecom Dynamic Multicast Tree Building Procedure 1520 Nortel Networks Corrections to H.323 and H.245 regarding fast start procedures 1521 Bosch, Ericsson, NTT DoCoMo Request to support full MPEG-4 functionality in H.324 terminals 1522 Mitel Additions to the H.323 Implementors Guide 1523 Mitel Comments on H.323 Annex F 1524 BT, Mitel H.245 Pre-Opened Channels 1525 Editor (G Fruendlich) H.225.0 Annex G white draft from the editor 1526 Editor (G Fruendlich) H.225.0 Annex G Clarifications and Improvements 1527 Lucent Caller ID Support 1528 Lucent Name Identification Features 1529 Lucent Media Device Control Protocol (MDCP) 1530 Lucent Support for Wireless Coders in H.323 1531 Lucent ISUP-Based Signaling for H.225 Control 1532 TAO Consideration of MPEG-2 stream packetization 1533 Editor (J Toga) Proposed text for H.323 Implementers Guide 1534 LM Ericsson Generic Mechanism for SS7 Transport in H323 based networks ----------------------------------------------------------------------

1 0

Contributions to the Monterey meeting
by Sakae OKUBO 04 Feb '99

04 Feb '99

Dear Jens Vollmer, Dear Dave Walker, Dear Mike Nilsson, Dear Glen Freundlich, In response to your requests, APC numbers have been allocated to your contributions as attached. 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 *********************************************************** ---------------------------------------------------------------------- APC- Source Title ---------------------------------------------------------------------- 1486 SG11 Q.20/11 DSS2 protocol provision of adaptive timing recovery used for transmitting clock 1487 SG9 Q.31/9 Progress report on Webcasting 1488 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q 11, 12, 13 and 14 on MPEG-4 Systems on H.32X 1489 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q11, 12, 13, and 14 on MPEG-4 Audio on H.32X 1490 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q12 on Common Text Recommendations 1491 Nokia GSM in H.323 1492 AT&T H.323 Differentiated Services and Their Protocol Architectures 1493 AT&T Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" 1494 AT&T TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 1495 Editor (G Kajos) Changes to H.341 Annexes 1496 Editors (D Gurle, G Kimchi) Editorial changes to H.323 Annex E text 1497 TIPHON Requirements for a Protocol at Reference Point N: Media Gateway Controller to Media Gateway 1498 VTEL H.323 QoS (Quality of Service) in the Policy Based Network 1499 VTEL Slides Presentation for H.323 QoS (Quality of Service) in the Policy Based Network 1500 Editor (B Hill) Gateway Control Protocol H.GCP 1501 Editor (J Ott) H.323 Annex F White Paper (for a final review) 1502 Teles OpenLogicalChannel structures for Annex F 1503 PTS Sweden H.323 Annex "Text", Text Conversation Capable SUD 1504 PTS Sweden Text conversation in H.323 1505 Editor (M Korpi) Draft H.450.8 - Conference out of Consultation Supplementary Service for H.323 1506 Siemens CallIdentifier and ConferenceIdentifier value setting in H.450.2and H.450.3 1507 PictureTel Fixing inconsistency between Annex E and H.283 and Annex G 1508 Chairman WP2/13 Status report on AAL2 signalling and switching 1509 Q12 Rapporteur Draft H.321 Implementors Guide 1510 Madge Networks cryptoTokens in H.225.0 Annex G 1511 Madge Networks Master/slave determination for inter-zone calls in H.323 environments where gatekeepers are routing H.245 signalling 1512 Madge Networks Submissions for the H.323 implementer's guide 1513 Ascend Extension Proposals for Gateway MIB of H.341 revison 2 1514 Siemens Comparison of Tunneling and Interworking 1515 Siemens H.450.x - Tunneling of External protocols 1516 ATMF "H.323 Over ATM Media Transport" specification 1517 ATMF H.245 codepoint for transport of compressed RTP over AAL5 1518 ATMF GIT for the transporting the portNumber 1519 Korea Telecom Dynamic Multicast Tree Building Procedure 1520 Nortel Networks Corrections to H.323 and H.245 regarding fast start procedures 1521 Bosch, Ericsson, NTT DoCoMo Request to support full MPEG-4 functionality in H.324 terminals 1522 Mitel Additions to the H.323 Implementors Guide 1523 Mitel Comments on H.323 Annex F 1524 BT, Mitel H.245 Pre-Opened Channels 1525 Editor (G Fruendlich) H.225.0 Annex G white draft from the editor 1526 Editor (G Fruendlich) H.225.0 Annex G Clarifications and Improvements 1527 Lucent Caller ID Support 1528 Lucent Name Identification Features 1529 Lucent Media Device Control Protocol (MDCP) 1530 Lucent Support for Wireless Coders in H.323 1531 Lucent ISUP-Based Signaling for H.225 Control ----------------------------------------------------------------------

1 0

Re: Relationship of H.323 and H.245 versions
by Jim Toga 04 Feb '99

04 Feb '99

Chris (and others) I'm penning up text (proposed) for the implementers guide. (Which I will post here for comments by tommorow) At this point I'm going to go with Paul's suggestion below even in light of your comments. Here's the reasoning: If the GK is routing H.225.0 and _not_ H.245 (which is for further study, btw) then is should _not_ be messing with any syntax/encoding that it absolutely does not understand (for exactly this reason). If it is routing both, then it can 'proxy' and give what-ever 'face' revision to the protocol that it wants (as long as it is consistent). I think what we gain by constraining the mix'n-match is consistency and predictability. The cost is that, as we revise the 'umbrella' H.323 Recommendation - products may have to support 'sets' of H.225.0/H.245 to play in multiple worlds. I don't see any great _system_ advantage to allowing vendors to provide a complete hodge-podge of stack revisions. (This is orthogonal to allowing vendors to provide a hodge-podge of stack support - H.235, annex E, annex G etc...) Regards, jimt. At 12:36 PM 2/1/99 -0000, you wrote: >Paul (and others), > >Consider the case of a v1 gatekeeper routing H.225.0 and NOT H.245 in a call >between two v2 endpoints. The gatekeeper certainly MAY relegate the H.225.0 >messages to v1. This may be a policy decision, or it may be due to stack >capabilities. Note that the gatekeeper may not always desire to relay >messages entirely transparently, and is entirely within its rights to make >this sort of alteration (although people writing H.323 stacks for >gatekeepers would probably be well advised to implement relaying of messages >or message fragments). Certainly the standard should not mandate that >message relay should be entirely transparent. Anyway, the upshot of this is >that all H.225.0 messages in the call will be relegated to v1 by the >gatekeeper. The H.245 session runs directly end-to-end and will hence be >version 3, so both endpoints in the call need to be able to cope with an >H.245 session of a different version from that implied by the H.225.0 >session. > >Similar discrepancies may occur in the opposite direction (later version of >H.225.0 than H.245) for similar, but marginally more complex reasons. > >So what do we gain by insisting on an endpoint supporting EXACTLY version 3 >of H.245 if it happens to be EXACTLY version 2 of H.225.0 and vice versa? >Although I agree that it is what is currently specified I'm unconvinced it >buys us anything. > >Regards, >Chris > >> -----Original Message----- >> From: Paul Long [mailto:Plong@SMITHMICRO.COM] >> Sent: 29 January 1999 8:09 >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: Relationship of H.323 and H.245 versions >> >> >> Gary, >> >> You be the judge: >> >> Summary/H.323v2: "Products claiming compliance with Version 2 >> of H.323 shall >> comply with all of the mandatory requirements of this >> document, H.323 (1998), >> which references H.225.0 (1998) and H.245 (1998). Version 2 >> products can be >> identified by H.225.0 messages containing a >> protocolIdentifier = {itu-t (0) >> recommendation (0) h (8) 2250 version (0) 2} and H.225.0 >> messages containing a >> protocolIdentifier = {itu-t (0) recommendation (0) h (8) 245 >> version (0) 3}." >> >> Assuming this text is normative, H.323v2 uses H.225.0v2 and >> H.245v3. Period. >> >> IMO, we will be asking for big trouble if we at some point >> decide that one can >> mix and match versions and even use subsets or supersets of a >> particular >> version. Whatever interoperability problems we have now will >> be magnified many >> times over if we head down that slippery slope. >> >> Paul Long >> Smith Micro Software, Inc. >> >> -----Original Message----- >> From: Gary A. Thom [SMTP:gthom@DELTA-INFO.COM] >> Sent: Friday, January 29, 1999 1:37 PM >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: Relationship of H.323 and H.245 versions >> >> One more question???? >> >> >> > Dave, >> > >> > Sorry, but I won't be in Monterey. >> > >> > I agree with what you say, except that I would go >> further and state >> that there >> > is always a one-to-one mapping between H.225.0 and H.245 >> protocolIdentifiers >> > via H.323. For example, >> > >> > H.225.0v1 => H.323v1 => H.245v2 and H.245v2 => >> H.323v1 => >> H.225.0v1 >> > H.225.0v2 => H.323v2 => H.245v3 and H.245v3 => >> H.323v2 => >> H.225.0v2 >> > >> > This is already implied by the Summary section of >> H.323 starting >> with version >> > 2. I think it's clear, but you could add >> clarification text if you >> like. IOW, >> > for example, an EP cannot use H.245v2 and H.225.0v2 >> in the same >> call. >> > >> >> But can H.225.0 V2 (H.323 V2) and H.245V4 (or 5) be >> used in the same >> call??? >> >> Gary >> >> ------------------------------------------------------ >> Name : Gary A. Thom >> Company: Delta Information Systems, Inc. >> Address: 300 Welsh Rd., Bldg 3 >> Horsham, PA 19044 USA >> Phone : +1-215-657-5270 Fax : +1-215-657-5273 >> E-mail : gthom(a)delta-info.com >> ------------------------------------------------------ >> > +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

APC-1514 and APC-1515
by Callaghan, Robert 04 Feb '99

04 Feb '99

The documents APC-1514 and APC-1515 have been uploaded to the server. ------------------------------------------------------------------ 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: TPKT in H.225.0
by Jim Toga 04 Feb '99

04 Feb '99

I am working on some (initial) text for the Implementers Guide. I will welcome additions/modifications at the Rapportours meeting...... jimt. At 02:03 PM 2/4/99 +0100, Derks, Frank wrote: >Hi Tom, > >I couldn't find it either and I suspect that it couldn't be in because the >ITU is very reluctant to reference any non-ITU material. Furthermore, >RFC1006 encompasses a lot more than just the bit(s) that are used for >H.225.0, so even referring to this RFC does not clarify it all. I think some >work should be spent on this. > >Frank > >-----Original Message----- >From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] >Sent: 02 February 1999 22:12 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: TPKT in H.225.0 > > >I'd swear the reference to RFC1006 used to be in H.225.0 Appendix D, but I >can't find it there now. > >> -----Original Message----- >> From: Derks, Frank [SMTP:F.Derks@PBC.BE.PHILIPS.COM] >> Sent: Tuesday, February 02, 1999 4:05 AM >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: TPKT in H.225.0 >> >> Hi Paul, >> >> I received two responses to my question, one from you and one from Tom >> Taylor. The fact that there are at least two people that know about it >> (and >> several dozens more that have actually implemented the protocol stacks), >> makes it hard to believe that this is an "oversight" in the >> recommendation. >> In fact, not knowing about this makes it impossible to implement an >> interoperable protocol stack! Shouldn't action be taken to get this into >> the >> recommendation ASAP (e.g. through the Implementor's Guide)? >> >> Regards, >> >> Frank >> >> -----Original Message----- >> From: Paul Long [mailto:Plong@SMITHMICRO.COM] >> Sent: 01 February 1999 18:50 >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: TPKT in H.225.0 >> >> >> TPKT is defined in RFC 1006. Not identifying TPKT was an oversight that >> has >> never been fixed in the Recommendation. >> >> Paul Long >> Smith Micro Software, Inc. > +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

Re: TPKT in H.225.0
by Derks, Frank 04 Feb '99

04 Feb '99

Hi Tom, I couldn't find it either and I suspect that it couldn't be in because the ITU is very reluctant to reference any non-ITU material. Furthermore, RFC1006 encompasses a lot more than just the bit(s) that are used for H.225.0, so even referring to this RFC does not clarify it all. I think some work should be spent on this. Frank -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: 02 February 1999 22:12 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: TPKT in H.225.0 I'd swear the reference to RFC1006 used to be in H.225.0 Appendix D, but I can't find it there now. > -----Original Message----- > From: Derks, Frank [SMTP:F.Derks@PBC.BE.PHILIPS.COM] > Sent: Tuesday, February 02, 1999 4:05 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: TPKT in H.225.0 > > Hi Paul, > > I received two responses to my question, one from you and one from Tom > Taylor. The fact that there are at least two people that know about it > (and > several dozens more that have actually implemented the protocol stacks), > makes it hard to believe that this is an "oversight" in the > recommendation. > In fact, not knowing about this makes it impossible to implement an > interoperable protocol stack! Shouldn't action be taken to get this into > the > recommendation ASAP (e.g. through the Implementor's Guide)? > > Regards, > > Frank > > -----Original Message----- > From: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: 01 February 1999 18:50 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: TPKT in H.225.0 > > > TPKT is defined in RFC 1006. Not identifying TPKT was an oversight that > has > never been fixed in the Recommendation. > > Paul Long > Smith Micro Software, Inc.

1 0

RE: Santo's problem and H.450.2
by hlt＠zurich.ibm.com 04 Feb '99

04 Feb '99

Paul, two additional emails on the topic. Linh ---------------------- Forwarded by Hong Linh Truong/Zurich/IBM on 04.02.99 08:20 --------------------------- "Kumar, Vineet" <vineet.kumar(a)intel.com> on 03.02.99 19:05:03 To: Hong Linh Truong/Zurich/IBM, Klaghofer Karl ICN IB NL IP 7 <Karl.Klaghofer(a)vs.siemens.de>, Korpi Markku USA <markku.korpi(a)icn.siemens.com>, "'wiryaman santo (VideoServer)'" <swiryaman(a)VideoServer.com>, "Kumar, Vineet" <vineet.kumar(a)intel.com>, "'Freundlich Glen'" <ggf(a)lucent.com>, "'Walker Dave (Mitel)'" <dave_walker(a)mitel.com>, "'Ruditsky Sasha (RadVision)'" <sasha(a)radvision.rad.co.il>, Chris Purvis <CPurvis(a)Madge.com> cc: Subject: RE: Santo's problem and H.450.2 The case is: B calls A and a connection is established between A and B. Then A transfers B to C which ends up with a connection between B and C. In this case we agree that things work fine as long as we don't bring in accounting/charging. Since accounting/charging is needed in the real world, we need to bring that in as a new supplementary service. Any ideas ? Let's look at the charging models in the above case: (i) If B dialed a toll-free number then it is expected that B will not pay for the call even when he is transferred to C. This means that the transferred-to number should also be toll-free. (ii) If B dialed a non toll-free number then the question is whether B should pay for the call when he gets transferred to C. Seems that if A uses a toll-free number to transfer B to C then there is no problem. But if A uses a non toll-free number then atleast the user at B should be informed before the transfer. B can then decide whether to have the call transferred. B can also program his terminal to transfer only local calls as an example here. My suggestion is that there should be a way to express all these various cases in some document so the accounting model is consistent. But my thinking on this subject is preliminary, so comments are welcome. vineet -----Original Message----- From: hlt(a)zurich.ibm.com [mailto:hlt@zurich.ibm.com] Sent: Wednesday, February 03, 1999 5:44 AM To: Klaghofer Karl ICN IB NL IP 7; Korpi Markku USA; 'wiryaman santo (VideoServer)'; 'Kumar Vineet (Intel)'; 'Freundlich Glen'; 'Walker Dave (Mitel)'; 'Ruditsky Sasha (RadVision)'; hlt(a)zurich.ibm.com; Chris Purvis Subject: Santo's problem and H.450.2 Dear all, after having answered Santo's note on the charging problem one may run into when a call is re-routed, it came to my mind that we have the same problem with H.450.2. According to Figures 2 and 8 of H.450.2, if A was calling B and then transfers B to C, then it will ends up with B having to pay for the transferred call B to C! I don't have time yet to check whether it also the case for H.450.5. Karl and Markku, may be you know immediately the answer? Regards, Linh ---------------------- Forwarded by Hong Linh Truong/Zurich/IBM on 04.02.99 08:20 --------------------------- Klaghofer Karl ICN IB NL IP 7 <Karl.Klaghofer(a)vs.siemens.de> on 03.02.99 18:33:35 To: "'Chris Purvis'" <CPurvis(a)Madge.com>, Hong Linh Truong/Zurich/IBM, Korpi Markku USA <markku.korpi(a)icn.siemens.com>, "'wiryaman santo (VideoServer)'" <swiryaman(a)VideoServer.com>, "'Kumar Vineet (Intel)'" <vineet.kumar(a)intel.com>, "'Freundlich Glen'" <ggf(a)lucent.com>, "'Walker Dave (Mitel)'" <dave_walker(a)mitel.com>, "'Ruditsky Sasha (RadVision)'" <sasha(a)radvision.rad.co.il> cc: Subject: AW: Reps and interrupted dinners The issue of charging interactions in conjunction with supplementary services was a complicated topic already in the ISDN and ISO PBX networking. You have to think about charging really on a per supplementary service basis. For SS-CoC (following H.450.8 approach) it might be the served user (CSSE) that takes over the charges for all calls. BTW, We actually need a "Advice of Charge" service for H.323, that maps the SCN AOC mesages to H.323 environment for being displayed at the H.323 endpoint to the user. Regards, Karl > -----Ursprüngliche Nachricht----- > Von: Chris Purvis [SMTP:CPurvis@Madge.com] > Gesendet am: Mittwoch, 3. Februar 1999 16:50 > An: 'hlt(a)zurich.ibm.com'; Klaghofer Karl ICN IB NL IP 7; Korpi Markku > USA; 'wiryaman santo (VideoServer)'; 'Kumar Vineet (Intel)'; 'Freundlich > Glen'; 'Walker Dave (Mitel)'; 'Ruditsky Sasha (RadVision)' > Betreff: Reps and interrupted dinners > > Santo, Linh et al, > > Sorry for the subject line change, but this is a bit of a side-track > (however interesting) from the main stream discussion... > > My feeling is that I would wish to be able to set up policy for my > endpoint > that to make it ignore these messages (or at least ask me very nicely) if > they were about to involve me in spending large amounts of money. The > routeCallToMC FACILITY message is for the express purpose of telling me > that > the endpoint I've tried to call is already in a conference, and how to > join > it. Possible ways that I can see of adding extra endpoints to an extant > call in Santo's scenario are: > 1. Use Linh's method, and allow the man with the interrupted dinner to put > the phone down and then ring it again. > 2. Something like Karl's H.450.8-proposal that allows us to "replace" one > call with another. This would need to be combined with Linh's comments in > order to avoid 1. > 3. Give the "rep" in that scenario an endpoint containing an MC, or a > clever > enough gatekeeper (one containing, or "with access to" an MC) that any > calls > can be made at the rep's expense. In this scenario any call control > signalling (H.225 and H.245) to the interrupted-dinner-person are routed > via > the rep's GK, and these stay open when the GK pulls in the MC. > > Of these, 1. is inconvenient to the user, 2. requires some standardisation > work, and 3. requires the annoying rep to spend money. Any preferences? > > Regards, > Chris > > > > -----Original Message----- > > From: hlt(a)zurich.ibm.com [mailto:hlt@zurich.ibm.com] > > Sent: 03 February 1999 1:20 > > To: Klaghofer Karl ICN IB NL IP 7; Korpi Markku USA; 'wiryaman santo > > (VideoServer)'; 'Kumar Vineet (Intel)'; 'Freundlich Glen'; > > 'Walker Dave > > (Mitel)'; 'Ruditsky Sasha (RadVision)'; hlt(a)zurich.ibm.com; > > Chris Purvis > > Subject: RE: Draft H.450.8 Conference out of Consultation Suppl. Serv. > > for H.323 > > > > > > > > > > My apologies. I forget to cc: to the whole group my reply to Santo. > > Linh > > ---------------------- Forwarded by Hong Linh > > Truong/Zurich/IBM on 03.02.99 > > 14:18 --------------------------- > > > > From: Hong Linh Truong on 03.02.99 10:00 > > > > To: Santo Wiryaman <swiryaman(a)VideoServer.com> > > cc: > > > > Subject: RE: Draft H.450.8 Conference out of Consultation > > Suppl. Serv. for > > H.323 (Document link not converted) > > > > Santo, > > > > Although I do not know how the charging model for IP > > telephony will look > > like, I do agree with the excellent point you made below. > > Assuming that in > > general the calling party has to pay for the call, then any > > conferencing > > approach that modifies the setup direction of a call will run > > into that > > unacceptable problem. Unfortunately, both conferencing > > approaches we have > > identified so far do modify the direction of the calls. > > > > Let me take your scenario and modify it a little bit. Instead > > the agent > > conferencing-in his boss, you conference-in your wife. In > > this case you'd > > be fine with the Facility "re-route to MC" but not with > > 450.8. Using 450.8 > > you'd get a bill at the end of the month ;-). > > > > To solve the above problem, we need an approach that DO NOT modify the > > setup direction of the calls. Fortunately, we can build such > > an approach > > based on the current H.323. Endpoint A (the one that wants to create a > > conference with B and C) has now to handle a call differently based on > > whether it is an incoming or an outgoing call (from A's view > > point). If it > > was an incoming call, then A will send out a FACILITY > > "re-route to MC". If > > it was an outgoing call, then A has to request the MC to invite the > > corresponding endpoint. H.323 Figure 28 shows how the > > invitation procedure > > looks like. > > > > Any other opinions? > > > > Regards, > > > > Linh > > > > > > > > > > Santo Wiryaman <swiryaman(a)VideoServer.com> on 02.02.99 17:02:55 > > > > To: Klaghofer Karl ICN IB NL IP 7 > > <Karl.Klaghofer(a)vs.siemens.de>, Korpi > > Markku USA <markku.korpi(a)icn.siemens.com>, "'wiryaman santo > > (VideoServer)'" <swiryaman(a)VideoServer.com>, "'Kumar > > Vineet (Intel)'" > > <vineet.kumar(a)intel.com>, "'Freundlich Glen'" <ggf(a)lucent.com>, > > "'Walker Dave (Mitel)'" <dave_walker(a)mitel.com>, > > "'Ruditsky Sasha > > (RadVision)'" <sasha(a)radvision.rad.co.il>, Hong Linh > > Truong/Zurich/IBM, Chris Purvis <CPurvis(a)Madge.com> > > cc: > > > > Subject: RE: Draft H.450.8 Conference out of Consultation > > Suppl. Serv. for > > H.323 > > > > > > > > > > Karl, > > > > I share your concern on the fact that not all endpoints > > support the H.225.0 > > FACILITY "re-route to MC". Even though Linh pointed out that this is > > mandatory, I envision a general deployment problem with these > > "re-route to > > SOMETHING" messages. > > > > The problem I see is that the receiver of this message is to > > make a new > > call > > somewhere else, presumably automatically, without the user's > > consent. I > > can > > imagine the following scenario: > > > > 1. I am at home eating my dinner > > 2. The phone rings and it was a courtesy call from my long > > distance carrier > > to check if I am satisfied with their service > > 3. My dinner interrupted, I am already somewhat annoyed. > > However, while the > > rep is on the phone, I might as well ask if they have special > > deals for > > calling Switzerland > > 4. The rep is not familiar with any, so he conferences-in his > > manager using > > the "re-route to MC" message > > 5. The conference call went OK, but at the end of the month, > > I got this > > charge for calling an MCU in the Cayman Island > > > > As an engineer, I can see how the scheme might work, but as a > > consumer, I > > would have problem with the above scenario. Even if the > > endpoint prompts > > me > > for authorization to call the MCU, I would probably said no > > and continued > > with my dinner. > > > > I can see consumer pressure for an option to block the "re-route to > > SOMETHING" messages. > > > > Any opinions? > > > > > > Regards, > > > > Santo Wiryaman > > VideoServer Inc. > > +1.781.505.2348 > > > > > > > -----Original Message----- > > > From: Klaghofer Karl ICN IB NL IP 7 > > [SMTP:Karl.Klaghofer@vs.siemens.de] > > > Sent: Monday, February 01, 1999 11:36 AM > > > To: Korpi Markku USA; 'wiryaman santo (VideoServer)'; > > 'Kumar Vineet > > > (Intel)'; 'Freundlich Glen'; 'Walker Dave (Mitel)'; 'Ruditsky Sasha > > > (RadVision)'; 'hlt(a)zurich.ibm.com'; Chris Purvis > > > Subject: AW: Draft H.450.8 Conference out of Consultation Suppl. > > > Serv. for H.323 > > > > > > To all "conference participants": > > > > > > I had not yet answered the last comments/proposals > > received on Draft > > > H.450.8. The attached memo provides a summary. > > > > > > Thanks for your contributions so far. > > > > > > Regards, > > > Karl > > > > > > > > > <<H4508comments990201.doc>> > > > > > > > > > > > > ------------------------------------------------ > > > Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL IP7 > > > Hofmannstr. 51, D-81359 Munich, Germany > > > Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 > > > e-mail: karl.klaghofer(a)vs.siemens.de > > > > > > > > > << File: H4508comments990201.doc >> > > > >

1 0

Re: About Contribution submission
by Sakae OKUBO 03 Feb '99

03 Feb '99

Dear Mr. Audet, APC-1520 has been allocated to your contribution "Corrections to H.323 and H.245 regarding fast start procedures." 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 *********************************************************** ---------------------------------------------------------------------- APC- Source Title ---------------------------------------------------------------------- 1486 SG11 Q.20/11 DSS2 protocol provision of adaptive timing recovery used for transmitting clock 1487 SG9 Q.31/9 Progress report on Webcasting 1488 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q 11, 12, 13 and 14 on MPEG-4 Systems on H.32X 1489 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q11, 12, 13, and 14 on MPEG-4 Audio on H.32X 1490 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q12 on Common Text Recommendations 1491 Nokia GSM in H.323 1492 AT&T H.323 Differentiated Services and Their Protocol Architectures 1493 AT&T Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" 1494 AT&T TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 1495 Editor (G Kajos) Changes to H.341 Annexes 1496 Editors (D Gurle, G Kimchi) Editorial changes to H.323 Annex E text 1497 TIPHON Requirements for a Protocol at Reference Point N: Media Gateway Controller to Media Gateway 1498 VTEL H.323 QoS (Quality of Service) in the Policy Based Network 1499 VTEL Slides Presentation for H.323 QoS (Quality of Service) in the Policy Based Network 1500 Editor (B Hill) Gateway Control Protocol H.GCP 1501 Editor (J Ott) H.323 Annex F White Paper (for a final review) 1502 Teles OpenLogicalChannel structures for Annex F 1503 PTS Sweden H.323 Annex "Text", Text Conversation Capable SUD 1504 PTS Sweden Text conversation in H.323 1505 Editor (M Korpi) Draft H.450.8 - Conference out of Consultation Supplementary Service for H.323 1506 Siemens CallIdentifier and ConferenceIdentifier value setting in H.450.2and H.450.3 1507 PictureTel Fixing inconsistency between Annex E and H.283 and Annex G 1508 Chairman WP2/13 Status report on AAL2 signalling and switching 1509 Q12 Rapporteur Draft H.321 Implementors Guide 1510 Madge Networks cryptoTokens in H.225.0 Annex G 1511 Madge Networks Master/slave determination for inter-zone calls in H.323 environments where gatekeepers are routing H.245 signalling 1512 Madge Networks Submissions for the H.323 implementer's guide 1513 Ascend Extension Proposals for Gateway MIB of H.341 revison 2 1514 Siemens Comparison of Tunneling and Interworking 1515 Siemens H.450.x - Tunneling of External protocols 1516 ATMF "H.323 Over ATM Media Transport" specification 1517 ATMF H.245 codepoint for transport of compressed RTP over AAL5 1518 ATMF GIT for the transporting the portNumber 1519 Korea Telecom Dynamic Multicast Tree Building Procedure 1520 Nortel Networks Corrections to H.323 and H.245 regarding fast start procedures ----------------------------------------------------------------------

1 0

APC-1507 uploaded to Incoming directory
by Mark Duckworth 03 Feb '99

03 Feb '99

I have uploaded APC-1507.zip, Fixing Inconsistency Between Annex E and H.283 and Annex G, to ftp://standard.pictel.com/avc-site/Incoming This contribution proposes removing references to H.283 and H.225.0 Annex G from H.323 Annexe E, so that Annex E is consistent with H.283 and Annex G. Mark Duckworth

2 1

Re: About Contribution submission
by Sakae OKUBO 03 Feb '99

03 Feb '99

Dear Mr. Sang Gil Kim, In response to your request, APC-1519 has been allocated to your contribution "Dynamic Multicast Tree Building Procedure" as attached. 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 *********************************************************** ---------------------------------------------------------------------- APC- Source Title ---------------------------------------------------------------------- 1486 SG11 Q.20/11 DSS2 protocol provision of adaptive timing recovery used for transmitting clock 1487 SG9 Q.31/9 Progress report on Webcasting 1488 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q 11, 12, 13 and 14 on MPEG-4 Systems on H.32X 1489 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q11, 12, 13, and 14 on MPEG-4 Audio on H.32X 1490 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q12 on Common Text Recommendations 1491 Nokia GSM in H.323 1492 AT&T H.323 Differentiated Services and Their Protocol Architectures 1493 AT&T Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" 1494 AT&T TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 1495 Editor (G Kajos) Changes to H.341 Annexes 1496 Editors (D Gurle, G Kimchi) Editorial changes to H.323 Annex E text 1497 TIPHON Requirements for a Protocol at Reference Point N: Media Gateway Controller to Media Gateway 1498 VTEL H.323 QoS (Quality of Service) in the Policy Based Network 1499 VTEL Slides Presentation for H.323 QoS (Quality of Service) in the Policy Based Network 1500 Editor (B Hill) Gateway Control Protocol H.GCP 1501 Editor (J Ott) H.323 Annex F White Paper (for a final review) 1502 Teles OpenLogicalChannel structures for Annex F 1503 PTS Sweden H.323 Annex "Text", Text Conversation Capable SUD 1504 PTS Sweden Text conversation in H.323 1505 Editor (M Korpi) Draft H.450.8 - Conference out of Consultation Supplementary Service for H.323 1506 Siemens CallIdentifier and ConferenceIdentifier value setting in H.450.2and H.450.3 1507 PictureTel Fixing inconsistency between Annex E and H.283 and Annex G 1508 Chairman WP2/13 Status report on AAL2 signalling and switching 1509 Q12 Rapporteur Draft H.321 Implementors Guide 1510 Madge Networks cryptoTokens in H.225.0 Annex G 1511 Madge Networks Master/slave determination for inter-zone calls in H.323 environments where gatekeepers are routing H.245 signalling 1512 Madge Networks Submissions for the H.323 implementer's guide 1513 Ascend Extension Proposals for Gateway MIB of H.341 revison 2 1514 Siemens Comparison of Tunneling and Interworking 1515 Siemens H.450.x - Tunneling of External protocols 1516 ATMF "H.323 Over ATM Media Transport" specification 1517 ATMF H.245 codepoint for transport of compressed RTP over AAL5 1518 ATMF GIT for the transporting the portNumber 1519 Korea Telecom Dynamic Multicast Tree Building Procedure ----------------------------------------------------------------------

1 0

Reps and interrupted dinners
by hlt＠zurich.ibm.com 03 Feb '99

03 Feb '99

I'm now forwarding the emails relating to that thread to your ITU account. Is that OK for you or do you prefer your Databeam one? Linh ---------------------- Forwarded by Hong Linh Truong/Zurich/IBM on 03.02.99 17:34 --------------------------- Chris Purvis <CPurvis(a)Madge.com> on 03.02.99 16:49:50 To: Hong Linh Truong/Zurich/IBM, Klaghofer Karl ICN IB NL IP 7 <Karl.Klaghofer(a)vs.siemens.de>, Korpi Markku USA <markku.korpi(a)icn.siemens.com>, "'wiryaman santo (VideoServer)'" <swiryaman(a)VideoServer.com>, "'Kumar Vineet (Intel)'" <vineet.kumar(a)intel.com>, "'Freundlich Glen'" <ggf(a)lucent.com>, "'Walker Dave (Mitel)'" <dave_walker(a)mitel.com>, "'Ruditsky Sasha (RadVision)'" <sasha(a)radvision.rad.co.il> cc: Subject: Reps and interrupted dinners Santo, Linh et al, Sorry for the subject line change, but this is a bit of a side-track (however interesting) from the main stream discussion... My feeling is that I would wish to be able to set up policy for my endpoint that to make it ignore these messages (or at least ask me very nicely) if they were about to involve me in spending large amounts of money. The routeCallToMC FACILITY message is for the express purpose of telling me that the endpoint I've tried to call is already in a conference, and how to join it. Possible ways that I can see of adding extra endpoints to an extant call in Santo's scenario are: 1. Use Linh's method, and allow the man with the interrupted dinner to put the phone down and then ring it again. 2. Something like Karl's H.450.8-proposal that allows us to "replace" one call with another. This would need to be combined with Linh's comments in order to avoid 1. 3. Give the "rep" in that scenario an endpoint containing an MC, or a clever enough gatekeeper (one containing, or "with access to" an MC) that any calls can be made at the rep's expense. In this scenario any call control signalling (H.225 and H.245) to the interrupted-dinner-person are routed via the rep's GK, and these stay open when the GK pulls in the MC. Of these, 1. is inconvenient to the user, 2. requires some standardisation work, and 3. requires the annoying rep to spend money. Any preferences? Regards, Chris > -----Original Message----- > From: hlt(a)zurich.ibm.com [mailto:hlt@zurich.ibm.com] > Sent: 03 February 1999 1:20 > To: Klaghofer Karl ICN IB NL IP 7; Korpi Markku USA; 'wiryaman santo > (VideoServer)'; 'Kumar Vineet (Intel)'; 'Freundlich Glen'; > 'Walker Dave > (Mitel)'; 'Ruditsky Sasha (RadVision)'; hlt(a)zurich.ibm.com; > Chris Purvis > Subject: RE: Draft H.450.8 Conference out of Consultation Suppl. Serv. > for H.323 > > > > > My apologies. I forget to cc: to the whole group my reply to Santo. > Linh > ---------------------- Forwarded by Hong Linh > Truong/Zurich/IBM on 03.02.99 > 14:18 --------------------------- > > From: Hong Linh Truong on 03.02.99 10:00 > > To: Santo Wiryaman <swiryaman(a)VideoServer.com> > cc: > > Subject: RE: Draft H.450.8 Conference out of Consultation > Suppl. Serv. for > H.323 (Document link not converted) > > Santo, > > Although I do not know how the charging model for IP > telephony will look > like, I do agree with the excellent point you made below. > Assuming that in > general the calling party has to pay for the call, then any > conferencing > approach that modifies the setup direction of a call will run > into that > unacceptable problem. Unfortunately, both conferencing > approaches we have > identified so far do modify the direction of the calls. > > Let me take your scenario and modify it a little bit. Instead > the agent > conferencing-in his boss, you conference-in your wife. In > this case you'd > be fine with the Facility "re-route to MC" but not with > 450.8. Using 450.8 > you'd get a bill at the end of the month ;-). > > To solve the above problem, we need an approach that DO NOT modify the > setup direction of the calls. Fortunately, we can build such > an approach > based on the current H.323. Endpoint A (the one that wants to create a > conference with B and C) has now to handle a call differently based on > whether it is an incoming or an outgoing call (from A's view > point). If it > was an incoming call, then A will send out a FACILITY > "re-route to MC". If > it was an outgoing call, then A has to request the MC to invite the > corresponding endpoint. H.323 Figure 28 shows how the > invitation procedure > looks like. > > Any other opinions? > > Regards, > > Linh > > > > > Santo Wiryaman <swiryaman(a)VideoServer.com> on 02.02.99 17:02:55 > > To: Klaghofer Karl ICN IB NL IP 7 > <Karl.Klaghofer(a)vs.siemens.de>, Korpi > Markku USA <markku.korpi(a)icn.siemens.com>, "'wiryaman santo > (VideoServer)'" <swiryaman(a)VideoServer.com>, "'Kumar > Vineet (Intel)'" > <vineet.kumar(a)intel.com>, "'Freundlich Glen'" <ggf(a)lucent.com>, > "'Walker Dave (Mitel)'" <dave_walker(a)mitel.com>, > "'Ruditsky Sasha > (RadVision)'" <sasha(a)radvision.rad.co.il>, Hong Linh > Truong/Zurich/IBM, Chris Purvis <CPurvis(a)Madge.com> > cc: > > Subject: RE: Draft H.450.8 Conference out of Consultation > Suppl. Serv. for > H.323 > > > > > Karl, > > I share your concern on the fact that not all endpoints > support the H.225.0 > FACILITY "re-route to MC". Even though Linh pointed out that this is > mandatory, I envision a general deployment problem with these > "re-route to > SOMETHING" messages. > > The problem I see is that the receiver of this message is to > make a new > call > somewhere else, presumably automatically, without the user's > consent. I > can > imagine the following scenario: > > 1. I am at home eating my dinner > 2. The phone rings and it was a courtesy call from my long > distance carrier > to check if I am satisfied with their service > 3. My dinner interrupted, I am already somewhat annoyed. > However, while the > rep is on the phone, I might as well ask if they have special > deals for > calling Switzerland > 4. The rep is not familiar with any, so he conferences-in his > manager using > the "re-route to MC" message > 5. The conference call went OK, but at the end of the month, > I got this > charge for calling an MCU in the Cayman Island > > As an engineer, I can see how the scheme might work, but as a > consumer, I > would have problem with the above scenario. Even if the > endpoint prompts > me > for authorization to call the MCU, I would probably said no > and continued > with my dinner. > > I can see consumer pressure for an option to block the "re-route to > SOMETHING" messages. > > Any opinions? > > > Regards, > > Santo Wiryaman > VideoServer Inc. > +1.781.505.2348 > > > > -----Original Message----- > > From: Klaghofer Karl ICN IB NL IP 7 > [SMTP:Karl.Klaghofer@vs.siemens.de] > > Sent: Monday, February 01, 1999 11:36 AM > > To: Korpi Markku USA; 'wiryaman santo (VideoServer)'; > 'Kumar Vineet > > (Intel)'; 'Freundlich Glen'; 'Walker Dave (Mitel)'; 'Ruditsky Sasha > > (RadVision)'; 'hlt(a)zurich.ibm.com'; Chris Purvis > > Subject: AW: Draft H.450.8 Conference out of Consultation Suppl. > > Serv. for H.323 > > > > To all "conference participants": > > > > I had not yet answered the last comments/proposals > received on Draft > > H.450.8. The attached memo provides a summary. > > > > Thanks for your contributions so far. > > > > Regards, > > Karl > > > > > > <<H4508comments990201.doc>> > > > > > > > > ------------------------------------------------ > > Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL IP7 > > Hofmannstr. 51, D-81359 Munich, Germany > > Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 > > e-mail: karl.klaghofer(a)vs.siemens.de > > > > > > << File: H4508comments990201.doc >> > >

1 0