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

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