Dear Mr. Korpi:
I guess that it is the time to hear publicly from you how you want to
organize the conference calls and contributions related to above annexes.
It is excellent that Mr. Sundquist has produced a draft for H.323 Annex H
that has been set as a baseline for discussions and bringing contributions.
However, we like to know more about your plan the way you want to proceed:
Conference calls, Contributions, Coordination among Annexes, etc.
Best regards,
Radhika R. Roy
H.323 Mobility …
[View More]Ad Hoc group
+1 732 420 1580
> -----Original Message-----
> From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com]
> Sent: Tuesday, June 06, 2000 7:01 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: [H.323 Mobility:] New H.323 Annex H Draft
>
> Hi folks,
>
> I have uploaded a new draft of the H.323 Annex H to the following URL:
> ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-101_H323AnnexH
> Dr
> aft.zip .
>
> This draft contains material from the TD-28 of the Osaka meeting in
> addition
> to the TD-47, which contained the H.323 Annex H Draft produced in the
> Osaka
> meeting. I suggest that we use this document as the baseline for the work
> from now on.
>
> I will not be very active on this reflector this week, because of other
> urgent chores at work, but I will try to produce some new ideas next week
> and also encourage you to make contributions as soon as possible.
>
> ------------------------------------------------
> Jaakko Sundquist *
> +358 50 3598281 * Audere est Facere!
> jaakko.sundquist(a)nokia.com *
> ------------------------------------------------
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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
[View Less]
Hi folks,
I have uploaded a new draft of the H.323 Annex H to the following URL:
ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-101_H323AnnexHDr
aft.zip .
This draft contains material from the TD-28 of the Osaka meeting in addition
to the TD-47, which contained the H.323 Annex H Draft produced in the Osaka
meeting. I suggest that we use this document as the baseline for the work
from now on.
I will not be very active on this reflector this week, because of other
urgent chores at …
[View More]work, but I will try to produce some new ideas next week
and also encourage you to make contributions as soon as possible.
------------------------------------------------
Jaakko Sundquist *
+358 50 3598281 * Audere est Facere!
jaakko.sundquist(a)nokia.com *
------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
1
0
AW: H.450-3
by Klaghofer Karl ICN SIB NL D1
06 Jun '00
06 Jun '00
Wolfgang,
The Remote Activation procedures (activateDiversionQ.inv) were intended to
be used for remote activation.
For local activation of diversion at the endpoint, activation is of local
significance only and is thus out of the scope of the recommendation.
However, the Remote Activation procedures may be used for activation of
diversion from a activating/served endpoint at its lokal GK. This has been
introduced in the late phase of H.450.3 standardization within clause 9.2.2.
>From the …
[View More]signalling point of view it is a regular H.450 non call related
SETUP including the activateDiversionQ.inv that is sent from the
activating/served EP to the GK.
Regards,
Karl Klaghofer
> -----Ursprüngliche Nachricht-----
> Von: Wolfgang Bandow [SMTP:wolfgang.bandow@DETEWE.DE]
> Gesendet am: Monday, June 05, 2000 15:24
> An: ITU-SG16(a)mailbag.cps.intel.com
> Betreff: H.450-3
>
> Hello H.450-Experts!
>
> I've got a question concerning the activation of call forwarding in
> cases when the served endpoint
> shall be represented by a gatekeeper.
>
> The standard distinguishes between the activating and the served
> endpoint but does not give sufficient
> information for the case that activating and served endpoint are both
> the same.
> Is there any message flow when activating call forwarding by the served
> user (locally)?
> Is the corresponding gatekeeper somehow informed about this activation?
>
> Thanks a lot for your reply.
>
> Regards,
> Wolfgang Bandow CT-B / Berlin
> << Datei: Visitenkarte f|r Wolfgang Bandow >>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Dear Mike,
>Could you please tell me when the white paper deadline is for SG16
>decision documents for the November meeting.
The report of SG16 meeting last February is available as COM16-R61 at
http://www.itu.int/itudoc/itu-t/com16/reports
and its Section 3.8.2 (determined draft Recs) states as follows:
The final edited texts of these draft revised and new Recommendations
should be provided by the editor/rapporteurs as a normal contribution to
reach TSB prior 15 July 2000 for …
[View More]consideration at the November meeting of
SG 16. It should be noted that the planned meeting of WP1/16 at the end of
June 2000 will very likely determine other Recommendations, in accordance
with their work programme.
Best regards,
Sakae OKUBO
***********************************************************
Waseda Research Center
Telecommunications Advancement Organization of Japan (TAO)
5th Floor, Nishi-Waseda Bldg.
1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo
169-0051 Japan
Tel: +81 3 5286 3830 (to be transferred)
+81 3 3204 8194 (direct)
Fax: +81 3 5287 7287
e-mail: okubo(a)giti.or.jp
***********************************************************
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Do you play the lottery?
We can't guarantee you will win, but with today's
technology and the internet we can drastically
improve your odds.
Did you know 1/3 of all lotterys are won by groups
or clubs!!
If you are already a player or would like to start
playing within a club
please reply to:
mailto:bb209b@yahoo.com?subject=more_info
with the following "info"
Name: _________________________________________
Email Address: __________________________________
Address …
[View More]__________________________________________
City ________________________ ST _____ ZIP __________
Phone (_______) __________________________ Best time to call
The above information is required to receive the requested
information.
*****************************************************************
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 may be
stopped at no cost to you. This message is
not intended for residents in the State of WA, 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.
=========================================
If you wish to be removed from future mailings, please Reply to:
mailto:drisck@netscape.net?subject=remove
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
I fully agree with Orit.
So far, I haven't heard of anybody that actually implemented clearing the
call
if both fastStart and h245Control are present in SETUP. I would argue, it
would
be a very bad implementation, regardless of what they interpreted the spec
saying.
This being said, it seems that it will not create any interoperability
problems.
The *worst* case scenario (here again, I haven't heard of anybody that
actually implemented it that way) is that the call would proceed as fast
…
[View More]tunnelling (as per the spec) and ignore the fast start.
The benefits of doing the fastStart and the fast tunnelling at the same time
far outweight the theoretical backward compatibility problems.
If anybody wants to revoke the Osaka agreement, contributions in Portland
are
welcomed. ;^)
> -----Original Message-----
> From: Orit Levin [mailto:orit@RADVISION.COM]
> Sent: Wednesday, May 31, 2000 8:32 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
>
>
> Hi Paul and all the others!
> Here it is (and it is not surprising for those, participated in Osaka
> meeting).
> I believe, that it is the last moment to clear the confusion
> in the least
> harmful way (even on the expense of THEORETICAL H.323v.2 "strict"
> implementations).
> RADVision definitely votes for allowing Fast Connect and
> H.245 tunneling in
> Setup, supporting by that TD-26.
> Best Regards,
> Orit Levin
> RADVision Inc.
> 575 Corporate Drive Suite 420
> Mahwah, NJ 07430
> Tel: 1 201 529 4300 (230)
> Fax: 1 201 529 3516
> www.radvision.com
> orit(a)radvision.com
> -----Original Message-----
> From: Paul E. Jones <paulej(a)PACKETIZER.COM>
> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM>
> Date: Wednesday, May 31, 2000 1:46 AM
> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
>
>
> >Pete,
> >
> >If we could follow such logic, I would agree that this
> procedure would be
> >worth perusing. Unfortunately, the inclusion of fastStart
> and tunneled
> >H.245 messages in the SETUP message is not defined. There
> is no way to
> >predict how a V2 device will behave when receiving these
> messages. I like
> >the idea, but I'm afraid we will compromise backward compatibility by
> >including it.
> >
> >Let's assume a V2 device does *not* recognize the tunneled
> H.245 in SETUP
> >(ignores it), but accepts the Fast Connect proposal.
> Assume, also, that in
> >the CONNECT message, the endpoint includes the fastStart
> element *and* a
> >tunneled TCS message. What could the calling endpoint
> *safely* assume?
> >
> >Assume that CONNECT was the first message received following
> the SETUP if
> >that helps complicate matters further for you. :-)
> >
> >I just need further convincing.
> >
> >Paul
> >
> >----- Original Message -----
> >From: "Pete Cordell" <pete(a)TECH-KNOW-WARE.COM>
> >To: <ITU-SG16(a)mailbag.cps.intel.com>
> >Sent: Tuesday, May 30, 2000 2:40 PM
> >Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
> >
> >
> >> RE: On TD26 - Fast TCS and M/S negotiation in H.323v4Hi
> Paul, Francois,
> >and
> >> others,
> >>
> >> I think it is important that we make it work, but as you
> say, it has to
> be
> >> reliable and any burden of insuring backwards
> compatibility has to be
> >placed
> >> on the newer EP. In this case it is primarily an issue
> for the calling
> >EP.
> >>
> >> As I see it, (and I'm sure you'll correct me if I'm not
> seeing it right!)
> >> when there is H.245 in the SETUP message, then the called
> endpoint can
> >> either ignore the H.245, or accept it. (It could clear
> the call, but
> I'll
> >> ignore that one for the time being.) There is also the
> case where it
> >> decides that the H.245 takes precedence over fast start.
> >>
> >> Knowing whether fast start has been accepted is fairly
> straight forward.
> >>
> >> I think the called endpoint has a very good idea of what
> decision was
> >taken
> >> with regard to the H.245 based on the reply from the
> called endpoint.
> >>
> >> - If the reply message in which the fast start information
> is contained
> >> contains H.245, then it can assume that the called EP
> accepted the H.245.
> >> The H.245 state about which channels are open will be
> updated according
> to
> >> the fast start parameters.
> >>
> >> - If the reply message in which the fast start information
> is contained
> >> contains no H.245, then it has probably ignored the H.245.
> >>
> >> --- If H.245 tunneling is enabled, but the calling
> endpoint believes that
> >> the called endpoint ignored its H.245 in the SETUP
> message, then it can
> >> re-transmit its capability set when it becomes OK to do so
> under the
> >normal
> >> fast start/H.245 rules. (It should probably modify the
> sequence number
> >> before doing this.)
> >>
> >> --- In the case where the called EP actually did accept
> the H.245 but did
> >> not reply as expected, the called EP will receive a second
> capability
> set.
> >> However, endpoints should be able to handle this as this
> is a standard
> >H.245
> >> procedure.
> >>
> >> So as long as V4 endpoints use this kind of logic then I
> think it is safe
> >> for them to combine both H.245 and fast start.
> >>
> >> Perhaps we should document the above more formally for V4,
> and maybe say
> >> that if a V4 EP wants to accept both fast start and H.245
> Cap tunnelling
> >at
> >> the same time then it SHALL put the fast start and H.245
> in the same
> >> message.
> >>
> >> Does this sound in any way reasonable?
> >>
> >> Pete.
> >>
> >> =============================================
> >> Pete Cordell
> >> pete(a)tech-know-ware.com
> >> =============================================
> >>
> >> ----- Original Message -----
> >> From: Paul E. Jones
> >> To: Francois Audet ; Mailing list for parties associated
> with ITU-T Study
> >> Group 16 ; pete
> >> Cc: Alexander (Sasha) Ruditsky ; Dale Skran
> >> Sent: 30 May 2000 08:20
> >> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
> >>
> >>
> >> Francois,
> >>
> >> But the possibility exists that a V2 device may accept
> both, reject one
> or
> >> the other, or reject both since a SETUP containing
> fastStart and tunneled
> >> H.245 is "illegal". Heck, a "strict" endpoint may even
> drop the call,
> but
> >I
> >> suspect that nobody would go that far.
> >>
> >> If fastStart was accepted and the remote end returns the
> tunneling flag
> >set
> >> to TRUE, how do you know if it did or did not process the
> H.245 message
> in
> >> the SETUP? I'm not convinced that this procedure is going to make
> >everybody
> >> happy. (Same could be said if fastStart is not accepted,
> I suppose.)
> >>
> >> My concern is that this issue is potentially damaging to some
> >> implementations. If all of the vendors have no problem
> with this change,
> >> then I can live with it. Cisco has no objection, but I
> would like to
> >> solicit the input of others-- changes like this, even as
> good as they
> are,
> >> could cause serious problems.
> >>
> >> It appears that we've already made a similar "mistake" by
> allowing H.245
> >> procedures to be done in parallel to fastConnect by
> removing the clause
> >that
> >> says that if we start H.245, fast connect is terminated.
> That text was
> >> removed, because there was a race condition that could
> occur, which could
> >> result in interoperability problems. The right solution
> probably should
> >> have been to document the race condition and tell people
> "don't do that".
> >> However, we made the change and now some manufacturers have serious
> >backward
> >> compatibility problems. I don't want to make the same
> mistake again.
> >>
> >> Comments?
> >>
> >> Paul
> >>
> >> ----- Original Message -----
> >> From: Francois Audet
> >> To: 'Paul E. Jones' ; Mailing list for parties associated
> with ITU-T
> Study
> >> Group 16 ; pete
> >> Cc: Alexander (Sasha) Ruditsky ; Dale Skran
> >> Sent: Monday, May 29, 2000 11:00 PM
> >> Subject: RE: On TD26 - Fast TCS and M/S negotiation in H.323v4
> >>
> >>
> >> Yes, a few comments:
> >> 1 It seems that all current implementations that we could think of
> >> would simply ignore the tunnelling information if the fastStart
> >> element is present. This means, that there would be no
> >> interoperability problems. Fast start would be
> sucessfull, but not
> >> tunnelling, which would mean that tunnelling would have to happen
> >> after the SETUP message, as per H.323v2 and v3.
> >> 2 There is a small possibility that an implementation
> would acutally
> >> give priority to the tunnelling information instead of
> the fastStart
> >> element (v2 and v3 don't say what would happen if they
> are present,
> they
> >> just say not to do it). In that particular case, the
> fastStart would
> >fail
> >> but the tunnelling would be successful. So the worst
> case scenario is
> >that
> >> fastStart fails, but "fast tunnelling" is successful.
> This doesn't seem
> >to
> >> me to be a real interoperability problem. In any case,
> it seems that
> >case
> >> 1 is much more likely.
> >>
> >>
> >> > -----Original Message-----
> >> > From: Paul E. Jones [mailto:paulej@packetizer.com]
> >> > Sent: Monday, May 29, 2000 7:46 PM
> >> > To: Mailing list for parties associated with ITU-T Study
> >> > Group 16; pete
> >> > Cc: Audet, Francois [SC9:4K02:EXCH]; Alexander (Sasha)
> Ruditsky; Dale
> >> > Skran
> >> > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
> >> >
> >> >
> >> > Pete, Sasha, Francois, Dale, et al,
> >> >
> >> > I have concerns about this document that differ from Pete's.
> >> > However, since
> >> > discussion on this document has started, I thought I might as
> >> > well express
> >> > my concerns now while the material is fresh on people's minds.
> >> >
> >> > The issue has to do with the very first sentence of the
> >> > proposal, which says
> >> > to strike "shall not" and replace it with "may". So, V2
> >> > devices shall not
> >> > send a fastStart element and an H.245 message in SETUP, but
> >> > V4 may. This
> >> > seems to be a serious backward compatibility issue. If a V2
> >> > device were to
> >> > receive a SETUP containing fastStart and an encapsulated
> >> > H.245 message, what
> >> > would it do? I believe the behavior is not defined.
> >> >
> >> > Would somebody like to comment?
> >> >
> >> > Paul
> >> >
> >> ... cut ...
> >>
> >>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >> 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
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
[View Less]
Hello H.450-Experts!
I've got a question concerning the activation of call forwarding in
cases when the served endpoint
shall be represented by a gatekeeper.
The standard distinguishes between the activating and the served
endpoint but does not give sufficient
information for the case that activating and served endpoint are both
the same.
Is there any message flow when activating call forwarding by the served
user (locally)?
Is the corresponding gatekeeper somehow informed about this …
[View More]activation?
Thanks a lot for your reply.
Regards,
Wolfgang Bandow CT-B / Berlin
[View Less]
Folks,
While talking with people recently about some features in H.323 version 3, I
discovered that a couple of fields in H.225.0v3 contained an error.
Specifically:
o "useAnnexECallSignalling" in RCF was supposed to be OPTIONAL
o "useAnnexECallSignalling" in ACF was supposed to be OPTIONAL
o "supportsAnnexECallSignalling" in LCF was supposed to be OPTIONAL
The field descriptions in the H.225.0 document correctly describe the fields
as if they were OPTIONAL, which followed the agreed text …
[View More]from TD-23 in the
Monterey meeting.
In order to correct these errors, I brought a contribution to the Osaka
meeting proposing to make these three fields OPTIONAL by making a correction
to the Implementers Guide. Participants at the meeting were in agreement to
make these corrections, especially since H.225.0v3 has not been published
yet.
However, since a change such as this will break backward compatibility
anyway, the attendees decided to go beyond simply making these 3 small
editorial corrections. Instead, a proposal was made to replace these fields
with new fields that have an expanded scope. It will now be possible to
provide "AlternateTransportAddresses" for various transports: Annex E, SCTP,
or something else (currently, only Annex E is defined). In addition, the
Gatekeeper, knowing what is supported, may specify which transport an
endpoint shall use.
I did not object to this proposed change because it looks reasonable and,
given that H.225.0v3 is so new, I did not expect it to have a serious
impact. However, I have been made aware that a few vendors have or are in
the process of implementing H.323v3. This means that we must solidify this
ASN.1 change. The participants in Osaka agreed to the proposed changes
(attached as a Word document). I believe they are reasonable, but we cannot
wait until November, which is when the official vote will be made by the
various world governments, to approve those fields: by that time, H.225.0v3
will be published and will have been in a Decided state for 14 months!
So, I want to hear people's comments: are all of the vendors comfortable
with these changes? I do not believe that any vendor would be put in an
uncomfortable position today, so I want to get agreement that we will accept
these ASN.1 changes now. I do not want to see a contribution in the
November meeting proposing to change these structures in any way-- hopefully
what we agreed to in Osaka is acceptable to everybody and we will have no
objections. If there are objections, I want to hear them now. It will be
too late in November, based on what I have been hearing from various
companies.
Please give your comments to me and/or post them publicly here.
Best Regards,
Paul E. Jones
Editor, H.323 and the H.323 Implementers Guide
[View Less]
Folks,
This may be old news to some, but I know that many people have not heard
that Upper Side will be hosting a conference called "Implementing H.323" in
Paris October 10-13, 2000.
If you would like to attend as a speaker, they are now accepting proposals
(a list of suggested topics are in their web page). The deadline for
proposals is June 15, 2000.
Here's the official web site:
http://www.upperside.fr/bah323.htm
Best Regards,
Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~…
[View More]~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Guys, I was travelling, so I couldn't respond to this thread earlier.
I think I like this idea of the earlyH245Control containing the first
H.245 message (i.e., a TCS), in the SETUP message, instead of the
h245Control.
You have my blessings. ;^)
