March 1998 - sg16-avd - lists.packetizer.com

Fwd: Re: Signalling required SCN call bandwidth
by Michele Bozier WVdevmt-WS 11 Mar '98

11 Mar '98

All, Apologies if you've already seen this email before. So far, the only suggestion I've received is that no endpoints really use the multirate info correctly and so MCUs/ gateway manufacturers have to have knowledge of the type of H.320 call to make, based on the called number. It strikes me that having the ability to at least signal the required bandwidth for the call in the H.225 Setup message, even if you don't include WAN specific call setup parameters such as bonding/H.221-aggregration/Hybrid call, could be of value. What does everyone else think? Michele ---------------------------------------- Michele Bozier Principal Development Engineer Madge Networks, Wexham Springs, Framewood Rd, Wexham, Slough SL3 6PJ, England Tel: +44(0)1753 661331 Fax: +44(0)1753 661011 email:mbozier@madge.com ---------------------------------------- Hi all, I have a question about how to signal a multiple 'B' channel SCN call from an H.323 endpoint. The bearer capability information element in standard Q.931 allows you to signal a Multirate call and then specify the bandwidth (in multiples of 64Kbps) using the optional rate multiplier octet (octet # 4.1). My question is how do I signal an n * 'B' channel call from my H.323 endpoint, where the channels are aggregated using H.221 framing or Bonding? Reading the H.225 standard, the description of the Rate multiplier field indicates that it 'shall' be present if the call is Multirate as per standard Q.931. It then goes on to say that: 'For a call originated from an H.323 endpoint, this SHALL be used to indicate the bandwidth to be used for this call'. Is this field only mandatory if I am doing Multirate, or is the intention that it should be used to indicate the number of 'B' channels irrespective of how the ISDN call is placed (Multirate,multi-H.221 or Bonded)? (My understanding of pure Q.931 is that it really only ought to be present in the Multirate case). If I can't use the rate multiplier octet in the non-Multirate case, is there a standard way I can signal a 2 * B, or 6 * B channel call? Thanks in advance for your help! Michele Bozier

1 0

Fwd: GK-handled call diversion.
by Michele Bozier WVdevmt-WS 11 Mar '98

11 Mar '98

Hi all, I have a question about the H450.3 Call Diversion recommendation when the gatekeeper handles the diversion. Figure 12 in section 10 shows the signalling flow for Call forwarding unconditional being handled by a gatekeeper. My concern is that the figure shows the gatekeeper informing the 'called' user that the call has been diverted away from it, using an H.225 Setup message. In order for this not to create confusion, the gatekeeper must know that the called user understands H450.2 (e.g. if the called user were a Version 1 endpoint then it would surely wrongly interpret this Setup as an incoming call). The text in the standard which relates to the sending of this information to the called user (H450.2 APDU divertingLegInformation4), states that this message is sent by the gatekeeper only if the option 'served user notification' applies. As far as I can see, this option is a local configuration matter at the served endpoint. My question is, how does a gatekeeper work out whether or not this option is set in a standard way? Thanks for your help Michele ---------------------------------------- Michele Bozier Principal Development Engineer Madge Networks, Wexham Springs, Framewood Rd, Wexham, Slough SL3 6PJ, England Tel: +44(0)1753 661331 Fax: +44(0)1753 661011 email:mbozier@madge.com

1 0

Re: Far End Camera Control in H.323
by Roni Even 11 Mar '98

11 Mar '98

Hi, FECC is not defined yet in the standards. In the Geneva meeting the decision was to supply basic AVC through the H.323 protocols. One of the areas to be discussed in the Japan Q.13/Q.14 meeting is FECC, contributions are welcome. Roni Even Accord Video Telecommunication email:roni_e@accord.co.il ______________________________ Reply Separator _________________________________ Subject: Far End Camera Control in H.323 Author: <ITU-SG16(a)MAILBAG.INTEL.COM> at internet Date: 3/4/98 4:40 PM Hello all, I have some questions pertaining to Far End Camera Control in H.323. I would appreciate it much if someone could please answer them. Is FECC going to be done through the T.120 channel? If so, then is H.281 encapsulated within t.120 stack? Or has the Standards committee come up with a different scheme to do Far End Camera Control? Thanks in advance, Anupama Phone: 408-922-4785 email: anupama(a)vtel.com

1 0

new job Mascha van Dort
by Dort, M. van 11 Mar '98

11 Mar '98

Dear SG16 colleagues, As from next monday I'll start at a new job at PTT Telecom. I would like to thank you for working together - it's been a pleasure. Maybe we'll meet somewhere. Since my email address will cease to exist, can someone please remove it from the list? regards, Mascha van Dort >temporary email address: mascha(a)happy.demon.nl

1 0

H.323 Annex D in the Incoming directory of gctech ftp site
by Tirtsa Hochberg 11 Mar '98

11 Mar '98

Hello, My name is Tirtsa and I'm working in IBM Haifa with Yoav Meidan and Haim Nelken. I'm interested in reading "The determined version of H.323 Annex D (Real Time Facsimile over H.323)". I tried looking for the gctech ftp site with no success. Do you have a better pointer as of the location of this version? If you do' I will appriciate it if you could send it to me. Thanks Tirtsa Hochberg HRL.

1 0

Re: this may be of interest to this group
by Scott Bradner 10 Mar '98

10 Mar '98

-- This is definitely in the realm of the work that TIPHON is doing. Are there any liaisons between the groups? -- not now but I'd like there to be Scott

1 0

Re: this may be of interest to this group
by Pedro Colaco 10 Mar '98

10 Mar '98

This is definitely in the realm of the work that TIPHON is doing. Are there any liaisons between the groups? By the way, I think we should make an active effort to standardize language. In the voice world the party you refer as "callee" is the "Calling party". The "calling party" calls the "called party". Does this make sense, and if so should we use these terms consistently thorughout all the working groups dealing with IP Telephony (IMTC, ITU, ETSI, IETF)? Best regards Pedro Colaco Sr. Product Manager - InterXpress IP Telephony Product Line Siemens

1 0

H.323 Annex D in the Incoming directory of gctech ftp site
by Vineet Kumar 09 Mar '98

09 Mar '98

Dear Colleagues, The determined version of H.323 Annex D (Real Time Facsimile over H.323) has been posted to the Incoming directory of the gctech ftp site. A number of issues are documented in this draft and I prefer to resolve them before the Yokusuka meeting. Please send your comments/solutions/etc. on this reflector. Thanks. vineet kumar intel corporation (+1) 503-264-3439

1 0

H.323 and NAT
by Annika Kilegran 09 Mar '98

09 Mar '98

Network Address Translation (NAT) is used as a solution to the problem of few available IPv4 addresses. The idea is to use private addresses within a domain and when IP traffic leaves or enters the internal network the address fields are translated between the public IP addresses and the corresponding private address. A private address is only associated with a public address when the node communicates externally. By using this mechanism it is possible to have many more IP nodes in the private domain then the number of assigned public IP addresses to that domain. NAT is a defacto solution to connect for big groups of users. The combination of NAT and applications exchanging IP addresses in the protocol (like H.323 does) creates problems. The applications are either broken, or gets more difficult to run. There are different solutions for how to be able to run these application in combination with NAT. We list the alternatives in the bottom of this mail. Does anybody on the mailing have an opinion? For instance, a Gatekeeper might have to interact with the NAT (co-located), and possibly act as an application gateway. By the way the question might com up on the DAVIC meeting next week. Best regards, Annika Kilegran ********************************************************************** Telia Research S-136 80 HANINGE, Sweden Tel +46 8 707 55 15 Fax +46 8 707 53 10 Email: annika.w.kilegran(a)telia.se *********************************************************************** The differnt alternatives: ----------------------------- 1) Use an Application layer gateway, that translates addresses in the application protocol. Used today for FTP. Will work, but will be quite complex for H.323. The Application layer gateway would typically be co-located with the NAT-box. 2) Use the location of servers, and the configuration of servers and clients to overcome the problem. DNS is handled this way today. Seems not to work for H.323. 3) A combination of alternatives1 and 2 should be possible, and may acheive a lesser complexity than 1. 4) NAT bypass using tunneling over the local network. The global address is available in the host and is used in the application, removing the problem. This kind of solution have been proposed in contributions to IETF. 5) Skip NAT altogether. Instead use IPv.6, or something like NNAT (No NAT) for IPv.4. NNAT will completely replace NAT, and uses DHCPv.6 for assigning global addresses. NNAT remains to be specified for IPv.4 operation.

2 1

this may be of interest to this group
by Scott Bradner 09 Mar '98

09 Mar '98

If you have comments please send them to me Scott ---

1 0