Dear SG16 Q.11, Q.12-14 Experts,
As we have announced earlier, March 20 is the deadline for the
registration and hotel reservation for the SG16 Yokosuka meeting.
If you plan to attend the meeting, please register as soon as possible
according to the following directions;
1) Registration form should be sent to "harasaki(a)ccm.cl.nec.co.jp"
with copy to Rapporteurs.
2) Hotel reservation form should be faxed to Yokosuka Prince Hotel.
Block room reservation will expire on March 20, however, …
[View More]the hotel will
continue to accept your reservation at the same price after the deadline
only if the rooms are available.
Registration and hotel reservation forms are attached to this mail.
Best regards,
Hidenobu Harasaki, NEC Corporation
Kiyoshi Sakai, Fujitsu Laboratories LTD.
**********************************************************************
Kiyoshi Sakai
Media Processing Laboratory
Multimedia Systems Labs.
FUJITSU LABORATORIES LTD.
Tel. : +81 44 754 2679
Fax. : +81 44 754 2347
E-mail : sakai(a)flab.fujitsu.co.jp
**********************************************************************
[View Less]
Forwarded to the ITU email reflector for SG16/Q.11in hopes that some if not
all of the ITU member experts will get it during the time the normal q.11
reflector is not operating.
Thanks, Tom Geary
-------------------- Forwarded by Tom A Geary/RSS/Rockwell on 16-03-98
22:42 ---------------------------
Tom A Geary
14-03-98 21:04
To: sg16.lbc(a)research.kpn.com, webberr(a)pictel.com
cc:
Subject: New files on q11-site (lbc-site)
Dear SG16 Q.11 Experts:
I have uploaded files for the …
[View More]proposed agendas for Yokosuka and Tampere
Q.11 experts meetings, q11dtd2.doc an q11etd2.doc.
Also I have assigned a number to the invitation (and in the case of
Tampere, the registration) letters from our gracious hosts and have
uploaded these as well, q11d01.doc for Yokosuka and q11e01.doc along with
q11e05.doc for Tampere.
I have also uploaded a document for each meeting, q11d04.doc and q11e04.doc
which is the updated SG16 Q.11 meeting report (with change marks from the
one presented in the WP2 meeting in Geneva adding missing TD numbers and
revising the agenda of the Yokosuka and Tampere meetings) as discussed in
the WP2 meeting.
Mr. Webber:
Can you move all files with q11dnn.ccc names to the /yokosuka.April98
folder and all with q11enn.ccc names to the /tampere.April98 folder. (Also
you can delete file Q11_trac from the /lbc-site/dropbox, it was just a
reference file for the Q.11 documents to the January Geneva meeting and .)
Also please move files h223c_13_details.zip and h324c_21_details.zip to the
/lbc-site/LBCmobile/documents directory.
Thanks,
Tom Geary
[View Less]
fyi - the IETF IPTEL working group has been formed and will be meeting
during the IETF meeting in LA the end of the month.
The charter for the working group, along with information about
subscribing to the mailing list can be found at
http://www.ietf.org/html.charters/iptel-charter.html
Scott
-------------------------------
Die MS Mail Adresse Ihres Teilnehmers "Euchner Martin ZT IK 3" ist nur noch
bis Juni 98 gueltig und wurde an die neue Exchange Adresse weitergeleitet.
Sie finden die neue Exchange Adresse im Adressbuch
- des MS Mail Clients unter "Globaler Adressliste -> Euchner
Martin(Exchange)"
- des Exchange Clients unter "Globaler Adressliste -> Euchner Martin".
Passen Sie ggf. Ihr pers. Adressbuch an.
MfG SBS CS
Dear Mr. Korpi,
In response to your request, the following APC numbers have been
allocated to your three contributions:
APC-1328 Proposal for Call Hold Supplementary service in H.323
(H.450.Hold)
APC-1329 Proposal for Call Park/Call Pickup supplementary service in
H.323 (H.450.Park+Pickup
APC-1330 Proposal for Call Waiting Supplementary Service H.323
(H.450.CallWaiting)
Best regards,
Sakae OKUBO (Mr.)
********************************************************************
Graphics …
[View More]Communication Laboratories Phone: +81 3 5351 0181
6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184
4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp
151-0053 Japan
********************************************************************
[View Less]
> Toby, Jim, Pete and all others!
>
> During the implementation of Fast Connect Procedure, we found two
> pitfalls regarding the use of Transport Addresses as it are currently
> defined. For compatibility sake I provide following > clarifications for your revision:
>
> 1. In chapter 8.1.7.1 Proposal, Selection, and Opening of Media
> Channels is written:
> "The mediaChannel element shall be set appropriately according to the
> calling endpoint requirements; …
[View More]different values may be used in
> alternative proposals if desired."
>
> As a part of the "Fast Connect Procedure", it is the responsibility of
> the called endpoint to decide about the coupling of proposed incoming
> and outgoing media streams for each SessionId. According to RTP/RTCP
> specifications, such a couple uses a common RTCP channel. Besides
> there are implementations, that rely on dependency between RTP and
> RTCP ports values.
> As a result of all that, "different values" for proposed (by the
> calling endpoint) mediaChannels can NOT be used within the same
> SessionId.
> It means that in the SETUP message all alternative OpenLogicalChannel
> structures, that propose a channel for transmission from the called
> endpoint to the calling endpoint, shall contain not only the same
> sessionID value but also the same mediaChannel value.
>
> 2. The "Fast Connect Procedure" doesn't explicitly define how the RTCP
> port values are provided. In order to support the general case
> (including one direction media transmission) and in accordance with
> (1) above, the following procedures shall be performed in addition to
> the described in H.323.
>
> In the SETUP message, each OpenLogicalChannel which proposes a channel
> for transmission from the calling endpoint to the called endpoint,
> shall contain mediaControlChannel element (indicating the reverse RTCP
> channel) into the H2250LogicalChannelParameters element of the
> forwardLogicalChannelParameters structure.
> In the SETUP message, each OpenLogicalChannel which proposes a channel
> for transmission from the called endpoint to the calling endpoint,
> shall contain mediaControlChannel element (indicating the RTCP channel
> going in the same direction) into the H2250LogicalChannelParameters
> element of the reverseLogicalChannelParameters structure.
> All mediaControlChannel elements inserted by the calling endpoint for
> the same sessionID for both directions shall have the same value.
>
> When accepting a proposed channel for transmission from the calling
> endpoint to the called endpoint, the called endpoint shall return the
> corresponding OpenLogicalChannel structure to the calling endpoint,
> inserting a valid mediaControlChannel element (indicating the RTCP
> channel going in the same direction) into the
> H2250LogicalChannelParameters element of the
> forwardLogicalChannelParameters structure.
> When accepting a proposed channel for transmission from the called
> endpoint to the calling endpoint, the called endpoint shall return the
> corresponding OpenLogicalChannel structure to the calling endpoint,
> inserting a valid mediaControlChannel element (indicating the reverse
> RTCP channel) into the H2250LogicalChannelParameters element of the
> reverseLogicalChannelParameters structure.
> All mediaControlChannel elements inserted by the called endpoint for
> the same sessionID for both directions shall have the same value.
>
> I propose that we put such sort of clarifications into H.323
> Implementers Guide.
> What is your opinion and what is the procedural way to do that?
>
> Best Regards,
Orit Levin
RADVision Inc. E Mail: orit(a)radvision.com
575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230
Mahwah, NJ 07430 Fax: 201-529-3516
[View Less]
See my in-line comments below:
--Markku Korpi
>-----Original Message-----
>From: Michele Bozier WVdevmt-WS [SMTP:mbozier@MADGE.COM]
>Sent: Wednesday, March 11, 1998 6:19 PM
>To: ITU-SG16(a)mailbag.jf.intel.com
>Subject: Fwd: GK-handled call diversion.
>
>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
&…
[View More]gt;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).
>[MKo] The Notification Setup of H.450.2 contains in the Bearer
>Capability/Octet 3 "call independent signaling connection". Since the BC is
>a mandatory IE in H.323 version 1, the correct response should be Release
>Complete message with Cause=Mandatory information element error. Therefore
>the interpretation of the Notification as an incoming call is not legal
>according to H.323 V.1.
>
>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?
>[MKo] The GK would have some network management functions, by means of which
>the local configuration can be influenced either by the user or by the
>network manager or by both.
>Therefore we do not need signaling capabilities in the H.450.3 for this
>purpose.
>
>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
[View Less]
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-…
[View More]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
[View Less]
