May 1999 - sg16-avd - lists.packetizer.com

Re: caller ID and implementer's guide
by Kaynam Hedayat 07 May '99

07 May '99

Hi, H.323 V1 and V2 endpoints correctly assume that octet 3a is not present since H.225.0 states that it shall not be. Therefore there are endpoints that don't check for the extension bit of octet 3 (i.e. assume it is 1). I agree that it is useful to forward octet 3a but backward compatibility must be met. Kaynam Rich Bowen <rkbowen(a)CISCO.COM> on 05/07/99 03:49:54 PM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com cc: (bcc: Kaynam Hedayat/PicTel) Subject: Re: caller ID and implementer's guide Glen, others, I also would support the proposal to allow octet 3a. We have had requests from customers to allow this information. Not knowing about APC-1527, I also submitted a contribution to allow octet 3a (D-264), with proposed text indicating that gateways "should" forward this information as received from the SCN. As Glen has indicated, however, we need to look further into interoperability issues. Regards, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen(a)cisco.com Research Triangle Park, NC -------------------------------------------------------------------- Karl.Klaghofer(a)ICN.SIEMENS.DE wrote: > > Glen and others, > > It was a mistake to exclude the octet 3a in H.225.0 (v1 and v2) Calling > party number IE. It has led to interoperability problems with the SCN in > the past (where octet 3a is used) ! > Now, it is time to fix this error as discussed in the Monterey Rapporteuts > meeting in February (i.e. for H.225.0v3 but also for H.225.0v2 via > Implementors Guide !). There may be procucts already planning on that > announced correction. > > An endpoint B - not supporting octet 3a of Calling Party Number Information > element - should treat this situation as a "non-mandatory information > element content error". The reaction to such an type of error shall be: > * Take actions on the SETUP received and on all the information > elements that are recognized and have valid contents; i.e. ignore only the > Calling party Number IE > * A STATUS may optionally be returned with Cause #100. > > Refer also to Q.931 clause 5.8.7.2 (which should applicable also to H.225.0, > since H.225.0 is so much based on the Q.931). > > So, if such an endpoint B receives an octet 3a in Calling party Number set > to "presentation allowed", all that happens is that the Number would not be > displayed at B. > But for the really critical case where the octet 3a is received by such an > endpoint B being set to "presentation restrictet", we have even the behavier > we intend, namely NOT to display the number to the endpoint B (since the > whole IE should be ignored anyway). > > A miscoded optional Information element should never lead to a clearing of > the call ! > > Regards, > Karl > ------------------------------------------------ > Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 > Hofmannstr. 51, D-81359 Munich, Germany > Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 > e-mail: karl.klaghofer(a)icn.siemens.de > > > -----Ursprüngliche Nachricht----- > > Von: Glen Freundlich [SMTP:ggf@lucent.com] > > Gesendet am: Donnerstag, 6. Mai 1999 22:11 > > An: ITU-SG16(a)mailbag.cps.intel.com > > Betreff: caller ID and implementer's guide > > > > At the Monterey meeting we discussed the possibility of an addition to > > the Implementer's Guide to support caller ID features (APC-1527). > > H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party > > Number IE (and also specifies that the octet 3 extension bit shall be > > set to 1). The proposal calls for removing the restriction through the > > Implementer's Guide. (See also the meeting report in APC-1554b.) > > > > Fixing this brings up the possibility of interoperability problems with > > existing products. Please respond if you think this change will be a > > problem. You can respond to me individually, rather than to the entire > > list, if you prefer. > > > > Thanks, > > Glen > > > > > > -- > > 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: caller ID and implementer's guide
by Rich Bowen 07 May '99

07 May '99

Glen, others, I also would support the proposal to allow octet 3a. We have had requests from customers to allow this information. Not knowing about APC-1527, I also submitted a contribution to allow octet 3a (D-264), with proposed text indicating that gateways "should" forward this information as received from the SCN. As Glen has indicated, however, we need to look further into interoperability issues. Regards, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen(a)cisco.com Research Triangle Park, NC -------------------------------------------------------------------- Karl.Klaghofer(a)ICN.SIEMENS.DE wrote: > > Glen and others, > > It was a mistake to exclude the octet 3a in H.225.0 (v1 and v2) Calling > party number IE. It has led to interoperability problems with the SCN in > the past (where octet 3a is used) ! > Now, it is time to fix this error as discussed in the Monterey Rapporteuts > meeting in February (i.e. for H.225.0v3 but also for H.225.0v2 via > Implementors Guide !). There may be procucts already planning on that > announced correction. > > An endpoint B - not supporting octet 3a of Calling Party Number Information > element - should treat this situation as a "non-mandatory information > element content error". The reaction to such an type of error shall be: > * Take actions on the SETUP received and on all the information > elements that are recognized and have valid contents; i.e. ignore only the > Calling party Number IE > * A STATUS may optionally be returned with Cause #100. > > Refer also to Q.931 clause 5.8.7.2 (which should applicable also to H.225.0, > since H.225.0 is so much based on the Q.931). > > So, if such an endpoint B receives an octet 3a in Calling party Number set > to "presentation allowed", all that happens is that the Number would not be > displayed at B. > But for the really critical case where the octet 3a is received by such an > endpoint B being set to "presentation restrictet", we have even the behavier > we intend, namely NOT to display the number to the endpoint B (since the > whole IE should be ignored anyway). > > A miscoded optional Information element should never lead to a clearing of > the call ! > > Regards, > Karl > ------------------------------------------------ > Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 > Hofmannstr. 51, D-81359 Munich, Germany > Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 > e-mail: karl.klaghofer(a)icn.siemens.de > > > -----Ursprüngliche Nachricht----- > > Von: Glen Freundlich [SMTP:ggf@lucent.com] > > Gesendet am: Donnerstag, 6. Mai 1999 22:11 > > An: ITU-SG16(a)mailbag.cps.intel.com > > Betreff: caller ID and implementer's guide > > > > At the Monterey meeting we discussed the possibility of an addition to > > the Implementer's Guide to support caller ID features (APC-1527). > > H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party > > Number IE (and also specifies that the octet 3 extension bit shall be > > set to 1). The proposal calls for removing the restriction through the > > Implementer's Guide. (See also the meeting report in APC-1554b.) > > > > Fixing this brings up the possibility of interoperability problems with > > existing products. Please respond if you think this change will be a > > problem. You can respond to me individually, rather than to the entire > > list, if you prefer. > > > > Thanks, > > Glen > > > > > > -- > > 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

Roaming and mobility
by Kristiansen, Lill 07 May '99

07 May '99

On behalf of Espen and myself I will post this (delayed) reply to Douglas Best regards Lill -- Lill Kristiansen, Ericsson Internet Development, XoIP (former MMTS) Billingstad, Norway email: etolkr(a)eto.ericsson.se - - Hi, Thanks for clarifying this. We're basicly happy with an agreement that mobility issues more work. > It is not enough to just say "roaming"! > Douglas Fully support this statement! There are (at least) two different aspects of mobility: Terminal mobility - A terminal communicating independent of location User mobility - The user receives his phone service independent of of terminal and underlying network (domain). In addition we have the discrete vs continuous cases. See Tiphon WG7 for more definitions In wireless one mostly talk about the continuous case (aka handover). Discrete user mobility may very easy be achieved by user oriented E.164 numbers and RAS messages Discrete terminal mobility is often out of scope of the application (may be done by Mobile IP or other means) Digression: In case an H.323 E.164 number is assigned to a terminal/plug in the wall, (i.e. similar to the PSTN case) then you place a call towards this fixed place. The fact that my phusical phone can be plugged in also at another house, does not offer 'mobility', as the calls will still be charged to the plug in the wall. So even though is is a sort of 'discrete terminal mobility', it is not what we're after. (and why the UPT concept was invented) end digression However in most cases with terminal mobility the continuous/wireless case is the interesting one. We consider wireless to be a very important and radio specific access technology, outside the scope and competence of sg16 and Tiphon. Here we're talking about user mobility, as we hope terminal mobility can be achieved with other/access techniques. But the point is, when we are introducing "user mobility" between the Annex G domains, we should make sure that any supplementary services the user subscribes to are also reachable. This includes both services invoked by the service provider and terminal invoked services. For the service provider invoked services one can see solutions as 1. Downloading a service profile from home domain to the visited domain This is done in GSM networks, and requires all services to be standardized. 2. Route the call signaling channel through the home domain This allows proprietary services within the domain to be executed anywhere. I.e. one obtain service mobility, and virtual home environment There is danger of "tromboning" which is the reason it hasn't been introduced in switched networks, but as H.323 uses a packet network, the tromboning applies only to the signaling, which in many cases might not be problematic. See also some comments below Espen and Lill -----Original Message----- > From: Douglas Clowes [mailto:dclowes@ozemail.com.au] > Sent: 27. april 1999 01:01 > To: Espen Skjæran > Cc: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Annex G and Roaming? > > Espen, > It all depends on what you mean by "roaming of users between different > domains". > Annex G does support some functionality for some favours of roaming, but > requires further development - particularly in how to use these aspects > between domains. > > Comments below. > At 14:54 1999-04-23 +0200, Espen Skjæran wrote: > >Hi all, > > > >I've recently heard (unofficially) that some claim Annex G > >(APC-1546/TD-20 in Monterey) > >also to support roaming of users between different domains. > > > >If this is true, I wonder how. > > > >I can see how the AccessRequest/ValidationRequest might be sent from a > >visiting domain to the home domain for per-call authorization. While > >this might work in simple cases, it will hinder the use of services > >while roaming. > Per call authorization permits a user from one domain to use gateway > equipment from a second domain, to make calls to through a gateway in a > third domain. There could even be a fourth domain present as a clearinghouse. > > I don't know what you mean by "hinder the use of services while roaming" in > this context. Perhaps you could elaborate please. This is the VAS/supplementary services issue mention above > >I can not either see any mechanism to authorize the roaming > >registration. > Registration is a completely different issue, and I don't see support for > it in Annex G. Perhaps an RRQ with a remote e.164 or IP address could be > issued to the home domain, by the terminal or host gatekeeper? > >I am sorry to post based on "rumors", but this may change the scope of > >Annex G significally, and I worry if this might affect future work on > >roaming. As Tiphon has just started their work on roaming by analysing > >existing roaming techniques in telco and datacom/IETF work,and not yet > >reached any conclusion, it seems premature to use annex G > >in its current state for roaming. > These concepts will have to be developed in parallel. There is more than > one "type" or "roaming", and different people will think of different > things when that word is used. Maybe have a look at Tiphon 12TD088 for an overview of existing techniques for mobility and roaming in datacom and telecom > Some people think of terminal mobility, yes, and often the continuous/wireless one > while others think of mobile IP. > Neither of these apply to the mobile user on public ingress gateways > depicted above, but they are no less valid and need to be considered. If we compare to the terminology used above, we think what you refer to is discrete user mobility, more like in UPT, where you register for in/outgoing calls to be routed to your current location. I.e. it relates to you and your H.323 application, and the call routing you want (including routing to IVR etc..) And it is true that this is neither wireless nor Mobile IP. But it is important as well. > When we know what the opportunities are, we will be better placed to seek > solutions. It is not enough to just say "roaming"! > Douglas > >Espen

1 0

Delayed Document H.323 Annex F (changes to white paper)
by Joerg Ott 07 May '99

07 May '99

Dear Mr. Okubo, dear colleagues, I have placed a copy of the revised Draft H.323 Annex F (incorporating editorial changes from the last Rapporteur's meeting in Monterey) in the Incoming directory on the PicureTel ftp server: H323AnnexF-Delayed.zip Please disregards file H323AnnexF-02.zip (uploading failed last night). Regards, Joerg ------------------------------------------------------------------------------- Joerg Ott jo(a)tzi.uni-bremen.de Universitaet Bremen, Germany fax + 49 421 218-7000 TELES AG voice + 49 421 201-7028

1 0

Re: TD's for discussion at the Santiago meeting
by Roy, Radhika R, ALCOO 07 May '99

07 May '99

Dale: Yes, I like Espen's idea. I also like to add as follows: 1. Backend services for H.323 2. Mobility support for H.323 3. Other possible topics ... Radhika R. Roy AT&T (732) 420 1580 PS: "Mobile Internet Telephony: Mobile Extension to H.323 by W. Liao," INFOCOM'99, is a good start for support of mobility in H.323. > -----Original Message----- > From: Espen Skjæran (ETO) [SMTP:Espen.Skjaeran@ETO.ERICSSON.SE] > Sent: Friday, May 07, 1999 8:45 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: TD's for discussion at the Santiago meeting > > Dale, > > We would like to bring up a (rather new) topic for discussion about a > future work item at the rapporteur's part of the Santiago meeting. We hope > this is possible at this time. > > The topic is service control (and have been discussed at Tiphon meeting in > Bankok this week). We will like to bring forward some of the Tiphon > discussion to sg16. We will write a small note about the possible use of > H.245 to establish service control channels. It will be explained via a > few simple examples, and hopefully serve as a basis fo further dicsussion. > > Thus we will ask you as a rapporteur to give us a TD number if this is > required. > > > Espen Skjaeran

1 0

Re: flowControlCommand and packet overhead
by Pete Cordell 07 May '99

07 May '99

Let's not get too trigger happy here! The original intent of flowControl is to constrain the bit rate of a channel to something such as a video decoder can cope with. In the past these tended to be MIPS limited, and bit rate tended to be a major (although not only) parameter that affecting the number of MIPS required. Note that in this case this was bits of video data and had nothing to do with headers etc. flowControl is also used to control the rate at which gateways receive things like video data. This allows the gateways to squirt the data down fixed bit rate pipes such as parts of ISDN B channels. Again this figure is not interested in packet overhead. Use of flowControl in the QoS arena is the most recent of its uses. Therefore, even if it is broken in this context, it is not appropriate to change its definition as it would fix one problem and break two others! However, I don't believe it is actually broken in the latter context. In the QoS case, the flowControl command is really only used to switch the channel on and off. The transmitter knows at which rate it will send, and puts this in the RSVPParameters part of the OLC. This information is presumably also put in the RSVP PATH Sender TSPEC. Even if it is desired to allow flowControl to change the channel rate, a transmitter that receives a flowControl message can work out what it requires to add in terms of headers, and then change the RSVP PATH TSPEC accordingly. This will get to the receiver, which will send RESV using the new spec. As the transmitter knows what it is going to do in terms of packetisation and the receiver can only guess, this seems the right way round to me. Pete ============================================= Pete Cordell pete.cordell(a)btinternet.com ============================================= -----Original Message----- From: Gur Kimchi <Gur_Kimchi(a)VOCALTEC.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 07 May 1999 04:41 Subject: Re: flowControlCommand and packet overhead >Paul Wrote: > >>>> The value in consistently >>>> using the same, although arguably flawed, >>>> bandwidth calculations outweighs the >>>> benefit of having a mix of calculations. > >I don't quite agree, this is the type of corrections that should make >into the Implementer's guide. When you calculate for a few sessions >it does not make much of a difference, but there are high-scale GWs >and GKs based on 323 out in the market (supporting multiple DS3s) >and the offset will be too much - it will effect network provisioning. > >- gur > >______________________________________________________________________ > Gur Kimchi > Corporate Director, Advance Technologies, Research and Standards > VocalTec Communications Ltd > web: http://www.vocaltec.com > >-------- On 05/06/99 04:04 PM GMT Paul Long <Plong(a)SMITHMICRO.COM> wrote: > > > > >Steve, > >But H.323, the referencing document via H.225.0 of RFC 1889, says that >bandwidth for the open logical channel bitrate and ARQ is calculated >_without_ >headers. We cannot change this, because it would break existing >implementations. Are you suggesting that flowControlCommand should do it >differently, i.e., include at least the RTP header? The value in >consistently >using the same, although arguably flawed, bandwidth calculations outweighs >the >benefit of having a mix of calculations. > >Paul Long >Smith Micro Software, Inc. > > -----Original Message----- > From: Stephen Casner [SMTP:casner@CISCO.COM] > Sent: Wednesday, May 05, 1999 10:20 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: flowControlCommand and packet overhead > > On Wed, 28 Apr 1999, Paul Long wrote: > > > Therefore, clarification text to the following effect should be >added to > > 6.2.11.2 (in v2) of H.323: > > > > "flowControlCommand applies to the information streams >which >are the > > content of logical channel(s), not including RTP headers, RTP >payload headers, > > network headers and other overhead." > > I'm mostly a lurker on this list, but I thought I would offer >another > perspective. The RTP spec, RFC 1889, says the following: > > Bandwidth calculations for control and data traffic include >lower- > layer transport and network protocols (e.g., UDP and IP) since >that > is what the resource reservation system would need to know. The > application can also be expected to know which of these >protocols >are > in use. Link level headers are not included in the calculation >since > the packet will be encapsulated with different link level >headers >as > it travels. > > At a minimum, I would expect the RTP payload header to be included > because that is specific to the encoding and would not be known by > lower layers. The difficulty in pushing this problem off to lower > layers is that they need to know the packet rate in order to know >how > much overhead the additional headers will add. > -- Steve >

1 0

Re: Draft H.246 Annex C
by Edgar Martinez [1] 07 May '99

07 May '99

Hi Christian, Good timing, In the study D meeting in Washington dc I was asked to put my contribution as a proposal for new annex in h.246. In the contribution I show one example in Annex-A of the RAS messages mapping into ITU INAP other example may include HLR/VLR, MAP and WIN messages. I did not include the parameters mapping. Because, I did not want to do all that work until the concept is approved. (document attached) In any case I have proposed the lower layer sigtran transport (CTP) to carry upper layer protocol for tunneling and interworking. Which should not be any issue with h.246 or the work you are doing..I hope? I will read your contribution as a framework going forward on SS7 interworking. We both/all need to resolve the Transport problem where to terminate the Lower SS7 layers (MTP 1,2,3). That is, where does SS7 ends and IP begins? in the H.323 network i.e., tiphon. Regards, Ed Christian Groves wrote: > > G'Day All, > > Attached is a draft copy of H.246 Annex C. > > As you can see it is Version 0.0 so it needs some > work. It is based on Q.699 as is split into 4 > main sections: > > 1 Overview/Introduction > 2 ISUP to H225 message and parameter mapping > 3 Outgoing Call - H.225 to ISUP > Basic Call > Services > 4 Incoming Call - ISUP to H.225 > Basic Call > Services > > The services sections need some work to align > with the 3pty/conference discussions. > > RAS hasn't been considered in the document yet. > > Comments/addition/amendments welcome. > > Regards, Christian Groves > > ------------------------------------------------------------------------ > Name: h246_annex_c_v_0-0.zip > h246_annex_c_v_0-0.zip Type: Winzip32 File (application/x-zip-compressed) > Encoding: base64 -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 TIPHON & Other Stds -- http://www.cig.mot.com/~martinze/

2 1

Re: flowControlCommand and packet overhead
by Gur Kimchi 07 May '99

07 May '99

Paul Wrote: >>> The value in consistently >>> using the same, although arguably flawed, >>> bandwidth calculations outweighs the >>> benefit of having a mix of calculations. I don't quite agree, this is the type of corrections that should make into the Implementer's guide. When you calculate for a few sessions it does not make much of a difference, but there are high-scale GWs and GKs based on 323 out in the market (supporting multiple DS3s) and the offset will be too much - it will effect network provisioning. - gur ______________________________________________________________________ Gur Kimchi Corporate Director, Advance Technologies, Research and Standards VocalTec Communications Ltd web: http://www.vocaltec.com -------- On 05/06/99 04:04 PM GMT Paul Long <Plong(a)SMITHMICRO.COM> wrote: Steve, But H.323, the referencing document via H.225.0 of RFC 1889, says that bandwidth for the open logical channel bitrate and ARQ is calculated _without_ headers. We cannot change this, because it would break existing implementations. Are you suggesting that flowControlCommand should do it differently, i.e., include at least the RTP header? The value in consistently using the same, although arguably flawed, bandwidth calculations outweighs the benefit of having a mix of calculations. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Stephen Casner [SMTP:casner@CISCO.COM] Sent: Wednesday, May 05, 1999 10:20 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: flowControlCommand and packet overhead On Wed, 28 Apr 1999, Paul Long wrote: > Therefore, clarification text to the following effect should be added to > 6.2.11.2 (in v2) of H.323: > > "flowControlCommand applies to the information streams which are the > content of logical channel(s), not including RTP headers, RTP payload headers, > network headers and other overhead." I'm mostly a lurker on this list, but I thought I would offer another perspective. The RTP spec, RFC 1889, says the following: Bandwidth calculations for control and data traffic include lower- layer transport and network protocols (e.g., UDP and IP) since that is what the resource reservation system would need to know. The application can also be expected to know which of these protocols are in use. Link level headers are not included in the calculation since the packet will be encapsulated with different link level headers as it travels. At a minimum, I would expect the RTP payload header to be included because that is specific to the encoding and would not be known by lower layers. The difficulty in pushing this problem off to lower layers is that they need to know the packet rate in order to know how much overhead the additional headers will add. -- Steve

1 0

Re: Annex G & big messages (and TPKT and Annex E)
by Gur Kimchi 06 May '99

06 May '99

Another point to consider is when to use which transport: for Annex G: small/fast messages should be sent over UDP (e.g. the Access family) large/slow messages should be sent over TCP (e.g. information push/pull) ultimately this is an implementation + network environment issue. for Annex E, I really don't see this as an issue - 225 messages are small (we did specify PER for a purpose) and far between, so the follow the small/fast category. - gur -------- On 05/05/99 04:08 PM GMT Andrew Draper <Andrew.Draper(a)MADGE.COM> wrote: At 09:35 1999-05-04 +0200, ETO wrote: >When an Annex G message will exceed max packet size (typically a >DescriptorConfirm) on UDP, a Reject might be sent, and the session is >repeated on TCP. > >But, isn't our PDU size on TCP also limited? When using TPK, the max pdu >size is 65k too, as seen in RFC-1006.... I don't think this is a problem for Annex G. First, a sensible implementation is probably sending DescriptorRequests over TCP anyway since it expects a large (well larger than MRU) answer anyway so the UDP step described above won't happen (only AccessRequest and ValidationRequest is likely to be sent over UDP). Secondly, the only message likely to run into the maximum message size limit is the DescriptorConfirm (if a descriptor is more than 64K). I don't expect anyone to have a descriptor of 64K or more, but if they do it can be broken down into multiple descriptors, and each one transmitted separately. For call signalling over annex E the message size limit isn't a problem either. Annex E will be transmitting the same call signalling messages as would be sent over TPKT over TCP, so messages of more than 64K aren't allowed (since they wouldn't fit within TPKT), even if anyone can create a plausible one. Regards, Andy -- Andrew Draper -- Principal Development Engineer -- WAVE Software Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks, UK. mailto:adraper@madge.com = = = = = = = = = phone:+44 1753 661329 pgp fingerprint 8776 1F5F DD1B F37E BEF7 1E52 924D F6B7 34CB EFA9

1 0

Re: H.323 AnnexD & mandatory fax OpenLogicalChannel elements
by Kumar, Vineet 06 May '99

06 May '99

Joachim, I think you have a draft version of Annex D and not the decided version. I can't find the sentence you mentioned in your email in my copy of Annex D. vineet -----Original Message----- From: joachim.fabini(a)SEA.ERICSSON.SE [mailto:joachim.fabini@SEA.ERICSSON.SE] Sent: Thursday, May 06, 1999 2:20 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H.323 AnnexD & mandatory fax OpenLogicalChannel elements Hi all, >From H.323 AnnexD, D.7: "The H.323 AnnexD gateway shall send both a voice and a fax OpenLogicalChannel element in the setup message". Could anyone envolved in the development of AnnexD please outline the facts behind the _mandatory_ voice _and_ fax OpenLogicalChannel elements? Does this really mean that a H.323 gateway needs to open (or, at least offer) a fax channel beside each voice call if it intends to be also AnnexD compliant? The gateway can decide on the type (voice, fax) of the connection anyhow only _after_ the end-to-end voice channels are connected. Thanks in advance, Regards --Joachim Fabini --------------------------------------- Joachim Fabini Ericsson Austria AG Pottendorfer Strasse 25-27 A-1121 Vienna, Austria voice: +43 1 81100-5127 fax: +43 1 81100-4686 email: Joachim.Fabini(a)ericsson.com ---------------------------------------

1 0