September 2001 - sg16-avd - lists.packetizer.com

Santa Barbara meeting: document list and reminder
by Glen Freundlich 06 Sep '01

06 Sep '01

Greetings Colleagues, We currently have 19 contributions registered for the upcoming Santa Barbara meeting (see the list below). Please remember to register your contribution by close of business on 14 September (earlier is certainly welcome and encouraged), and post the contribution to ftp://standard.pictel.com/avc-site/Incoming by close of business on 17 September. If you have not already done so, please send a note to Paul Jones (paulej(a)packetizer.com) if you plan to attend the meeting. Best Regards, Glen -------------------- This information will be available on the avc-site soon. AVD- Q Title Source 2101 2 Draft H.GEF.1 Tech-Know-Ware 2102 3 MCU Decomposition Polycom 2103 2 Circuit Information Signalling for Alternate Endpoints Cisco 2104 2 Corrections to the H.323 URL Syntax Pagoo 2105 3 Rec. H.248 package definitions ATM Forum 2106 All Concepts of Emergency Communications Service NCS 2107 F Allowable QoS Degradation NCS 2108 G Security for Emergency Communications Service NCS 2109 2, 5 H.GEF.3 (Presence in H.323 Systems) RadVision 2110 G Draft H.235 V3 Editor 2111 G Draft H.235 Annex F Editor 2112 G, 5 Draft H.235 Annex G Editor 2113 G, 2, 5 Extended H.235 error codes Siemens 2114 G Harmonization of media security Q.G Rapporteur 2115 3 Topology enhancement in H.248 Version 2 RadVision 2116 G Liaison Statement to ITU-T SG 16 regarding Mediacom 2004 and MPEG-2 ISO/IEC JTC1/SC29/WG11 2117 G Security for Emergency Communications Service Siemens AG 2118 2 Draft H.323 Annex O Editor 2119 3 H.248 Annex M.1, Advanced Audio Server Packages Editor

1 0

AVD-2116: uploaded liaison from ISO towards Q.G
by Euchner Martin 06 Sep '01

06 Sep '01

Please find contribution AVD-2116 conveying a "Liaison Statement to ITU-T SG 16 regarding Mediacom 2004 and MPEG-21" from ISO/IEC JTC1/SC29/WG11 in the Incoming directory ftp://standard.pictel.com/avc-site/Incoming/AVD-2116LSfromSC29onMedi2004.zip <ftp://standard.pictel.com/avc-site/Incoming/AVD-2116LSfromSC29onMedi2004.zip> The file will be moved to the ftp://standard.pictel.com/avc-site/0109_San/ <ftp://standard.pictel.com/avc-site/0109_San/> directory. Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 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/sr/pages/122/122_euchner.htm <http://intranet.icn.siemens.de/marketing/cs27/> | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.450.6 and Gatekeeper actions
by Callaghan, Robert 06 Sep '01

06 Sep '01

Frank, The basic model for determining busy in H.450.x features is User Determined User-Busy. That is, only the endpoint can truly determine if it is not able to handle additional calls. It is easy for an endpoint to be equipped to handle multiple call instances in a manner similar to keyset operation. In the case of H.450.6 (Call Waiting), this is a destination endpoint controlled feature. The destination endpoint is indicating that it can handle an additional call. However there will be a short delay. If the endpoint cannot handle the call, then it should indicate busy. I fail to see the logic of having the destination GK process Call Waiting. This denies the endpoint the ability to place the existing call on hold and to process the new call. >From an operational viewpoint, I fail to see how a FACILITY message can be sent from the GK to the endpoint when there is no signaling path. In that each call is independent, it is invalid to send signaling for a call on the signaling path for another call. This signaling independence is key to the handling of feature interaction between different calls. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- -----Original Message----- From: Frank Derks [mailto:frank.derks@PHILIPS.COM] Sent: Thursday, September 06, 2001 5:33 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.450.6 and Gatekeeper actions In many of the H.450 Recommendations, the Gatekeeper (in a GK-routed model) can take on the role of one or more of the parties involved in a call and/or supplementary service. In H.450.6, however, this role is limited to the extent that the GK can only act on behalf of the served endpoint towards the calling user. What this means, is that the call to the served user must always be propagated towards the served ednpoint, to be able to _notify_ the served user about an incoming call. Since the GK (in the GK-routed) model knows that the served user is busy, it may not want to propagate the new call to the served user, but it may also want to be able to notify the served user the call. This does not seem to be possible. As a consequence of the reception of the call setup, the served endpoint may invoke some supplementary service (e.g. CFB). This may create a situation of undesired supplementary service interaction, in which both the served endpoint and the GK act on the situation. One possible way out of this situation is to allow for the served endpoint to receive the callWaiting.Invoke in a FACILITY message from the GK. This allows the GK to notify the served user about the fact that there is a call waiting and how many calls are waiting. It, however, does not provide the served endpoint with sufficient information to be able to, e.g., pickup a specific call! Maybe it would be better to introduce a new operation callWaitingNotification, that can be used towards the served user and that will include information (e.g. a list of the Calling Party number(s) and/or Alias(es)) of the calling party(s)) that the served endpoint can use to refer to such a call. Any views? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: Rules for sending H.450.1 APDUs
by Horvath Ernst 06 Sep '01

06 Sep '01

Frank, H.450.1 is the framework for individual supplementary service specifications. Which messages will be used for supplementary service APDUs is specified in these individual specifications, subject to the rules of H.450.1. In particular: - In the context of H.450, a Facility message needs a valid, agreed-upon call reference. - Therefore the sender of Setup shall not send a Facility message before having received a positive response message (e.g. Call Proceeding, but obviously not Release Complete since the call reference would be no longer valid). - The recipient of Setup shall not use Facility as first response message - note that supplementary service APDUs can be included in almost all other possible response messages. The last bullet applies only to H.450 standards. It does not mean that Facility could not be the first response message for other purposes! Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Frank Derks [mailto:frank.derks@PHILIPS.COM] > Gesendet am: Dienstag, 04. September 2001 14:28 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: Rules for sending H.450.1 APDUs > > 6.3/H.450.1 states (the third bullet item): > > "a FACILITY message shall not be sent if a SETUP message previously > sent or received has not been answered" > > It is not clear what constitutes an answer to a SETUP message. Does > this refer to any response that is the effect effect of sending or > receiving a SETUP message? E.g. a SETUP ACKNOWLEDGE or a CALL > PROCEEDING as "response" to having received a SETUP? > > Regards, > > Frank > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

MSCs in H.450.5
by Frank Derks 06 Sep '01

06 Sep '01

All the MSCs in H.450.5 are identical and are copied (and unmodified) from H.450.2 (Figure 2)!!! Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.450.6 and Gatekeeper actions
by Frank Derks 06 Sep '01

06 Sep '01

In many of the H.450 Recommendations, the Gatekeeper (in a GK-routed model) can take on the role of one or more of the parties involved in a call and/or supplementary service. In H.450.6, however, this role is limited to the extent that the GK can only act on behalf of the served endpoint towards the calling user. What this means, is that the call to the served user must always be propagated towards the served ednpoint, to be able to _notify_ the served user about an incoming call. Since the GK (in the GK-routed) model knows that the served user is busy, it may not want to propagate the new call to the served user, but it may also want to be able to notify the served user the call. This does not seem to be possible. As a consequence of the reception of the call setup, the served endpoint may invoke some supplementary service (e.g. CFB). This may create a situation of undesired supplementary service interaction, in which both the served endpoint and the GK act on the situation. One possible way out of this situation is to allow for the served endpoint to receive the callWaiting.Invoke in a FACILITY message from the GK. This allows the GK to notify the served user about the fact that there is a call waiting and how many calls are waiting. It, however, does not provide the served endpoint with sufficient information to be able to, e.g., pickup a specific call! Maybe it would be better to introduce a new operation callWaitingNotification, that can be used towards the served user and that will include information (e.g. a list of the Calling Party number(s) and/or Alias(es)) of the calling party(s)) that the served endpoint can use to refer to such a call. Any views? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Limited Openings #2608
by Lenny Resorte 06 Sep '01

06 Sep '01

*Earn $2000 - $5000 weekly-starting within 3-12 weeks. Make what you deserve! *Own your own business. Control your destiny! *Money Freedom=Time Freedom *54% + Gross Profit Margins *No Selling *Work from home, No overhead, or employees. *Fabulous Training & Support *Not traditional MLM, many times more profitable *Multibillion Dollar Travel & Internet Industry The most incredible part of our business is that ALL MY CLIENTS ASK ME TO CALL THEM! DO YOU QUALIFY FOR OUR MENTOR PROGRAM? ACCEPTING ONLY A FEW NEW ASSOCIATES This is not a hobby! Serious Inquires Only!! Please reply with the following information NOW! FULL NAME: COMPLETE ADDRESS: EMAIL ADDRESS: PHONE: (Required; area code & number) BEST 2 TIMES TO CALL YOU: TO: mailto:55btr@verizonmail.com?subject=tell_me_more This message is sent in compliance of the new email bill section 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email will be stopped at no cost to you. This message is not intended for residents in the State of WA, NV, CA & VA. Screening of addresses has been done to the best of our technical ability. If you are a Washington, Virginia, or California resident please remove yourself. We respect all removal requests. //////////////////////////////////////////////////// Please remove at: mailto:rxxpp9@netscape.net?subject=remove //////////////////////////////////////////////////// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

incomplete SDL in H.450.3 continued
by Frank Derks 05 Sep '01

05 Sep '01

There is only one SDL diagram in H.450.3 that uses divertingLegInformation4.Invoke and then only as something that is received, without specifying the message(s) in which it could be received (see a previous E-mail message). I would certainly expect at least one situation in which it is sent in the diagrams, but I can't find it. Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

incomplete SDL in H.450.3
by Frank Derks 05 Sep '01

05 Sep '01

Figure 24/H,450.3 (sheet 4) does not specify in which message the divertingLegInformation4.Invoke may be received from the network. The text does not seem to be conclusive, in that it mentions that this operation may be carried in a FACILITY message or "using the call independent procedures as specified in 6.2/H.450.1". Figure 25/H.450.3 (sheet 2) does not specify in which message the divertingLegInformation3.Invoke may be received from the network. According to the text it would seem that a comment should be added, stating that the message may be FACILITY, ALERTING or CONNECT. Regards, Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | ServWare |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | ----------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.GEF.1 - GEF Usage
by Pete Cordell 04 Sep '01

04 Sep '01

Dear All, I've uploaded new text for H.GEF.1 - Usage guidelines for GEF - to my local server so that people have a chance to comment on it before I formally post it on the PictureTel server. The main changes are removal of the syntax method of specification and making it clear that the examples section is informative only. There have also been a number of editorial changes which should not affect the original direction of the document. It can be accessed at: http://www.tech-know-ware.com/HGEF1-Santa-Barbara.zip If you have any comments, let me know and I can sort them out before formal posting to the PictureTel site. All the best, Pete. ============================================= Pete Cordell Tech-Know-Ware pete(a)tech-know-ware.com +44 1473 635863 ============================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 1