- sg16-avd - lists.packetizer.com

Limited Openings #2608
by Lenny Resorte 05 Sep '01

05 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

Rules for sending H.450.1 APDUs
by Frank Derks 04 Sep '01

04 Sep '01

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

1 0

AW: Private Numbering Plans and the Called/Calling party number I Es
by Horvath Ernst 03 Sep '01

03 Sep '01

Frank, the reason for these complicated rules is backwards compatibility. Originally numbers were only used in implicit form and assumed to be "(more or less) E.164" (this alternative of an alias address is now more correctly termed "dialled digits"). The indicator "private numbering plan" meant that the UUI contained the alias address. With version 2, structured party numbers were introduced (E.164 and private numbering plans). Still, the decision between party number information elements and UUI address-fields was mostly left to the implementor. This unsatisfactory situation is clarified in version 4. The main principles are: - for a calling number in implicit form or explicit E.164 form, use the calling party number information element, but for an explicit PNP number use the sourceAddress field; - for a destination number in implicit form or explicit E.164 form, use the called party number information element, but for an explicit PNP number use the destinationAddress field (exception: in INFORMATION messages used for overlap sending, PNP number digits are also transported in the called party number information element); - for a connected number, use the infornmtion element (here the PNP indicator has no special meaning); - in all other cases use the UUI fields. Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Frank Derks [mailto:frank.derks@PHILIPS.COM] > Gesendet am: Dienstag, 21. August 2001 14:32 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: Private Numbering Plans and the Called/Calling party > number IEs > > 7.2.2.4/H.225.0 and 7.2.2.6/H.225.0 state that if the > numbering plan information is set to "private" (in a packet > based network originated call), that this indicates that the > number itself is _not_ present in the IE, but in the > User-User information. > This is not the case for the Connected Number, as this is > encoded per Q.951. > > Strangely enough 7.3.10/H.225.0 states (under the description > of destinationAddress) that, if an endpoint uses only a > dialled digit string that this address _shall_ be placed in > the Called party number IE and (under the description of > sourceAddress) that > if the source has an E.164 address that this _shall_ be > contained in the Calling party number IE. This would seem to > contradict the statements in 7.2.2.4 and 7.2.2.6. > > Furthermore, it is not clear to me why private numbers can't > just be put in the Called/Calling party number IEs? > > 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

Returned mail: Disk Quota is Full!!
by Ktland 03 Sep '01

03 Sep '01

1 0

AW: H.450.2 and overlap sending?
by Horvath Ernst 03 Sep '01

03 Sep '01

Frank, according to the general design principle of H450 series, H.450.2 (call transfer) functionality by default resides in the endpoint. Thus the determination of user C's address becomes a local matter outside the scope of H.450.2. It could be collected from key strokes, retrieved from a directory or data base, or whatever. In the first case the call transfer functionality at user A's endpoint should prevent any digits to get out on the line (otherwise these would be treated as DTMF signals since the primary call is already in active state). If the call transfer functionality resides in a proxy or GK rather than in endpoint A, the interface between endpoint and proxy/GK is outside the scope of H.450.2 (e.g. stimulus according to annex L). Again the call transfer functionality should take care of collecting digits entered over that interface. So there should never be a need for "overlap sending" as part of call transfer operations. Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Frank Derks [mailto:frank.derks@PHILIPS.COM] > Gesendet am: Mittwoch, 22. August 2001 13:37 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: H.450.2 and overlap sending? > > In the case where no secondary call exists, an initiating endpoint > (the A-party) has the choice of first setting up a secondary call > and then transferring at some stage, or to simply start the transfer > (a "blind" transfer" through a FACILITY message containing a > ctInitiate.Invoke. In the latter case the reroutingNumber in the > CTInitiateArg contains the (whole) number of the "C-party". > > What this implies is that the A-party must have some way of > collecting entered digits and deciding when the number is complete, > after which it sends the FACILITY message with the ctInitiate.Invoke > or the user interface of the A-party must be such that it allows > for entering a number for this purpose, after which transfer can > be interactively activated, resulting in the sending of a FACILITY > message with the ctInitiate.Invoke. > > There does not seem to be an obvious (or even possible) way to > indicate to the receiving party that a transfer should be effected > (E.g. through a ctInitiate.Invoke with an empty reroutingNumber) > after sufficient number information has become available (E.g. in > INFORMATION messages). This means that endpoints that would > normally translate keypresses on the keypad to sending INFORMATION > messages, would have to have special provisions to deal with this > situation. > > Is this a correct interpretation of the Reommendation? > > 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

Can you email H.323 Annex-I to me?
by ��ˬ 02 Sep '01

02 Sep '01

hi, I'm interested in mobility of h.323,Now I have the protocol of H.323 Annex-H, but I don't have H.323 Annex-I and H.246 Annex-E.Because I can't access to Internet, Can you email the Protocol of H.323 Annex-I and H.246 Annex-E? Thank you! Best Regards! Shuang Li Email to njuptlsh(a)263.net ___________________________________________IP卡、上网卡两折史奴比、蜡笔小新全家福华语排行榜颁奖典礼天赢炒股,天生我赢!

2 1

Called/Calling party in Q.931 IEs or in source/destinationAddress?
by Frank Derks 31 Aug '01

31 Aug '01

7.3.10/H.225.0 States the following about address information in the sourceAddress and destinationAddress fields: sourceAddress: "Note that the E.164 number of the source, if any, shall be contained within the Calling Party Number Information Element." destinationAddress: " When calling an endpoint using only a dialed digit string, this address shall be placed in the Q.931 Called Party Number IE." First of all there is a difference in terminology. The description of sourceAddress uses "E.164 number", whereas the description of destinationAddress uses "dialed digit string". These are different concepts. Nevertheless, assuming that in both cases we're talking about an Alias that consists of digits (i.e. a number), it is not clear whether such information must only be present in the Called/Calling Party Number IEs, or whether it is allowed to also include this information in the sourceAddress and/or destinationAddress fields. Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0