- sg16-avd - lists.packetizer.com

What does 'exchange' mean and which H.245 message gets to be sent first?
by Frank Derks 03 Apr '01

03 Apr '01

H.323 talks about capability exchange, but it is not clear to me whether exchange really means that communicating endpoints send their capability sets to _each other_ or that one endpoint sends its capability set. An example of this can be found in the below text. It talks about succesfully completing capability exchange, but does this means that the initiating endpoint has sent its capability set and that this was acknowledge by the receiver or does it mean that it has also received the capability set of the other party? 8.2/H.323 states: "Endpoint system capabilities are exchanged by transmission of the H.245 terminalCapabilitySet message. This capability message shall be the first H.245 message sent unless the endpoint is indicating that it understands the parallelH245Control field (see section 8.2.4). If prior to successful completion of terminal capability exchange, any other procedure fails, (i.e. rejected, not understood, not supported) then the initiating endpoint should initiate and successfully complete terminal capability exchange before attempting any other procedure. " The second sentence mandates that the terminalCapabilitySet message be the first message sent (given that "parallelH245Control" is not used). Which "failing procedures" are then being referred to in the third sentence? If terminalCapabilitySet has to be the first message to be sent, does this mean that an endpoint that has not sent a terminalCapabilitySet message yet and receives this message, it first has to send a terminalCapabilitySet message before acknowledging the received capability set? Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

AW: [imtch323implementors] H.323v4 Facility reason in conjunction with H.450apdus
by Klaghofer Karl ICN EN HC ID 71 03 Apr '01

03 Apr '01

Vladimir, With H.450 apdus to be sent within H.323 versions up to v3 your may choose not to include the Facility-UUIE construct at all (but set the "empty" h323-message-body choice instead). The disadvantage with this is that for such messages you miss the Call Identifier. Therefore, it has been agreed to make the Facility-UUIE mandatory with H.323v4, even if only H.450 would have to be transmitted in the H.225.0 message (mainly to get the call identifier). Since the FacilityReason is mandatory in Facility-UUIE, you have to select a reason that fits best to the situation. E.g. use "routeCallToMc" if your scenario is an H.450.2 Transfer to an MCU or use starth245 in conjunction with a FACILITY that also contains an H.450.3 callReroute.Inv if this is what you want to achieve, etc. If none of the reasons are suitable, the new value "transportedInformation" I guess is intended to be used. Value undefinedReason should be accepted always. However, H.225.0 v4 clause 7.4 (third para, last sentense) is misleading, since someone may interpret that the only FacilityReason that is allowed in conjunction with transmitted H.450 apdus may be the new value transportedInformation, which would limit combination of applications significantly. Therefore, the sentense should be rewored to say: "... In H.225.0 version 4 and higher, a sender of an H.450 apdu shall include a Facility-UUIE carrying a callIdentifier field in every Facility message. The FacilityReason field should be set to value transportedInformation if no other reason fields are suitable." I propose to add this clarification to the v4 Implementers Guide. Regards, Karl Klaghofer -----Ursprüngliche Nachricht----- Von: Vladimir Burlik [mailto:vladbph@home.com] Gesendet: Dienstag, 3. April 2001 04:14 An: imtch323implementors(a)mail.imtc.org Betreff: [imtch323implementors] Facility reason Hello all, Could somebody tell me what facility reason should be used when transferring supplementary services messages? For example CallRerouting.Invoke? Thanks Vlad --- You are currently subscribed to imtch323implementors as: Karl.Klaghofer(a)icn.siemens.de To unsubscribe send a blank email to leave-imtch323implementors-35014H(a)mail.imtc.org ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Report of the Launceston meeting
by OKUBO Sakae 03 Apr '01

03 Apr '01

Dear SG16 experts, A little bit belatedly I have placed the meeting report at the following place: http://standard.pictel.com/ftp/avc-site/0103_Lau/AVD-2100a.zip This has the status of "confirmed by participants" with minor editorial refinements from AVD-2100. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* My contract with TAO finished on 31 March. Please change my e-mail address as above, though okubo(a)giti.or.jp will continue to work for some time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

RE: H.248 Implementors' Guide Additions V5 Update
by Alf Heidermark (UAB) 02 Apr '01

02 Apr '01

How do I reference this implementors guide. -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com] Sent: den 2 april 2001 02:32 To: Blatherwick, Peter Cc: megaco ietf; SG16 Subject: Re: H.248 Implementors' Guide Additions V5 Update Hello Peter, The change bars in v5 are relative to the decided version of H.248. There is an Approved Implementors' Guide which you should look at see td-plen 39 from the Geneva 12/00 SG16 meeting. It contains approved changes up until the 12/00. The implementors' guide additions v5 contains non-approved changes from 12/00 until now. Regards, Christian "Blatherwick, Peter" wrote: > > Hi Christian: > > Quick questions (apologies if I have just been out of > the loop for too long). > > - What are the change bars in v5 relative to? > > - Is there a complete Implementors Guide to look at, > including proposed additions. If not, where can I > locate the latest version that the proposed additions > would apply to? > > Cheers, > Peter Blatherwick > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Thursday, March 29, 2001 23:28 > To: megaco ietf; SG16 > Subject: H.248 Implementors' Guide Additions V5 Update > > G'Day all, > > I have come up with an interim version of the H.248 Implementors' Guide > Additions v5. It contains additional correction to ones reviewed at the > SG16 Launceston meeting. > > It can be found at: > ftp://standard.pictel.com/avc-site/Incoming/ > filenames: > TD-xxx_H248_Implementors_Additions_v5.doc > TD-xxx_H248_Implementors_Additions_v5.pdf > > Please check it for correctness and that it contains the points > discussed on the list. There were also some corrections added that were > not discussed on the list. If you have an issue please propose a > solution giving the wording that you would like to see. As mentioned in > the introduction this document is liable to change until final approval. > > v4 was my own edition and was not published to any external network/list > so please don't look for it. > > Let the editor bashing begin. > > Cheers, Christian

1 0

RE: H.248 Implementors' Guide Additions V5 Update
by Blatherwick, Peter 01 Apr '01

01 Apr '01

Hi Christian: Quick questions (apologies if I have just been out of the loop for too long). - What are the change bars in v5 relative to? - Is there a complete Implementors Guide to look at, including proposed additions. If not, where can I locate the latest version that the proposed additions would apply to? Cheers, Peter Blatherwick -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com] Sent: Thursday, March 29, 2001 23:28 To: megaco ietf; SG16 Subject: H.248 Implementors' Guide Additions V5 Update G'Day all, I have come up with an interim version of the H.248 Implementors' Guide Additions v5. It contains additional correction to ones reviewed at the SG16 Launceston meeting. It can be found at: ftp://standard.pictel.com/avc-site/Incoming/ filenames: TD-xxx_H248_Implementors_Additions_v5.doc TD-xxx_H248_Implementors_Additions_v5.pdf Please check it for correctness and that it contains the points discussed on the list. There were also some corrections added that were not discussed on the list. If you have an issue please propose a solution giving the wording that you would like to see. As mentioned in the introduction this document is liable to change until final approval. v4 was my own edition and was not published to any external network/list so please don't look for it. Let the editor bashing begin. Cheers, Christian

2 1

Issues and Solutions: H.MMS.1 (Mobility for H.323)
by Roy, Radhika R, ALCOO 01 Apr '01

01 Apr '01

Hi, Folks: Further to my earlier message, I am sending a note related to the fundamental issues of the present H.MMS.1 (Mobility for H.323) draft. The note also includes the proposed solutions for all those issues. Please note that we discussed all those issues in the last November'00 SG16 meeting. We do not want that the same should be repeated in the upcoming SG16 May-June'01 meeting. In this regard, I also draw the special attention of editors of H.MMS.1 and H.225.0 Annex G, Rapporteurs of Q5/16 and Q2/16, and Mr. Tosco as well. Issues and Solutions of H.MMS.1 (Mobility for H.323): 1. Problem A: The document (Section 10, H.NMS.1 Mobility for H.323 Multimedia Systems [MD-112, AVD-2053a]) still shows that HLF, VLF, and AuF, as if, are another sets of H.323 functional entities (like GKs, BEs, MCUs and terminals) that are entitled to use H.323/H.225.0 (RAS, Q.931/932)/H.225.0 Annex G protocols. However, like many other services such as directory, billing, and others, HLF, VLF, and AuF are the backend services and the protocols used by those entities must NOT be called a part of the H.323/H.225.0 protocol because these backend services protocols can be used by other application protocols (e.g., H.234, H.310) as well. Problem B: If the mobility management protocol is called H.225.0 Annex G, it cannot be used or extended for the global mobility management purpose (e.g., H.MMS.2). Problem C: More functionalities like Authentication, Charging/Billing, Directory, Policy, and other entities are needed for mobile (and even for non-mobile) functions. We cannot use make them as a part of H.323 protocol. Problem D: We cannot make one HLF/VLF/AuF protocol for H.323, another HLF/VLF/AuF protocol for H.324, and another for H.310, and another for IMT-2000. The same protocols MUST be allowed to be used by any applications whenever needed without providing any restrictions. Solution for problems A, B, C, and D: No functional entity like HLF, VLF, AuF, Charging/Billing, Policy, Directory or others will be defined as the H.323 functional entity. Rather, each of this entity will be a backend functional entity and the protocol among these entities must be independent of the H.323/H.225.0 Annex G protocol. The protocol used among HLF, VLF, and AuF entities may have all capabilities, functionalities and features as described in the document, but MUST be called a different protocol (e.g., M.management) so that all application protocols including H.323 will be at liberty to use it. So, the said protocol MUST NOT be called H.225.0 Annex G or its extension. In other words, we are changing the name only (not the capabilities, functions, or features). Similar will be the case for Charging/Billing, Policy, Directory or others. 2. Problem: Mobility management procedures (Section 10, H.NMS.1 Mobility for H.323 Multimedia Systems [MD-112, AVD-2053a (Figure 11a)]) still indicate that there is only one HLF that communicates directly with the VLFs located in two separate administrative domains. This breaks the fundamental concept of the administrative domains as standardized in H.323 because an administrative domain is autonomous and can communicate only through the BEs (with one HLF, this principle is violated and breaks the basic foundation of H.225.0 Annex G). Solution: Similar to inter-zone (e.g., Figure 13 of AVD-2053a), the communications between the two administrative domains MUS be made via the BEs no matter whether there is one or multiple HLFs. Communications scenarios with at least one HLF in each administrative domain needs to be shown. Best regards, Radhika R. Roy AT&T Technology Consultant Room 3D-2C09 200 S. Laurel Avenue Middletown, NJ 07748 +1 732 420 1580 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

FW: List Last Call On draft-rosen-megaco-namepatterns-00.txt
by Tom-PT Taylor 30 Mar '01

30 Mar '01

FYI -----Original Message----- From: Taylor, Tom-PT [NORSE:B881:EXCH] Sent: Friday, March 30, 2001 1:45 PM To: 'megaco' Subject: List Last Call On draft-rosen-megaco-namepatterns-00.txt I would like to make an official Last Call for draft-rosen-megaco-namepatterns-00.txt, to expire Friday, April 15. After that I will forward it to the IESG and register the package with IANA. I do need list direction on whether it should be Informational or Standards Track. Tom Taylor Multimedia Control and Applications Standards Ph. +1 613 736 0961 taylor(a)nortelnetworks.com

1 0

FW: List Last Call For draft-boyle-megaco-tonepkgs-02.txt
by Tom-PT Taylor 30 Mar '01

30 Mar '01

FYI -----Original Message----- From: Taylor, Tom-PT [NORSE:B881:EXCH] Sent: Friday, March 30, 2001 2:43 PM To: 'megaco' Subject: List Last Call For draft-boyle-megaco-tonepkgs-02.txt I would like to announce Last Call for draft-boyle-megaco-tonepkgs-02.txt, to end Friday, April 15. This draft is a candidate for reference by the decided Q.1950, so the authors would like it to go forward in Standards Track. It will not move forward unless I have comments from other parties. Please have a look. Tom Taylor Multimedia Control and Applications Standards Ph. +1 613 736 0961 taylor(a)nortelnetworks.com

1 0

How do I sign up to this list?
by Mart Nurmet 30 Mar '01

30 Mar '01

Thanks! -Mart

2 1

Call for participation for ICN01 and Call for Papers for ECUMN'02
by conf＠UHA.FR 30 Mar '01

30 Mar '01

Dear All, Please feel free to circulate to interested colleagues: 1. The preliminary program of ICN01 (International Conference on Networking) (see http://iutsun1.colmar.uha.fr/ICN01.html ) which will be held at Colmar, France, from Monday July 9, 2001 to Friday July 13, 2001. If you would like to Chair a session during ICN01, please contact lorenz(a)ieee.org 2. The call for papers of ECUMN'02 (see http://iutsun1.colmar.uha.fr/ECUMN02.html ) scheduled from April 8 to April 10, 2002. The deadline for this CfP is September 1, 2001. Accept our sincere apologies if you receive multiple copies. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Updates of H.MMS.1 (Mobility for H.323)
by Roy, Radhika R, ALCOO 29 Mar '01

29 Mar '01

Hi, Ernst: Per AVD-2100 Version 1 (March 9, 2001 - Launceston Meeting), many contributions have been accepted for proposed modifications of the document (H.MMS.1 - H.323 Mobility). When will it be the right time to post the latest UPDATED document in the SG web site (http://standard.pictel.com/ftp/avc-site/0103_Lau/)? If you do so, we can bring contributions to the upcoming SG16 meeting in May-June'01 showing where the modifications need to be made. Please note that the contributions need to be approved by the respective Govt of each country. That is, if the update document is posted by April 15, 2001, then we will have enough time to go through the document and write contributions and take the approval from the Dept of State by the end of April (may April 30). We would appreciate if you would kindly post the updated document not later than April 15, 2001. Thanks in advance, Radhika R. Roy Technology Consultant AT&T Room 3D-2C09 200 S. Laurel Avenue Middletown, NJ 07748 +1 732 420 1580 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Omission in H.245 v7
by Francois Audet 28 Mar '01

28 Mar '01

Actually, this was done on purpose. It was also apparently discussed in the last meeting (which I didn't attend). The way it works with fastStart is that after (or at the same time) as fastStart is initiated, you'll have to initiate H.245 Terminal capability negotiation, and that is where the dynamic payload type will be exchanged. There are procedures in H.323v4 that allows you to do terminal capability negotiation in parrallel with fastStart. The whole idea is to stop adding things to fastStart. -----Original Message----- From: Rajesh Kumar [mailto:rkumar@CISCO.COM] Sent: Wednesday, March 28, 2001 18:56 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Omission in H.245 v7 Dear ITU SG16 team, I just came across what I believe is an unintended omission in H.245 v7. Although you have added support for rfc2833 to the 'terminal capability set' command, you have not included it as one of the CHOICEs for the dataType object in the Open Logical Channel command. The upshot is that you cannot dynamically assign a payload type to rfc2833 telephone events in the 'fast connect' scenario where the 'terminal capability set' command is not used. For all practical purposes, this means that you either statically provision the rfc2833 capability, which the IETF has decried, or you do not use Fast Connect when you support telephone events. All indications are that this is a minor, unintended omission on the part of SG16: nobody has discovered it as yet. It can be fixed easily. The Open Logical Channel dataType object points to the capability objects anyway, and there is no reason to omit AudioTelephonyEventCapability as an instance of the dataType object. How should we go about fixing this - H.245 is still in draft, although there is preliminary approval of it? Thanks. Rajesh ------------------------------------- Dr. Rajesh Kumar, Principal Engineer Cisco Voice Technology Center Tel: 408-527-0811, Fax: 408-853-1101 Epage: mailto:rkumar@epage.cisco.com ------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Omission in H.245 v7
by Rajesh Kumar 28 Mar '01

28 Mar '01

Dear ITU SG16 team, I just came across what I believe is an unintended omission in H.245 v7. Although you have added support for rfc2833 to the 'terminal capability set' command, you have not included it as one of the CHOICEs for the dataType object in the Open Logical Channel command. The upshot is that you cannot dynamically assign a payload type to rfc2833 telephone events in the 'fast connect' scenario where the 'terminal capability set' command is not used. For all practical purposes, this means that you either statically provision the rfc2833 capability, which the IETF has decried, or you do not use Fast Connect when you support telephone events. All indications are that this is a minor, unintended omission on the part of SG16: nobody has discovered it as yet. It can be fixed easily. The Open Logical Channel dataType object points to the capability objects anyway, and there is no reason to omit AudioTelephonyEventCapability as an instance of the dataType object. How should we go about fixing this - H.245 is still in draft, although there is preliminary approval of it? Thanks. Rajesh ------------------------------------- Dr. Rajesh Kumar, Principal Engineer Cisco Voice Technology Center Tel: 408-527-0811, Fax: 408-853-1101 Epage: mailto:rkumar@epage.cisco.com ------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Firewall/NAT Crossing by H.323/H.248
by Alok Dubey (OCS-BLRAKS-AVS) 27 Mar '01

27 Mar '01

Just to add to the below.. NAT and firewalls are no problem per se that the source IP is translated and the destination IP is that of the actual destination itself.. but for a proxy we have application based stuff happening.. eg http proxy or ftp proxy. What i would like to know is this.. 1. Is there a way that we can make our proxies SIP aware or H.323 aware.. 2. If we are using a NAT or a firewall then does it actually support the SIP prioritising mechanisms.. eg.. when i set up a network i tend to prioritise voice traffic by in turn prioritizing the RTP traffic(for voice quality) or SIP traffic.. (for call setup etc) Now will firewall softwares support this QoS / IP Priority stuff? else this will be a scenario where half my netowrk components are aware of Prioritising the traffic and half are not. Rgds Alok Dubey -----Original Message----- From: Alok Dubey (OCS-BLRAKS-AVS) Sent: Tuesday, March 27, 2001 1:47 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: RE: Firewall/NAT Crossing by H.323/H.248 Hi, Can anyone point to the RFC / draft whih tells me the standard encapsualtion / message format for data flows across firewalls/proxies/NATs? ..im sure once that is figured out .. instead of making firewalls/ NAts H.323 aware, one could simply just change the policies to allow forwarding of H.323 traffic like ordinary HTTP/FTP traffic....by opening the corresponding ports.. Rgds Alok Dubey ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Firewall/NAT Crossing by H.323/H.248
by Alok Dubey (OCS-BLRAKS-AVS) 27 Mar '01

27 Mar '01

Hi, Can anyone point to the RFC / draft whih tells me the standard encapsualtion / message format for data flows across firewalls/proxies/NATs? ..im sure once that is figured out .. instead of making firewalls/ NAts H.323 aware, one could simply just change the policies to allow forwarding of H.323 traffic like ordinary HTTP/FTP traffic....by opening the corresponding ports.. Rgds Alok Dubey ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Firewall/NAT Crossing by H.323/H.248
by Roy, Radhika R, ALCOO 26 Mar '01

26 Mar '01

Euchner: Steve Davies has provided another URL to me. It is working for me. Hope that it will work for all of you. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com -----Original Message----- From: Steve Davies [mailto:SDavies@Ridgeway-Sys.com] Sent: Thursday, March 22, 2001 2:45 PM To: Roy, Radhika R, ALCOO Subject: RE: Firewall/NAT Crossing by H.323/H.248 Radhika, The document is going through the IETF draft process - we sent it on Tuesday. In the meantime its available from www.vxserver.com/standards. We will be at the SIP discussion tomorrow. Thanyou - we think it is a better solution too. The PIA does not need to be application aware (so its future proof), the PS takes care of that. The PIA can be client software (i.e a shim to the application) or a standalone unit. It scales down as well as up. regards Steve Steve Davies Chief Technical Officer Ridgeway Systems and Software Email: mailto:sdavies@ridgeway-sys.com Web: www.ridgeway-sys.com Tel B: +44 (0) 118 938 1114 Tel H: +44 (0) 1285 770979 -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@icn.siemens.de] Sent: Monday, March 26, 2001 9:38 AM To: Roy, Radhika R, ALCOO; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: AW: Firewall/NAT Crossing by H.323/H.248 Radhika, thanks for pointing to this interesting draft. However, I was unable to obtain that document; http://www.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-00.txt <http://www.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-00.txt> is not successful. Would someone be so kind and send it to me? Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Roy, Radhika R, ALCOO [SMTP:rrroy@ATT.COM] Gesendet am: Donnerstag, 22. März 2001 05:18 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: Firewall/NAT Crossing by H.323/H.248 Folks: The following Internet draft (draft-davies-fw-nat-traversal-00.txt) deals with the proposal how H.323, H.248, and other applications (e.g., SIP) can cross the firewalls and NATs that do not require any changes in NATs and firewalls. I would request the members that it may be worthwhile to look into the proposal. (I would also propose the authors to see whether this can be presented in the ITU-T SG16 for possible examination. If attendance is a problem by the authors, whether Rapporteurs, as they did in the past, can help in collaboration with the authors in the presenting the proposal.) Best regards, Radhika R. Roy AT&T -----Original Message----- From: Steve Davies [mailto:SDavies@Ridgeway-Sys.com] Sent: Tuesday, March 20, 2001 8:45 PM To: mshore(a)cisco.com Cc: sob(a)harvard.edu; Steve Davies; midcom(a)ietf.com; sip(a)lists.bell-labs.com Subject: [SIP] Contribution to Midcom WG Melinda, Please excuse this email at the 11th hour. I've taking the liberty of copying it to the SIP and Midcom WGs in order to maximise the opportunity for discussion. Ridgeway Systems & Software have just completed an Internet draft for the traversal of non-protocol aware firewalls and NATs by session-oriented protocols such as H.323, SIP and H.248/Megaco. The draft is the culmination of the last 2 years of research and development within Ridgeway. The methods outlined in the draft have been implemented and proven to work. The main benefit to the Internet and Telecommunications community of the method outlined in this draft is that it is protocol agnostic - a single method can carry multiple protocols. Until it is available through the system it is available from http://www.vxserver.com/standards/ - username is 'standards' password is 'stevedavies'. The method outlined in the draft is probably ahead of where Midcom is at this point. I bring it to your attention now because I see similar initiatives within the SIP WG and because I would like to suggest to the Midcom WG that there are at least 2 classes of problem with potentially multiple solutions to address and capture. My basic premise is that it is not just a FW/NAT problem to address, but a FW/NAT + deployment set of problems. Class A: This class of problem is characterised by the fact that it is not possible or it is undesirable to upgrade the firewalls and NAT devices. Typically, NAPT is being used and Internet data and voice/video packets are transported on the same network (at some point, e.g. the LAN). Security must not be compromised. Examples deployments include residential and enterprise access to the Converged Network via an ISP. The Traversal method Ridgeway has developed addresses this class of problem. Class B: This class of problem is characterised by the fact that it is possible to upgrade existing or deploy new equipment to transport voice/video over IP. ALGs in firewalls and NATs is one solution to this class of problem. It seems that the approach within Midcom is to formalise and abstract ALGs such that one method suits all protocols. However, this doesn't address deployments in Class A. My colleague, Pete Cordell, and I will be in Minneapolis from Wednesday thru Friday and shall be attending the Midcom WG where we hope such requirements and issues will be raised and captured. Please feel free to contact me should you want to discuss this offline. Kindest regards Steve Steve Davies Chief Technical Officer Ridgeway Systems and Software Email: mailto:sdavies@ridgeway-sys.com Web: www.ridgeway-sys.com Tel B: +44 (0) 118 938 1114 Tel H: +44 (0) 1285 770979 US cell: +1 512 771 7160 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request(a)cs.columbia.edu with "subscribe" in the body. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: Firewall/NAT Crossing by H.323/H.248
by Euchner Martin 26 Mar '01

26 Mar '01

Radhika, thanks for pointing to this interesting draft. However, I was unable to obtain that document; http://www.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-00.txt <http://www.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-00.txt> is not successful. Would someone be so kind and send it to me? Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Roy, Radhika R, ALCOO [SMTP:rrroy@ATT.COM] Gesendet am: Donnerstag, 22. März 2001 05:18 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: Firewall/NAT Crossing by H.323/H.248 Folks: The following Internet draft (draft-davies-fw-nat-traversal-00.txt) deals with the proposal how H.323, H.248, and other applications (e.g., SIP) can cross the firewalls and NATs that do not require any changes in NATs and firewalls. I would request the members that it may be worthwhile to look into the proposal. (I would also propose the authors to see whether this can be presented in the ITU-T SG16 for possible examination. If attendance is a problem by the authors, whether Rapporteurs, as they did in the past, can help in collaboration with the authors in the presenting the proposal.) Best regards, Radhika R. Roy AT&T -----Original Message----- From: Steve Davies [mailto:SDavies@Ridgeway-Sys.com] Sent: Tuesday, March 20, 2001 8:45 PM To: mshore(a)cisco.com Cc: sob(a)harvard.edu; Steve Davies; midcom(a)ietf.com; sip(a)lists.bell-labs.com Subject: [SIP] Contribution to Midcom WG Melinda, Please excuse this email at the 11th hour. I've taking the liberty of copying it to the SIP and Midcom WGs in order to maximise the opportunity for discussion. Ridgeway Systems & Software have just completed an Internet draft for the traversal of non-protocol aware firewalls and NATs by session-oriented protocols such as H.323, SIP and H.248/Megaco. The draft is the culmination of the last 2 years of research and development within Ridgeway. The methods outlined in the draft have been implemented and proven to work. The main benefit to the Internet and Telecommunications community of the method outlined in this draft is that it is protocol agnostic - a single method can carry multiple protocols. Until it is available through the system it is available from http://www.vxserver.com/standards/ - username is 'standards' password is 'stevedavies'. The method outlined in the draft is probably ahead of where Midcom is at this point. I bring it to your attention now because I see similar initiatives within the SIP WG and because I would like to suggest to the Midcom WG that there are at least 2 classes of problem with potentially multiple solutions to address and capture. My basic premise is that it is not just a FW/NAT problem to address, but a FW/NAT + deployment set of problems. Class A: This class of problem is characterised by the fact that it is not possible or it is undesirable to upgrade the firewalls and NAT devices. Typically, NAPT is being used and Internet data and voice/video packets are transported on the same network (at some point, e.g. the LAN). Security must not be compromised. Examples deployments include residential and enterprise access to the Converged Network via an ISP. The Traversal method Ridgeway has developed addresses this class of problem. Class B: This class of problem is characterised by the fact that it is possible to upgrade existing or deploy new equipment to transport voice/video over IP. ALGs in firewalls and NATs is one solution to this class of problem. It seems that the approach within Midcom is to formalise and abstract ALGs such that one method suits all protocols. However, this doesn't address deployments in Class A. My colleague, Pete Cordell, and I will be in Minneapolis from Wednesday thru Friday and shall be attending the Midcom WG where we hope such requirements and issues will be raised and captured. Please feel free to contact me should you want to discuss this offline. Kindest regards Steve Steve Davies Chief Technical Officer Ridgeway Systems and Software Email: mailto:sdavies@ridgeway-sys.com Web: www.ridgeway-sys.com Tel B: +44 (0) 118 938 1114 Tel H: +44 (0) 1285 770979 US cell: +1 512 771 7160 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request(a)cs.columbia.edu with "subscribe" in the body. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

None
by Bellala, Kasipathi (CTS) 24 Mar '01

24 Mar '01

_________________________________________ Kasipathi Bellala Telecom Group Cognizant Technology Solutions Ph : 2540555 X: 7026 ***************************************** Keep Trying...to Get....Success Keep Smiling..to Get....Happiness Keep Loving..to Get....Peace _________________________________________

1 0

PV2001 Call for Participation & Advance Program
by PV2001 23 Mar '01

23 Mar '01

CALL FOR PARTICIPATION Please mark your calendar to attend the PV-2001 for a rewarding experience in the field of "Advanced Packet Video” The 11th International Packet Video Workshop (PV-2001) will be held on 30 April - 1 May 2001 in Kyongju, Korea (located in 350-kilometer southeast of Seoul), which was the capital city of ancient Korea (A.D 676-A.D 935). The workshop is devoted to presenting technological advancements and innovations in video transmission over packet networks, in particular, the Internet. Packet Video Workshops have been unique in providing a common ground for people from video coding and networking fields. Presentations on theory and practice, standards activities, and business and consumer applications are encouraged. In 2001, the workshop is scheduled to take place in the week following Picture Coding Symposium (PCS-2001) which will be held in Seoul on 25-27 April 2001. We cordially invite you to take part in this workshop. Further details and updated information for PV-2001 can be found at http://pv2001.kaist.ac.kr. With broad and active participations from all over the world, we are convinced that the PV-2001 will be very successful. Program Overview: The session program will have 8 sessions with 56 papers from 16 countries. This will be further highlighted by two invited talks and one panel discussion. The 23 papers will be presented by oral presentation and the other papers will be presented by poster presentation. Topic Areas: - Video streaming over Internet - Network adaptive video coding and transport - Error/loss resilient video coding and transport - Layered coding for error resilience and heterogeneous networks - Rate control for VBR video - Statistical multiplexing for greater network and terminal utilization - Congestion control and bandwidth allocation - Efficient transcoding for heterogeneous networks - Error concealment and post processing - Traffic shaping for efficient network and terminal utilization - Performance modeling and evaluation for packet video network - Interstream synchronization for multiple video presentations - Packetized video for wireless/mobile systems - Packetized video for home LAN's - Multicasting, MBONE applications - International standards: MPEG-4, MPEG-7, H.26L, H.323, RTP, RTSP, SIP, SDP - Terminal and server architecture for Internet TV - Implementations and commercial applications Invited Speakers: - Dr. Ya-Qin Zhang, Microsoft Research in Beijing, China "Convergence of Multimedia, Wireless and Internet” - Dr. Civanlar M. Reha, AT&T Labs Research, U.S.A. "Internet Video - Protocols & Applications” Registration Information: Category By March 31, 2001 After March 31, 2001 Regular Registration Plan 1 US$300 US$350 Plan 2 US$225 US$275 Banquet for Accompanying Person US$60/each Additional CD-ROM Proceedings US$50/each Special Bus Transportation (from Seoul to Kyongju) US$80/each PV and PCS-2001 Registration By March 31, 2001 After March 31, 2001 Regular Registration Plan 3: PCS Regular+PV Plan 1 US$650 US$750 Student Registration Plan 4: PCS Plan A+PV Plan 2 US$450 US$550 Plan 5: PCS Plan B+PV Plan 2 US$390 US$490 Important Date: March 31, 2001 Advance Registration & Hotel Reservation PCS-2001 Secretariat: Further inquiries can be made at: Tel: +82-42-472-7460 Fax: +82-42-472-7459 Email: pv(a)pv2001.kaist.ac.kr

1 0

RE: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Francois Audet 22 Mar '01

22 Mar '01

> Chris, > > My opinion is that, if you do Fast Connect, there is no need > to start H.245. > I agree that support shall be there, so that either end may > initiate H.245 > for whatever reason, but if using Fast Connect, opening the > H.245 channel > should be optional. > Correct. Unless you need to support any H.245 message, including sending DTMF. > Also, as I suggested earlier, given that tunneling is the > "norm" now, one > could argue that the H.245 channel is already there... we just don't > exchanges messages over it :-) (Yes, I know.. that's a weak > argument.) > > Paul > > ----- Original Message ----- > From: "Chris Wayman Purvis" <cwp(a)ISDN-COMMS.CO.UK> > To: <ITU-SG16(a)mailbag.cps.INTEL.COM> > Sent: Thursday, March 22, 2001 6:27 AM > Subject: Re: Conflicting text in H.323 concerning the > requirement for esta > blishing a H.245 control channel?? > > > > Roni, Frank, Paul Jones et al, > > > > Having reread 8.1.7.2 (as referenced by Roni) I believe > that Frank was > right > > all along in saying there is a conflict. 8.1.7.2 saying > that a device > "may" > > establish an H.245 session at any point during a call is, I > would argue, > > clearly at odds with 6.2.8 stating that such a session "shall" be > > established. After all, having not bothered to bring one > up until an > > instant before the end of the call (clearly permitted by > 8.1.7.2), why > > create one at that stage (except because 6.2.8 tells you to...)? > > > > There is an alternative reading: the implication of 6.2.8 > is that some > sort > > of H.245 session should start immediately (the start and > end are the only > > "special" times in an ordinary call, so if you must start > one it's pretty > > well a requirement to do it immediately). What I don't > recall is whether > > it's permitted to drop an H.245 session during a call. I > think it is. So > > is there an alternative reading, saying "start the H.245 > channel at the > > beginning of the call, but you may drop and restart it as > you like during > > the call"? > > I don't like this reading, though, it's probably the worst > of all worlds. > > > > However I don't like the delay of setting up an H.245 > session being added > to > > the time taken to transmit the first DTMF tone in a call either... > > > > Paul, > > > > I think this really needs tidying up one way or another - I > think it's a > job > > for the implementors guide... Consensus currently seems to > be against me, > > and to be that we should dump the relevant text in 6.2.8. > > > > Regards, > > Chris > > > > Roni Even wrote: > > > > > Chris, > > > About your comments > > > > > > 1. B can make A start H.245 by using facility message with reason > > > startH.245. See H.323 8.2.3 Switching to a separate > H.245 connection. > > > 2. About 6.2.8 I agree that it states the H.245 shall be > established, it > > > does not say when. The when is mentioned in 8.1.7.2. > > > Roni Even > > > > > > > > > -----Original Message----- > > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > > Sent: Wednesday, March 21, 2001 3:31 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: Conflicting text in H.323 concerning the > requirement for > > > esta blishing a H.245 control channel?? > > > > > > > > > Roni, > > > > > > > > > > > >> H.323 mandates the support of H.245 for end points that > comply with the > > >> standard. It does not mean, when using fast connect that > it must be > open > > >> immediately but can be opened at a later stage by any side. > > > > > > Except that it states exactly the opposite in the section under > discussion. > > > > > > Also, consider the following scenario: > > > Two endpoints, A and B. B does not support tunnelled > H.245. A calls B, > > > without giving any H.245 address in its Setup message. B > accepts the > call > > > on the basis of fastStart. No H.245 channel is set up, > as you suggest. > > > Suppose now B wishes to send a UII (or any H.245 message) > to A. It > can't. > > > It can't set up the H.245 channel. A could set it up, > but doesn't see > the > > > need. > > > > > > > > >> The reason for > > >> mandating H.245 is to supply a control channel and is > important for > > > > > > gateways > > > > > >> and MCUs as well as for control functions in point to > point calls such > as > > >> Video fast updates. H.323 annex F defines a simple end > point that has > > > > > > H.245 > > > > > >> support as optional. > > >> I do not see the conflict between 6.2.8 and 8.1.7 if > 6.2.8 means that > you > > >> have to support it but not to actually open it as in simple fast > connect > > >> calls. > > > > > > But 6.2.8 does not mean that. It clearly states that an > H.245 channel > SHALL > > > be opened. > > > > > > > > >> As for DTMF you can use the DTMF RTP payload to have it > in band instead > of > > >> H.245. > > > > > > If the person you're talking to happens to support this. > Of course you > > > don't know whether or not it does if you haven't exchanged TCS. > > > > > > Please let's not break this! > > > > > > Regards, > > > Chris > > > > > > > > > > > >> -----Original Message----- > > >> From: Agboh, Charles [mailto:charles.agboh@EBONE.COM] > > >> Sent: Tuesday, March 20, 2001 6:59 PM > > >> To: ITU-SG16(a)MAILBAG.INTEL.COM > > >> Subject: Re: Conflicting text in H.323 concerning the > requirement for > > >> esta blishing a H.245 control channel?? > > >> > > >> > > >> Chris, > > >> > > >> Part of establishing a "point-to-point" call involves > opening 2 TCP > > >> connnections using the Fast Connect procedure as you > described it. If > > > > > > that > > > > > >> is the case, then the extract from H.323v2 below is misleading(I > believe). > > >> > > >> H.323v2: 8.1.7 Fast Connect Procedure > > >> > > >> "..... The Fast Connect procedure allows the endpoints > to establish a > > > > > > basic > > > > > >> point-to-point call with as few as one round-trip > message exchange, > > > > > > enabling > > > > > >> immediate media stream delivery upon call connection." > > >> > > >> BR, > > >> Charles > > >> > > >> > > >>> -----Original Message----- > > >>> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > >>> Sent: Tuesday, March 20, 2001 5:47 PM > > >>> To: ITU-SG16(a)MAILBAG.INTEL.COM > > >>> Subject: Re: Conflicting text in H.323 concerning the > requirement for > > >>> esta blishing a H.245 control channel?? > > >>> > > >>> > > >>> Charles, > > >>> > > >>> It does NOT defeat ANY of the stated aims of FastConnect. > > >>> These aims were to get agreed media channels in both > > >>> directions open as > > >>> quickly as possible. Doing FastStart AND H.245 gives > you your media > > >>> quickly, and means you have the power of H.245 thereon. > > >>> > > >>> In-band DTMF transfer may be used. If you happen to be using > > >>> a codec that > > >>> supports it. If you assume it when you're using an > > >>> unsuitable codec you'll > > >>> have a problem. Which is a reason for using H.245 capability > > >>> negotiation. > > >>> > > >>> Regards, > > >>> Chris > > >>> > > >>> Agboh, Charles wrote: > > >>> > > >>> > > >>> > > >>>> which defeats the whole point of having a Fast Connect > > >>> > > >>> procedure (FS + > > >>> > > >>> > > >>>> H.245). Why isn't in-band- DTMF transfer used instead (in FS)? > > >>>> > > >>>> -Charles > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: Frank Derks [mailto:frank.derks@PHILIPS.COM] > > >>>>> Sent: Tuesday, March 20, 2001 4:40 PM > > >>>>> To: ITU-SG16(a)MAILBAG.INTEL.COM > > >>>>> Subject: Re: Conflicting text in H.323 concerning the > > >>>> > > >>> requirement for > > >>> > > >>> > > >>>>> establishing a H.245 control channel?? > > >>>>> > > >>>>> > > >>>>> Chris, > > >>>>> > > >>>>> I thought I was being clear enough, so let me try again. > > >>>>> 6.2.8/H.323 states > > >>>>> that an enpoint must open one (and exactly one) H.245 control > > >>>>> channel. When > > >>>>> Fast Connect is being used, I assume that the intention is > > >>>>> that no such control > > >>>>> channel is opened. > > >>>>> > > >>>>> To be compliant with 6.2.8/H,323 I would have to open a H.245 > > >>>>> control channel > > >>>>> irrespective of which type of H.245 procedures I will be > > >>>>> using. So if I intend > > >>>>> to use Fast Start (and assuming that the other party also > > >>>>> supports this), I > > >>>>> still have to open a H.245 control channel. > > >>>>> > > >>>>> Frank > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> cwp(a)isdn-comms.co.uk on 20-03-2001 15:17:14 > > >>>>> To: Frank Derks/HVS/BE/PHILIPS@EMEA2 > > >>>>> cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP > > >>>>> Subject: Re: Conflicting text in H.323 concerning the > > >>>>> requirement for establishing a H.245 control channel?? > > >>>>> Classification: > > >>>>> > > >>>>> Frank, > > >>>>> > > >>>>> Why do you consider this text to be "conflicting"? > > >>>>> Specifically, with what does it conflict? > > >>>>> > > >>>>> Regards, > > >>>>> Chris > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>> 6.2.8/H.323 states: "The endpoint shall establish exactly > > >>>>> > > >>> one H.245 > > >>> > > >>> > > >>>>>> Control Channel for each call that the endpoint is > > >>>>> > > >>>>> participating in." > > >>>>> > > >>>>> > > >>>>> > > >>>>>> 8.1.7/H.323 never states that when Fast Connect is being > > >>>>> > > >>> used such a > > >>> > > >>> > > >>>>>> control channel should be established. As far as I > understand the > > >>>>>> mechanism this is only required to switch to "normal" H.245 > > >>>>> > > >>>>> procedures. > > >>>>> > > >>>>> > > >>>>> > > >>>>>> It would seem that section 6.2.8 should be rephrased to > > >>>>> > > >>>>> make clear that > > >>>>> > > >>>>> > > >>>>> > > >>>>>> the H.245 control channel shall only be established when > > >>>>> > > >>>>> "normal" H.245 > > >>>>> > > >>>>> > > >>>>> > > >>>>>> procedures are being followed and not in the fast > connect case. > > >>>>>> > > >>>>>> Frank > > >>>>> > > >>>>> -- > > >>>>> Dr Chris Purvis -- Development Manager > > >>>>> ISDN Communications Ltd, The Stable Block, Ronans, > Chavey Down Road > > >>>>> Winkfield Row, Berkshire. RG42 6LY ENGLAND > > >>>>> Phone: +44 1344 899 007 > > >>>>> Fax: +44 1344 899 001 > > >>>>> > > >>>>> > > >>>> > > >>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >>> > > >>> > > >>>>> For help on this mail list, send "HELP ITU-SG16" in a > message to > > >>>>> listserv(a)mailbag.intel.com > > >>>>> > > >>>> > > >>>> > > >>>> > > >>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >>> > > >>> > > >>>> For help on this mail list, send "HELP ITU-SG16" in a > message to > > >>>> listserv(a)mailbag.intel.com > > >>> > > >>> > > >>> -- > > >>> Dr Chris Purvis -- Development Manager > > >>> ISDN Communications Ltd, The Stable Block, Ronans, > Chavey Down Road > > >>> Winkfield Row, Berkshire. RG42 6LY ENGLAND > > >>> Phone: +44 1344 899 007 > > >>> Fax: +44 1344 899 001 > > >>> > > >>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >>> For help on this mail list, send "HELP ITU-SG16" in a message to > > >>> listserv(a)mailbag.intel.com > > >>> > > >> > > >> > > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> For help on this mail list, send "HELP ITU-SG16" in a message to > > >> listserv(a)mailbag.intel.com > > >> > > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >> For help on this mail list, send "HELP ITU-SG16" in a message to > > >> listserv(a)mailbag.intel.com > > > > > > > > > > > > -- > > > Dr Chris Purvis -- Development Manager > > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey > Down Road > > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > > Phone: +44 1344 899 007 > > > Fax: +44 1344 899 001 > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > > > -- > > Dr Chris Purvis -- Development Manager > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > Phone: +44 1344 899 007 > > Fax: +44 1344 899 001 > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

New Editor of H.225.0 and the H.323-Series Implementers Guide
by Paul E. Jones 22 Mar '01

22 Mar '01

Folks, As many of you know, Rich Bowen has changed roles within the company and now has little time to continue as editor of H.225.0. I would like to thank Rich for his hard work on version 4-- I know he spent a few nights without sleep to finish that document! (Perhaps that's the *real* reason he chose to step down.) Vivek Bhargava (Cisco), who has been working on H.323 for a number of years, expressed an interest to assume responsibility for H.225.0v5. In discussing the work with him, he also expressed interest in taking the Implementers Guide forward. As many of you know, it is very hard to find an editor for the Implementers Guide, so he was quickly awarded the job before he changed his mind :-) Seriously, Vivek is very thorough and pays close attention to detail. I believe he will serve well as editor of these two documents. His e-mail address is vbhargava(a)packetizer.com. Feel free to call out his name as new Implementers Guide issues arise. Best Regards, Paul E. Jones Rapporteur Q.2/16 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Horvath Ernst 22 Mar '01

22 Mar '01

Frank, Roni et al., I like Roni's summary. In my opinion the procedures (in section 8) are clear enough. But section 6.2 talks about terminal functionality, and this got out of line with new options added over time. How about the following guidelines for improving on the text in 6.2.8: 1. All terminals shall support H.245 control, as far as required by the terminal type (e.g. annex-F-SETs need only a subset for fastStart). 2. Except for SETs, a terminal shall be "able" to open an H.245 control channel at any time during a call. 3. Encapsulation/tunneling may be used instead of the H.245 control channel if supported at both ends. 4. The terminal shall associate exactly one H.245 "session" with each call, but the transport method for the H.245 control information can be chosen as desired and also changed during a call (fastStart / tunnel / H.245 control channel - the rules for switching from one method to another are given in section 8). Regards, Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Frank Derks [mailto:frank.derks@PHILIPS.COM] > Gesendet am: Donnerstag, 22. März 2001 15:03 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: Re: Conflicting text in H.323 concerning the requirement for > esta blishing a H.245 control channel?? > > Roni (et al.), > > I would say that what you are saying is pretty much how I > initially thought > things were supposed to work (before I started this > discussion;-0). The > downside is that this brings us back to square one, and I do > not want to > restart the discussion. > > I would like to ask Paul and Chris to come up with how we're > going to avoid > future confusion. Would it be a good idea to change the > wording in 6.2.8 to: > > "The endpoint shall establish at most one H.245 Control > Channel for each call > that the endpoint is participating in." > > Regards, > > Frank > > > > > > Roni_e@ACCORD.CO.IL@SMTP@MAILBAG.INTEL.COM on 22-03-2001 13:55:44 > Please respond to Roni_e@ACCORD.CO.IL@SMTP > Sent by: ITU-SG16(a)MAILBAG.INTEL.COM > To: ITU-SG16@MAILBAG.INTEL.COM@SMTP > cc: > Subject: Re: Conflicting text in H.323 concerning the > requirement for esta blishing a H.245 control channel?? > Classification: > > all, > > I will try to give my view and history of the H.245. > Before fast connect the issue of H.245 was simple. It is > mandatory and after > call setup the H.245 process with Master-slave and caps > exchange was the > only way. Annex F gave an option for a simple terminal with no h.245 > mandatory support. This is the text in 6.2.8. When we added > fast connect we > opened the door for simple calls that finished the connection and > establishment of media channels and did not need any more > control to delay > or skip H.245 and described in 8.1.7.2. Any side can initiate > the opening of > H.245 during the call. I have to agree that 6.2.8 is very > strong about H.245 > channel establishment. The reason for having it this way is to prevent > implementers from understanding that an H.323 compliant > endpoint can be > implemented without support of H.245 if they are doing fast > connect!!!. > > Call termination, before fast connect, was done through > H.245. The call > signaling channel can be closed before but H.245 must stay > open during the > call. 8.1.7.2 explain what to do if H.245 was not open (call > signaling must > stay open until call finish or opening of a separate H.245 channel) ( > 8.1.7.2 2nd paragraph "When a call is established using the > Fast Connect > procedure, both endpoints shall keep the Q.931 Call Signaling > Channel open > until either the call is terminated or, for compatibility with older > endpoints, until a separate H.245 connection is established.") > > I think that is what H.323 says. If you feel that this is not > clear from the > text give me a suggestion how to change it. It can be > submitted to the next > meeting (I am the new editor for H.323 V5). > Regards > Roni Even > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Roni Even 22 Mar '01

22 Mar '01

Chris, About your comments 1. B can make A start H.245 by using facility message with reason startH.245. See H.323 8.2.3 Switching to a separate H.245 connection. 2. About 6.2.8 I agree that it states the H.245 shall be established, it does not say when. The when is mentioned in 8.1.7.2. Roni Even -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Wednesday, March 21, 2001 3:31 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel?? Roni, > H.323 mandates the support of H.245 for end points that comply with the > standard. It does not mean, when using fast connect that it must be open > immediately but can be opened at a later stage by any side. Except that it states exactly the opposite in the section under discussion. Also, consider the following scenario: Two endpoints, A and B. B does not support tunnelled H.245. A calls B, without giving any H.245 address in its Setup message. B accepts the call on the basis of fastStart. No H.245 channel is set up, as you suggest. Suppose now B wishes to send a UII (or any H.245 message) to A. It can't. It can't set up the H.245 channel. A could set it up, but doesn't see the need. > The reason for > mandating H.245 is to supply a control channel and is important for gateways > and MCUs as well as for control functions in point to point calls such as > Video fast updates. H.323 annex F defines a simple end point that has H.245 > support as optional. > I do not see the conflict between 6.2.8 and 8.1.7 if 6.2.8 means that you > have to support it but not to actually open it as in simple fast connect > calls. But 6.2.8 does not mean that. It clearly states that an H.245 channel SHALL be opened. > As for DTMF you can use the DTMF RTP payload to have it in band instead of > H.245. If the person you're talking to happens to support this. Of course you don't know whether or not it does if you haven't exchanged TCS. Please let's not break this! Regards, Chris > -----Original Message----- > From: Agboh, Charles [mailto:charles.agboh@EBONE.COM] > Sent: Tuesday, March 20, 2001 6:59 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Conflicting text in H.323 concerning the requirement for > esta blishing a H.245 control channel?? > > > Chris, > > Part of establishing a "point-to-point" call involves opening 2 TCP > connnections using the Fast Connect procedure as you described it. If that > is the case, then the extract from H.323v2 below is misleading(I believe). > > H.323v2: 8.1.7 Fast Connect Procedure > > "..... The Fast Connect procedure allows the endpoints to establish a basic > point-to-point call with as few as one round-trip message exchange, enabling > immediate media stream delivery upon call connection." > > BR, > Charles > >> -----Original Message----- >> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] >> Sent: Tuesday, March 20, 2001 5:47 PM >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: Conflicting text in H.323 concerning the requirement for >> esta blishing a H.245 control channel?? >> >> >> Charles, >> >> It does NOT defeat ANY of the stated aims of FastConnect. >> These aims were to get agreed media channels in both >> directions open as >> quickly as possible. Doing FastStart AND H.245 gives you your media >> quickly, and means you have the power of H.245 thereon. >> >> In-band DTMF transfer may be used. If you happen to be using >> a codec that >> supports it. If you assume it when you're using an >> unsuitable codec you'll >> have a problem. Which is a reason for using H.245 capability >> negotiation. >> >> Regards, >> Chris >> >> Agboh, Charles wrote: >> >> >>> which defeats the whole point of having a Fast Connect >> >> procedure (FS + >> >>> H.245). Why isn't in-band- DTMF transfer used instead (in FS)? >>> >>> -Charles >>> >>> >>> >>>> -----Original Message----- >>>> From: Frank Derks [mailto:frank.derks@PHILIPS.COM] >>>> Sent: Tuesday, March 20, 2001 4:40 PM >>>> To: ITU-SG16(a)MAILBAG.INTEL.COM >>>> Subject: Re: Conflicting text in H.323 concerning the >>> >> requirement for >> >>>> establishing a H.245 control channel?? >>>> >>>> >>>> Chris, >>>> >>>> I thought I was being clear enough, so let me try again. >>>> 6.2.8/H.323 states >>>> that an enpoint must open one (and exactly one) H.245 control >>>> channel. When >>>> Fast Connect is being used, I assume that the intention is >>>> that no such control >>>> channel is opened. >>>> >>>> To be compliant with 6.2.8/H,323 I would have to open a H.245 >>>> control channel >>>> irrespective of which type of H.245 procedures I will be >>>> using. So if I intend >>>> to use Fast Start (and assuming that the other party also >>>> supports this), I >>>> still have to open a H.245 control channel. >>>> >>>> Frank >>>> >>>> >>>> >>>> >>>> >>>> >>>> cwp(a)isdn-comms.co.uk on 20-03-2001 15:17:14 >>>> To: Frank Derks/HVS/BE/PHILIPS@EMEA2 >>>> cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP >>>> Subject: Re: Conflicting text in H.323 concerning the >>>> requirement for establishing a H.245 control channel?? >>>> Classification: >>>> >>>> Frank, >>>> >>>> Why do you consider this text to be "conflicting"? >>>> Specifically, with what does it conflict? >>>> >>>> Regards, >>>> Chris >>>> >>>> >>>> >>>>> 6.2.8/H.323 states: "The endpoint shall establish exactly >>>> >> one H.245 >> >>>>> Control Channel for each call that the endpoint is >>>> >>>> participating in." >>>> >>>> >>>>> 8.1.7/H.323 never states that when Fast Connect is being >>>> >> used such a >> >>>>> control channel should be established. As far as I understand the >>>>> mechanism this is only required to switch to "normal" H.245 >>>> >>>> procedures. >>>> >>>> >>>>> It would seem that section 6.2.8 should be rephrased to >>>> >>>> make clear that >>>> >>>> >>>>> the H.245 control channel shall only be established when >>>> >>>> "normal" H.245 >>>> >>>> >>>>> procedures are being followed and not in the fast connect case. >>>>> >>>>> Frank >>>> >>>> -- >>>> Dr Chris Purvis -- Development Manager >>>> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road >>>> Winkfield Row, Berkshire. RG42 6LY ENGLAND >>>> Phone: +44 1344 899 007 >>>> Fax: +44 1344 899 001 >>>> >>>> >>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >>>> For help on this mail list, send "HELP ITU-SG16" in a message to >>>> listserv(a)mailbag.intel.com >>>> >>> >>> >>> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >>> For help on this mail list, send "HELP ITU-SG16" in a message to >>> listserv(a)mailbag.intel.com >> >> >> -- >> Dr Chris Purvis -- Development Manager >> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road >> Winkfield Row, Berkshire. RG42 6LY ENGLAND >> Phone: +44 1344 899 007 >> Fax: +44 1344 899 001 >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> For help on this mail list, send "HELP ITU-SG16" in a message to >> listserv(a)mailbag.intel.com >> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Roni Even 22 Mar '01

22 Mar '01

All, H.323 mandates the support of H.245 for end points that comply with the standard. It does not mean, when using fast connect that it must be open immediately but can be opened at a later stage by any side. The reason for mandating H.245 is to supply a control channel and is important for gateways and MCUs as well as for control functions in point to point calls such as Video fast updates. H.323 annex F defines a simple end point that has H.245 support as optional. I do not see the conflict between 6.2.8 and 8.1.7 if 6.2.8 means that you have to support it but not to actually open it as in simple fast connect calls. As for DTMF you can use the DTMF RTP payload to have it in band instead of H.245. Regards Roni Even -----Original Message----- From: Agboh, Charles [mailto:charles.agboh@EBONE.COM] Sent: Tuesday, March 20, 2001 6:59 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel?? Chris, Part of establishing a "point-to-point" call involves opening 2 TCP connnections using the Fast Connect procedure as you described it. If that is the case, then the extract from H.323v2 below is misleading(I believe). H.323v2: 8.1.7 Fast Connect Procedure "..... The Fast Connect procedure allows the endpoints to establish a basic point-to-point call with as few as one round-trip message exchange, enabling immediate media stream delivery upon call connection." BR, Charles > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Tuesday, March 20, 2001 5:47 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Conflicting text in H.323 concerning the requirement for > esta blishing a H.245 control channel?? > > > Charles, > > It does NOT defeat ANY of the stated aims of FastConnect. > These aims were to get agreed media channels in both > directions open as > quickly as possible. Doing FastStart AND H.245 gives you your media > quickly, and means you have the power of H.245 thereon. > > In-band DTMF transfer may be used. If you happen to be using > a codec that > supports it. If you assume it when you're using an > unsuitable codec you'll > have a problem. Which is a reason for using H.245 capability > negotiation. > > Regards, > Chris > > Agboh, Charles wrote: > > > which defeats the whole point of having a Fast Connect > procedure (FS + > > H.245). Why isn't in-band- DTMF transfer used instead (in FS)? > > > > -Charles > > > > > >> -----Original Message----- > >> From: Frank Derks [mailto:frank.derks@PHILIPS.COM] > >> Sent: Tuesday, March 20, 2001 4:40 PM > >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> Subject: Re: Conflicting text in H.323 concerning the > requirement for > >> establishing a H.245 control channel?? > >> > >> > >> Chris, > >> > >> I thought I was being clear enough, so let me try again. > >> 6.2.8/H.323 states > >> that an enpoint must open one (and exactly one) H.245 control > >> channel. When > >> Fast Connect is being used, I assume that the intention is > >> that no such control > >> channel is opened. > >> > >> To be compliant with 6.2.8/H,323 I would have to open a H.245 > >> control channel > >> irrespective of which type of H.245 procedures I will be > >> using. So if I intend > >> to use Fast Start (and assuming that the other party also > >> supports this), I > >> still have to open a H.245 control channel. > >> > >> Frank > >> > >> > >> > >> > >> > >> > >> cwp(a)isdn-comms.co.uk on 20-03-2001 15:17:14 > >> To: Frank Derks/HVS/BE/PHILIPS@EMEA2 > >> cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP > >> Subject: Re: Conflicting text in H.323 concerning the > >> requirement for establishing a H.245 control channel?? > >> Classification: > >> > >> Frank, > >> > >> Why do you consider this text to be "conflicting"? > >> Specifically, with what does it conflict? > >> > >> Regards, > >> Chris > >> > >> > >>> 6.2.8/H.323 states: "The endpoint shall establish exactly > one H.245 > >>> Control Channel for each call that the endpoint is > >> > >> participating in." > >> > >>> 8.1.7/H.323 never states that when Fast Connect is being > used such a > >>> control channel should be established. As far as I understand the > >>> mechanism this is only required to switch to "normal" H.245 > >> > >> procedures. > >> > >>> It would seem that section 6.2.8 should be rephrased to > >> > >> make clear that > >> > >>> the H.245 control channel shall only be established when > >> > >> "normal" H.245 > >> > >>> procedures are being followed and not in the fast connect case. > >>> > >>> Frank > >> > >> -- > >> Dr Chris Purvis -- Development Manager > >> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > >> Winkfield Row, Berkshire. RG42 6LY ENGLAND > >> Phone: +44 1344 899 007 > >> Fax: +44 1344 899 001 > >> > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> For help on this mail list, send "HELP ITU-SG16" in a message to > >> listserv(a)mailbag.intel.com > >> > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

4 3

Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Frank Derks 22 Mar '01

22 Mar '01

Roni (et al.), I would say that what you are saying is pretty much how I initially thought things were supposed to work (before I started this discussion;-0). The downside is that this brings us back to square one, and I do not want to restart the discussion. I would like to ask Paul and Chris to come up with how we're going to avoid future confusion. Would it be a good idea to change the wording in 6.2.8 to: "The endpoint shall establish at most one H.245 Control Channel for each call that the endpoint is participating in." Regards, Frank Roni_e@ACCORD.CO.IL@SMTP@MAILBAG.INTEL.COM on 22-03-2001 13:55:44 Please respond to Roni_e@ACCORD.CO.IL@SMTP Sent by: ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16@MAILBAG.INTEL.COM@SMTP cc: Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel?? Classification: all, I will try to give my view and history of the H.245. Before fast connect the issue of H.245 was simple. It is mandatory and after call setup the H.245 process with Master-slave and caps exchange was the only way. Annex F gave an option for a simple terminal with no h.245 mandatory support. This is the text in 6.2.8. When we added fast connect we opened the door for simple calls that finished the connection and establishment of media channels and did not need any more control to delay or skip H.245 and described in 8.1.7.2. Any side can initiate the opening of H.245 during the call. I have to agree that 6.2.8 is very strong about H.245 channel establishment. The reason for having it this way is to prevent implementers from understanding that an H.323 compliant endpoint can be implemented without support of H.245 if they are doing fast connect!!!. Call termination, before fast connect, was done through H.245. The call signaling channel can be closed before but H.245 must stay open during the call. 8.1.7.2 explain what to do if H.245 was not open (call signaling must stay open until call finish or opening of a separate H.245 channel) ( 8.1.7.2 2nd paragraph "When a call is established using the Fast Connect procedure, both endpoints shall keep the Q.931 Call Signaling Channel open until either the call is terminated or, for compatibility with older endpoints, until a separate H.245 connection is established.") I think that is what H.323 says. If you feel that this is not clear from the text give me a suggestion how to change it. It can be submitted to the next meeting (I am the new editor for H.323 V5). Regards Roni Even -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Thursday, March 22, 2001 1:27 PM To: Roni Even; Paul Jones Cc: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel?? Roni, Frank, Paul Jones et al, Having reread 8.1.7.2 (as referenced by Roni) I believe that Frank was right all along in saying there is a conflict. 8.1.7.2 saying that a device "may" establish an H.245 session at any point during a call is, I would argue, clearly at odds with 6.2.8 stating that such a session "shall" be established. After all, having not bothered to bring one up until an instant before the end of the call (clearly permitted by 8.1.7.2), why create one at that stage (except because 6.2.8 tells you to...)? There is an alternative reading: the implication of 6.2.8 is that some sort of H.245 session should start immediately (the start and end are the only "special" times in an ordinary call, so if you must start one it's pretty well a requirement to do it immediately). What I don't recall is whether it's permitted to drop an H.245 session during a call. I think it is. So is there an alternative reading, saying "start the H.245 channel at the beginning of the call, but you may drop and restart it as you like during the call"? I don't like this reading, though, it's probably the worst of all worlds. However I don't like the delay of setting up an H.245 session being added to the time taken to transmit the first DTMF tone in a call either... Paul, I think this really needs tidying up one way or another - I think it's a job for the implementors guide... Consensus currently seems to be against me, and to be that we should dump the relevant text in 6.2.8. Regards, Chris Roni Even wrote: > Chris, > About your comments > > 1. B can make A start H.245 by using facility message with reason > startH.245. See H.323 8.2.3 Switching to a separate H.245 connection. > 2. About 6.2.8 I agree that it states the H.245 shall be established, it > does not say when. The when is mentioned in 8.1.7.2. > Roni Even > > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Wednesday, March 21, 2001 3:31 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Conflicting text in H.323 concerning the requirement for > esta blishing a H.245 control channel?? > > > Roni, > > > >> H.323 mandates the support of H.245 for end points that comply with the >> standard. It does not mean, when using fast connect that it must be open >> immediately but can be opened at a later stage by any side. > > Except that it states exactly the opposite in the section under discussion. > > Also, consider the following scenario: > Two endpoints, A and B. B does not support tunnelled H.245. A calls B, > without giving any H.245 address in its Setup message. B accepts the call > on the basis of fastStart. No H.245 channel is set up, as you suggest. > Suppose now B wishes to send a UII (or any H.245 message) to A. It can't. > It can't set up the H.245 channel. A could set it up, but doesn't see the > need. > > >> The reason for >> mandating H.245 is to supply a control channel and is important for > > gateways > >> and MCUs as well as for control functions in point to point calls such as >> Video fast updates. H.323 annex F defines a simple end point that has > > H.245 > >> support as optional. >> I do not see the conflict between 6.2.8 and 8.1.7 if 6.2.8 means that you >> have to support it but not to actually open it as in simple fast connect >> calls. > > But 6.2.8 does not mean that. It clearly states that an H.245 channel SHALL > be opened. > > >> As for DTMF you can use the DTMF RTP payload to have it in band instead of >> H.245. > > If the person you're talking to happens to support this. Of course you > don't know whether or not it does if you haven't exchanged TCS. > > Please let's not break this! > > Regards, > Chris > > > >> -----Original Message----- >> From: Agboh, Charles [mailto:charles.agboh@EBONE.COM] >> Sent: Tuesday, March 20, 2001 6:59 PM >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: Conflicting text in H.323 concerning the requirement for >> esta blishing a H.245 control channel?? >> >> >> Chris, >> >> Part of establishing a "point-to-point" call involves opening 2 TCP >> connnections using the Fast Connect procedure as you described it. If > > that > >> is the case, then the extract from H.323v2 below is misleading(I believe). >> >> H.323v2: 8.1.7 Fast Connect Procedure >> >> "..... The Fast Connect procedure allows the endpoints to establish a > > basic > >> point-to-point call with as few as one round-trip message exchange, > > enabling > >> immediate media stream delivery upon call connection." >> >> BR, >> Charles >> >> >>> -----Original Message----- >>> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] >>> Sent: Tuesday, March 20, 2001 5:47 PM >>> To: ITU-SG16(a)MAILBAG.INTEL.COM >>> Subject: Re: Conflicting text in H.323 concerning the requirement for >>> esta blishing a H.245 control channel?? >>> >>> >>> Charles, >>> >>> It does NOT defeat ANY of the stated aims of FastConnect. >>> These aims were to get agreed media channels in both >>> directions open as >>> quickly as possible. Doing FastStart AND H.245 gives you your media >>> quickly, and means you have the power of H.245 thereon. >>> >>> In-band DTMF transfer may be used. If you happen to be using >>> a codec that >>> supports it. If you assume it when you're using an >>> unsuitable codec you'll >>> have a problem. Which is a reason for using H.245 capability >>> negotiation. >>> >>> Regards, >>> Chris >>> >>> Agboh, Charles wrote: >>> >>> >>> >>>> which defeats the whole point of having a Fast Connect >>> >>> procedure (FS + >>> >>> >>>> H.245). Why isn't in-band- DTMF transfer used instead (in FS)? >>>> >>>> -Charles >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Frank Derks [mailto:frank.derks@PHILIPS.COM] >>>>> Sent: Tuesday, March 20, 2001 4:40 PM >>>>> To: ITU-SG16(a)MAILBAG.INTEL.COM >>>>> Subject: Re: Conflicting text in H.323 concerning the >>>> >>> requirement for >>> >>> >>>>> establishing a H.245 control channel?? >>>>> >>>>> >>>>> Chris, >>>>> >>>>> I thought I was being clear enough, so let me try again. >>>>> 6.2.8/H.323 states >>>>> that an enpoint must open one (and exactly one) H.245 control >>>>> channel. When >>>>> Fast Connect is being used, I assume that the intention is >>>>> that no such control >>>>> channel is opened. >>>>> >>>>> To be compliant with 6.2.8/H,323 I would have to open a H.245 >>>>> control channel >>>>> irrespective of which type of H.245 procedures I will be >>>>> using. So if I intend >>>>> to use Fast Start (and assuming that the other party also >>>>> supports this), I >>>>> still have to open a H.245 control channel. >>>>> >>>>> Frank >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> cwp(a)isdn-comms.co.uk on 20-03-2001 15:17:14 >>>>> To: Frank Derks/HVS/BE/PHILIPS@EMEA2 >>>>> cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP >>>>> Subject: Re: Conflicting text in H.323 concerning the >>>>> requirement for establishing a H.245 control channel?? >>>>> Classification: >>>>> >>>>> Frank, >>>>> >>>>> Why do you consider this text to be "conflicting"? >>>>> Specifically, with what does it conflict? >>>>> >>>>> Regards, >>>>> Chris >>>>> >>>>> >>>>> >>>>> >>>>>> 6.2.8/H.323 states: "The endpoint shall establish exactly >>>>> >>> one H.245 >>> >>> >>>>>> Control Channel for each call that the endpoint is >>>>> >>>>> participating in." >>>>> >>>>> >>>>> >>>>>> 8.1.7/H.323 never states that when Fast Connect is being >>>>> >>> used such a >>> >>> >>>>>> control channel should be established. As far as I understand the >>>>>> mechanism this is only required to switch to "normal" H.245 >>>>> >>>>> procedures. >>>>> >>>>> >>>>> >>>>>> It would seem that section 6.2.8 should be rephrased to >>>>> >>>>> make clear that >>>>> >>>>> >>>>> >>>>>> the H.245 control channel shall only be established when >>>>> >>>>> "normal" H.245 >>>>> >>>>> >>>>> >>>>>> procedures are being followed and not in the fast connect case. >>>>>> >>>>>> Frank >>>>> >>>>> -- >>>>> Dr Chris Purvis -- Development Manager >>>>> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road >>>>> Winkfield Row, Berkshire. RG42 6LY ENGLAND >>>>> Phone: +44 1344 899 007 >>>>> Fax: +44 1344 899 001 >>>>> >>>>> >>>> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> >>>>> For help on this mail list, send "HELP ITU-SG16" in a message to >>>>> listserv(a)mailbag.intel.com >>>>> >>>> >>>> >>>> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> >>>> For help on this mail list, send "HELP ITU-SG16" in a message to >>>> listserv(a)mailbag.intel.com >>> >>> >>> -- >>> Dr Chris Purvis -- Development Manager >>> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road >>> Winkfield Row, Berkshire. RG42 6LY ENGLAND >>> Phone: +44 1344 899 007 >>> Fax: +44 1344 899 001 >>> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> For help on this mail list, send "HELP ITU-SG16" in a message to >>> listserv(a)mailbag.intel.com >>> >> >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> For help on this mail list, send "HELP ITU-SG16" in a message to >> listserv(a)mailbag.intel.com >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> For help on this mail list, send "HELP ITU-SG16" in a message to >> listserv(a)mailbag.intel.com > > > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0