I'm just now plowing through old mail. Sorry to have not caught this thread sooner.
TPKT is also defined in T.123 which is called out in H.225.0/2.2
Greg Goodknight
Cisco Systems
-----Original Message-----
From: Derks, Frank <F.Derks(a)PBC.BE.PHILIPS.COM>
To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com>
Date: Thursday, February 04, 1999 5:17 AM
Subject: Re: TPKT in H.225.0
>Hi Tom,
>
>I couldn't find it either and I suspect that it couldn't be in …
[View More]because the
>ITU is very reluctant to reference any non-ITU material. Furthermore,
>RFC1006 encompasses a lot more than just the bit(s) that are used for
>H.225.0, so even referring to this RFC does not clarify it all. I think some
>work should be spent on this.
>
>Frank
>
>-----Original Message-----
>From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
>Sent: 02 February 1999 22:12
>To: ITU-SG16(a)MAILBAG.INTEL.COM
>Subject: Re: TPKT in H.225.0
>
>
>I'd swear the reference to RFC1006 used to be in H.225.0 Appendix D, but I
>can't find it there now.
>
>> -----Original Message-----
>> From: Derks, Frank [SMTP:F.Derks@PBC.BE.PHILIPS.COM]
>> Sent: Tuesday, February 02, 1999 4:05 AM
>> To: ITU-SG16(a)MAILBAG.INTEL.COM
>> Subject: Re: TPKT in H.225.0
>>
>> Hi Paul,
>>
>> I received two responses to my question, one from you and one from Tom
>> Taylor. The fact that there are at least two people that know about it
>> (and
>> several dozens more that have actually implemented the protocol stacks),
>> makes it hard to believe that this is an "oversight" in the
>> recommendation.
>> In fact, not knowing about this makes it impossible to implement an
>> interoperable protocol stack! Shouldn't action be taken to get this into
>> the
>> recommendation ASAP (e.g. through the Implementor's Guide)?
>>
>> Regards,
>>
>> Frank
>>
>> -----Original Message-----
>> From: Paul Long [mailto:Plong@SMITHMICRO.COM]
>> Sent: 01 February 1999 18:50
>> To: ITU-SG16(a)MAILBAG.INTEL.COM
>> Subject: Re: TPKT in H.225.0
>>
>>
>> TPKT is defined in RFC 1006. Not identifying TPKT was an oversight that
>> has
>> never been fixed in the Recommendation.
>>
>> Paul Long
>> Smith Micro Software, Inc.
>
[View Less]
PLEASE READ IF YOU CARE ABOUT EITHER GATEKEEPERS OR CONFERENCES!!!
Linh and I appear to agree that we need the views of more interested
parties!
Linh,
> >2. I disagree with Linh's assertion that "an MC never sends
> ARQ". If I am
> >administering an MCU which can initiate conferences by
> calling up a list of
> >participants at a given time, I will certainly require that
> MCU to apply to
> >its gatekeeper for permission to make these calls.
> >In the …
[View More]particular case under discussion, E2/its MC certainly
> has to send
> >ARQ. It is going to make a call, which will result in data
> flowing its
> >gatekeeper's zone, and which may end up costing money.
> >E1's "call" does not result in data flowing in its
> gatekeeper's zone if the
> >centralised model is used for data (in which I include both audio and
> >video) and it happens to be in a different zone from E2/MC
> and E3 - so
> >maybe E1 doesn't have to send ARQ? However it will result
> in data flowing
> >in its gatekeeper's zone if the decentralised model is used
> for data, and
> >the MC may wish to (cross?) charge E1 for inviting E3, so
> maybe E1 does
> >need to send ARQ.
>
> I must admit that I only consider the "address resolution"
> part of the ARQ
> procedure. I did not consider its BW management and reservation part,
> because that part is in my view broken. I'd never use the ARQ for that
> purpose. An endpoint only knows about the needed BW when a
> logical channel
> is opened, and not at call setup time! And that applies
> already in case of a
> point-to-point call. Since it does not work for
> point-to-point cases, it
> will also not work for the conference cases.
I agree that the bandwidth stuff is broken. However, if a gatekeeper
chooses to do things with it, you're going to end up with interoperability
problems from saying you don't use it. The point is slightly wider, though,
that someone needs to have knowledge of whether a given user is authorised
to initiate the inviting of people to conferences. I'd rather have all my
configuration for that sort of thing in my gatekeeper than in the
(potentially multiple) MCs in its zone.
> To make the scenario a bit more complicated, assume there is already a
> conference between E1, E2/MC and E4. Now E1 wants to invite
> E3. E4 will only
> knows about the joining of E3 when it is requested by the MC to either
> re-open the logical channels (centralized case with codec
> change) or open
> new ones (distributed case).
Really? I thought that was what the conferenceIndication
"terminalJoinedConference" was for, and that the MC was supposed to send it
to all participants whenever anyone new joined the conference.
> Should E4 sends ARQ when it is
> requested to
> open the logical channels? I don't think that is actually specified.
> Furthermore, how should E4 ask its GK for the permission to
> have a call with
> E3? I don't know whether the BRQ procedure can help. Maybe
> somebody more
> knowledgeable could help to clarify the situation.
In my view, the calls are logically between each endpoint and the MC, and
this is how the control paths run. Yes the model is slightly broken for
data paths, particularly by by decentralised conferences.
> >3. The destCallSignalAddress given in ACF is the only
> address to which an
> >endpoint should send a setup message. I find it hard to
> agree with Linh's
> >assertion that on the basis of an ACF mentioning E3, E1
> should send a setup
> >message to E2/MC. The suggestion in the case of the
> gatekeeper routed
> >model is simply impossible. E1 doesn't know where E2/MC is,
> so I fail to
> >see how E1 can send its setup message to E2/MC in this case.
> Note that all
> >E1's call signalling goes to its gatekeeper - and as a
> routing gatekeeper I
> >would feel justified in ensuring that E1 doesn't find out
> where E2/MC is:
> >for instance I wouldn't feel obliged to leave
> mcLocationIndication messages
> >alone as I relay them. The upside of this is that at least then E1's
> >gatekeeper knows where the activeMC is, and should be able
> to work out
> >what's going on when the setup message comes in.
>
> I was assuming that the call between E1 and E2 was direct and
> the MC was
> already created at E2. Otherwise, if the call was GK-routed
> then according
> to H.323 Section 8.4.3.4 the GK would know where the MC is,
> and certainly E1
> would have to sends its SETUP to the GK/MC as specified in 8.4.3.5.
Fair-ish cop... For some of it (ie the GK routed stuff). It kind of
depends on your understanding of a GK having "access to" an MC. Does any
entity with MC functionality that's registered with a GK count as an MC to
which it "has access"? Or just ones that happen to be involved in this
call? This is an area in which the standard is terribly woolly.
Can I just clarify your position, please? If I understand you correctly
you're suggesting that if I as an endpoint want to send a setup "towards"
the active MC in my call or conference in order to invite a new party to the
conference, I don't need to send ARQ to my gatekeeper. In any other
circumstances I need to send ARQ and receive ACF before I may send Setup.
In the gatekeeper routed model, any setup message with conference goal
"invite" will be sent by the gatekeeper to the active MC for the conference
whose conferenceID matches that in the setup message UNLESS it comes from
that entity, in which case it will go to the desired destination.
Arising questions:
What if there is NO active MC (ie the call is a typical one)? How do I
promote a call to a conference in the direct-routed model where I've ended
up as "slave" in the master-slave determination procedure (where other
entities in the call may or may not contain MCs)?
Who is vetting the inviting endpoint's right to invite (certainly the GK's
job in my opinion, whatever routing model you're using).
Regards,
Chris
[View Less]
Chris,
a few comments to your statements:
>2. I disagree with Linh's assertion that "an MC never sends ARQ". If I am
>administering an MCU which can initiate conferences by calling up a list of
>participants at a given time, I will certainly require that MCU to apply to
>its gatekeeper for permission to make these calls.
>In the particular case under discussion, E2/its MC certainly has to send
>ARQ. It is going to make a call, which will result in data flowing its
>…
[View More]gatekeeper's zone, and which may end up costing money.
>E1's "call" does not result in data flowing in its gatekeeper's zone if the
>centralised model is used for data (in which I include both audio and
>video) and it happens to be in a different zone from E2/MC and E3 - so
>maybe E1 doesn't have to send ARQ? However it will result in data flowing
>in its gatekeeper's zone if the decentralised model is used for data, and
>the MC may wish to (cross?) charge E1 for inviting E3, so maybe E1 does
>need to send ARQ.
I must admit that I only consider the "address resolution" part of the ARQ
procedure. I did not consider its BW management and reservation part,
because that part is in my view broken. I'd never use the ARQ for that
purpose. An endpoint only knows about the needed BW when a logical channel
is opened, and not at call setup time! And that applies already in case of a
point-to-point call. Since it does not work for point-to-point cases, it
will also not work for the conference cases.
To make the scenario a bit more complicated, assume there is already a
conference between E1, E2/MC and E4. Now E1 wants to invite E3. E4 will only
knows about the joining of E3 when it is requested by the MC to either
re-open the logical channels (centralized case with codec change) or open
new ones (distributed case). Should E4 sends ARQ when it is requested to
open the logical channels? I don't think that is actually specified.
Furthermore, how should E4 ask its GK for the permission to have a call with
E3? I don't know whether the BRQ procedure can help. Maybe somebody more
knowledgeable could help to clarify the situation.
>3. The destCallSignalAddress given in ACF is the only address to which an
>endpoint should send a setup message. I find it hard to agree with Linh's
>assertion that on the basis of an ACF mentioning E3, E1 should send a setup
>message to E2/MC. The suggestion in the case of the gatekeeper routed
>model is simply impossible. E1 doesn't know where E2/MC is, so I fail to
>see how E1 can send its setup message to E2/MC in this case. Note that all
>E1's call signalling goes to its gatekeeper - and as a routing gatekeeper I
>would feel justified in ensuring that E1 doesn't find out where E2/MC is:
>for instance I wouldn't feel obliged to leave mcLocationIndication messages
>alone as I relay them. The upside of this is that at least then E1's
>gatekeeper knows where the activeMC is, and should be able to work out
>what's going on when the setup message comes in.
I was assuming that the call between E1 and E2 was direct and the MC was
already created at E2. Otherwise, if the call was GK-routed then according
to H.323 Section 8.4.3.4 the GK would know where the MC is, and certainly E1
would have to sends its SETUP to the GK/MC as specified in 8.4.3.5.
Regards,
Linh
---------
TRUONG Hong Linh email: hlt(a)zurich.ibm.com
IBM Zurich Research Laboratory tel : +41 1 724 8434
CH-8803 Rueschlikon / Switzerland fax : +41 1 724 8955
[View Less]
Colleagues,
The H.GCP audio call was held Thursday March 4th , 18 ports called in
including a group from the TIPHON meeting. Companies represented were ATT,
Lucent, ACGS, RadVision, Cisco, Nortel, Delta Information Systems, NetSpeak,
Bellcore and others. . .
The meeting opened by reviewing a proposed working model and fleshing out
the work items that need to be addressed. A number of individuals
committed to fleshing some of the work items prior to the next call, I would
like to thank these …
[View More]individuals in advance. There was some news from TIPHON
regarding changes to the reference model and some adjustments to the
requirements they have contributed to H.GCP. These changes will be
reflected once TDs from the Philadelphia meeting are released. The last
hour or so was focussed on reviewing the H.GCP requirements I sent around
prior to the meeting.
The next call is tentatively planned for Thursday March 18 at 10AM EST.
The working model
Individuals will be working up submissions to be reviewed by the entire
group at the next audio call. The objective is that the principals involved
will collaborate off line initially, post the results to the SG16 reflector
for comments and a final version will be posted for discussion in an audio
call. The result of that final review will be added into the H.GCP by the
editor. Every effort will be made to resolve issues in this forum but if
issues remain they will be logged and discussed in Santiago
Work items
T
he following work items were identified and individuals who expressed an
interest in working on them are noted.
Control Model Tom Taylor
Connection Model Rex Coldren, Hong Liu, Nortel rep
Command related issues Chip Sharp
Resource Management Paul Sijben
Other work items
Messages (i.e.-command packaging)
Message Encoding
Scripting/Packages
Interface C protocol (Q.931/Q.764)
Interface B protocol (Q.931 )
-----Original Message-----
From: Bryan Hill [SMTP:bhill@VIDEOSERVER.COM]
Sent: Monday, March 01, 1999 2:37 PM
To: ITU-SG16(a)mailbag.cps.intel.com
Subject: H.GCP Audio Call
Colleagues,
I would like to invite you to participate in audio call on Thursday
March
4th from 11AM until 1PM EST to discuss H.GCP. The call details are
as
follows:
Calls from outside the US: 312-470-7273
Calls from within the US: 888-847-7598
Passcode: BryanHill
Confirmation number: 5193957
Please respond to me directly to reserve a port for this call (where
ever
possible please try to minimize port requirements by sharing a port
with a
colleague).
The main purpose of this initial call will be to review requirements
and
terminology for H.GCP which were discussed in Monterey. I have been
editing
these sections and will make them available on the ptel SG16 ftp
site no
later than tomorrow 3/2. The second purpose of the call is to
identify
other areas that need to be discussed in subsequent audio calls. An
initial
pass of topics is listed below. I would like to solicit volunteers
to
submit written contribution in each of the areas identified and use
these
submissions as a basis for discussing topics in future audio calls.
In this
manner I hope to scope our discussion to specific technical topics
and
combine the benefits from MDCP and MGCP approaches into H.GCP.
1) Control model
a) Controller to gateway associations
b) Controller to internal gateway entity associations
c) Failover
d) Security
2) Connection model
a) Controllable entities
b) Controllable entity properties
3) Commands
a) Types
b) Parameters
c) Acknowledgement styles/sequencing
4) Messages (i.e.-command packaging)
5) Message Encoding
6) Resource management
7) Scripting/Packages
8) Interface C protocol (Q.931/Q.764)
9) Interface B protocol (Q.931 )
Best Regards,
Bryan
_________________________________________________________
Bryan Hill
VideoServer Inc.
(781) 505-2159
<mailto:bhill@videoserver.com>
[View Less]
Linh, Soo, All,
I think there's a genuine problem here, and I think we need to look for the
"right" solution.
1. I agree with Linh that the fact that the MC happens to be located with
one of the endpoints in this scenario is (or should be) irrelevant.
2. I disagree with Linh's assertion that "an MC never sends ARQ". If I am
administering an MCU which can initiate conferences by calling up a list of
participants at a given time, I will certainly require that MCU to apply to
its gatekeeper …
[View More]for permission to make these calls.
In the particular case under discussion, E2/its MC certainly has to send
ARQ. It is going to make a call, which will result in data flowing its
gatekeeper's zone, and which may end up costing money.
E1's "call" does not result in data flowing in its gatekeeper's zone if the
centralised model is used for data (in which I include both audio and
video) and it happens to be in a different zone from E2/MC and E3 - so
maybe E1 doesn't have to send ARQ? However it will result in data flowing
in its gatekeeper's zone if the decentralised model is used for data, and
the MC may wish to (cross?) charge E1 for inviting E3, so maybe E1 does
need to send ARQ.
3. The destCallSignalAddress given in ACF is the only address to which an
endpoint should send a setup message. I find it hard to agree with Linh's
assertion that on the basis of an ACF mentioning E3, E1 should send a setup
message to E2/MC. The suggestion in the case of the gatekeeper routed
model is simply impossible. E1 doesn't know where E2/MC is, so I fail to
see how E1 can send its setup message to E2/MC in this case. Note that all
E1's call signalling goes to its gatekeeper - and as a routing gatekeeper I
would feel justified in ensuring that E1 doesn't find out where E2/MC is:
for instance I wouldn't feel obliged to leave mcLocationIndication messages
alone as I relay them. The upside of this is that at least then E1's
gatekeeper knows where the activeMC is, and should be able to work out
what's going on when the setup message comes in.
Outline Solution?:
I really don't think we have the tools at our disposal as things stand.
I'm (reluctantly) coming to the conclusion that we need either a1 & b or a2
& b (I think I prefer the latter) as follows:
a1) An extra RAS message to tell gatekeepers where the active MC lives in
conferences. I'm not certain how this works, though, because there needs
to be an "I am NOT the active MC" option (sent on receipt of
mcLocationIndication) which tells the gatekeeper where to find the active
MC. This may or may not be a problem.
a2) An "activeMCLocation" field in ARQ (and setup?).
b) A conferenceGoal element in ARQ (as in setup).
Then if a gatekeeper receives an "invite" ARQ from something that is not
the active MC in its conference it can send back in its confirm the
transport address to which to send setup, and destinationInfo for the final
destination. In the routed model I believe there is still sufficient
information in the setup message for the gatekeeper to do the right thing.
Handling "invite" from the activeMC is then fairly obvious.
I'd love to see how we can do this without new ASN.1, though...
Regards,
Chris
--
Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND
Phone: +44 1753 661 359 email: cpurvis(a)madge.com
> -----Original Message-----
> From: Lee Hyoung soo [mailto:soo@DESKVIEW.NADA.CO.KR]
> Sent: 05 March 1999 3:35
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: Invitation via Gatekeeper
>
>
> Dear Hong-Linh and Chris,
>
> Thank you for your mail.
>
> my questions are embeded below. ^.^
>
>
>
> > It's worth mentioning which standard here. For the benefit
> of anyone
> > needing to catch up, we're talking about H.323.
>
> Yes, I mentioned H.323 v2(October 1997).
>
> > > when an
> > > endpoint(E1) which do not have active MC wants to invite other
> > > endpoint(E3), does E1 send an ARQ to its Gatekeeper for
> the invite or
> > > does E2 send the ARQ to its gatekeeper, or do both of
> them send ARQ's?
> >
> > I would suggest that both ought to send ARQs. Both are
> logically setting up
> > calls, so both need to ask permission. However, E1's ARQ
> need ask for no
> > bandwidth as none will be used on the call between it and E2.
> >
> > <Linh> Here I think we have to distinguish carefully
> between an endpoint and
> > an
> > MC (what the current H.323 achieves very badly!). In the
> above scenario, the
> > MC is hosted in the same device as E2 and E1 is sending the
> SETUP message
> > to the MC and not to E2 (H.323 Figure 28-30 are misleading,
> because they
> > only
> > show E2 and not the MC!). Therefore, IMO only E1 has to
> send an ARQ, not E2,
> > and an MC never sends ARQ!
>
> I agree with Chris's opnion. I think, every endpoint which is
> registered to
> Gatekeeper must send ARQ to its Gatekeeper.
>
> But I still have some problems. In the above scenario, if E1
> sends ARQ to its
> Gatekeeper, E1's behavior after receiving ACF is not clear.
> There are two
> different cases. One is that E1 receives ACF with E3's
> CallTransportAddress. In
> this case, E1's behavior is not clear. E1 should keep its
> status(invite or not),
> and after receiving ACF, E1 send Setup message to E2 regardless of
> CallTransportAddress in ACF.
> And the other is that E1 receives ACF with E2's
> CallTransportAddres. In this
> case, E1' behavior is clear, but Gatekeeper should know E2 is
> active MC, and
> send ACF with E2's CallTransportAddress regardless of
> destination address in
> ARQ.
>
>
> > > And, when Gatekeeper doesn't know which endpoint has
> active MC in any
> > > conference, what should Gatekeeper do if it receives ARQ(for
> > > invitation)
> > > from an endpoint which do not have active MC? I mean, if
> Gatekeeper
> > > receives ARQ from E1, what should Gatekeeper do? Does
> Gatekeeper send
> > > ACR with E2's CallTransportAddress instead of E3's
> > > CallTransportAddress?
> >
> > E1's gatekeeper can conceivably spot that invite is
> probably what's wanted,
> > by matching up conferenceIDs, although there's nothing in
> the ARQ message to
> > say directly that invite is the desired outcome. The
> gatekeeper certainly
> > MUST return the address to which E1 should send its Setup
> message, so in the
> > direct-routed model that will be E2. However, a
> non-routing gatekeeper will
> > have no way of knowing where the active MC is. I believe
> this is a genuine
> > "hole" in the standard.
>
> Yes, you are right. E1's Gatekeeper can know E1's intention,
> but generally E1's
> gatekeeper doesn't know which endpoint is active MC in that
> conference.
>
>
> > <Linh>The point here is in general the GK does not (and
> needs not) know
> > where
> > the MC is actually located! It therefore, in response to
> the ARQ sent by E1,
> > returns
> > the transport address of either E3 (direct model) or itself
> (GK-routed
> > model).
> > In both cases, E1 has to send its SETUP message to the MC
> (which is in
> > our specific scenario colocated with E2).Then the MC will
> relay that message
> > to
> > either E3 or the GK, depending on which transport address
> is included in the
> > SETUP message sent by E1.
>
> According to Linh's opnion, As I explained above, E1 should keep its
> status(invite or not) and E1 should follow different procedure between
> invitation and other calls, after receiving ACF from its Gatekeeper.
>
> Best wishes,
> soo.
>
> --
> Nada Research Co., Ltd. Korea
> TEL : 82-2-525-3941
>
> Lee Hyoung soo.
>
mailto:soo@nada.co.kr
[View Less]
J.Aridaman wrote:
>>Please do not include me in further e-mails.
1) If you wish to unsubscribe from the SG16 mail list,
this is not how to do it.
2) If you wish the VoIP QoS discussion to discontinue
using the SG16 list, this has already been established
3) Joon has already setup a mail list for the discussion
>Hi! To subscribe H.323/VoIP QoS Activity Group, please send mail
>to majordomo(a)majordomo.vtel.com with a command line
>subscribe h323_voip_qos your email …
[View More]address
>in the body of the message
[View Less]
This was my understanding as well.
Does anyone disagree with Gary?
Regards,
Radhika
-------------------------------------------
Radhika R. Roy
AT&T Labs
Room C1-2B03
200 Laurel Avenue S.
Middletwon, NJ 07748
USA
+ 1 732 420 1580 Tel
rrroy(a)att.com
> -----Original Message-----
> From: Gary A. Thom [SMTP:gthom@DELTA-INFO.COM]
> Sent: Friday, March 05, 1999 11:18 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: Invitation via Gatekeeper
>
> I have this …
[View More]minor semantic clarification:
>
> > 2. I disagree with Linh's assertion that "an MC never sends ARQ". If I
> am
> > administering an MCU which can initiate conferences by calling up a list
> of
> > participants at a given time, I will certainly require that MCU to apply
> to
> > its gatekeeper for permission to make these calls.
> > In the particular case under discussion, E2/its MC certainly has to send
> > ARQ. It is going to make a call, which will result in data flowing its
> > gatekeeper's zone, and which may end up costing money.
>
> The original idea was that only endpoints send ARQ. An MC is not an
> endpoint, however, it is a
> functional element which can be contained in an endpoint (such is the case
> of an MCU or a terminal
> which contains an MC). So even though the endpoint contains an MC, it is
> the endpoint which is
> sending the ARQ not the MC functional element.
>
> If an MC exists in the Gatekeeper, I do not beleive that that MC will ever
> send ARQ for any of the
> connections in the conference. Only the endpoints in that conference will
> send ARQ to their
> Gatekeepers.
>
>
> Gary
> ------------------------------------------------------
> Name : Gary A. Thom
> Company: Delta Information Systems, Inc.
> Address: 300 Welsh Rd., Bldg 3
> Horsham, PA 19044 USA
> Phone : +1-215-657-5270 Fax : +1-215-657-5273
> E-mail : gthom(a)delta-info.com
> ------------------------------------------------------
[View Less]
Hi Pete,
I like to extend my sincere thanks for your great contributions in SG16
especially related to H.323. I am sure that all of us will miss you because
you may not be involved with H.323.
Hope for the best in your new venture!
Sincerely,
Radhika R. Roy
AT&T
+1 732 420 1580
rrroy(a)att.com
> -----Original Message-----
> From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK]
> Sent: Wednesday, March 03, 1999 3:32 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: …
[View More]BT change of representative
>
> Dear All,
>
> As you may know by know, I am moving on to own little venture. In case
> you were wondering, it doesn't involve H.323!!!
>
> This does mean that I will not be representing BT any more in SG16.
> This role will probably be taken over by Morgan Potter at
> morgan.potter(a)bt.com, so if you have any questions from BT he is the one
> to ask. Also Mike should be able to help.
>
> I would like to take this opportunity to say that, despite the hard
> work, I have enjoyed my time working with you and I wish you all the
> best. And, who knows, perhaps we'll meet again in the future - If you
> get back to Ipswich sometime on your travels, then look me up (assuming
> the Rapporteurs give you time to get out the meetings!).
>
> Regards,
>
> Pete
> =================================
> Pete Cordell
> BT Labs
> E-Mail: pete.cordell(a)bt-sys.bt.co.uk
> Tel: +44 1473 646436
> Fax: +44 1473 645499
> =================================
[View Less]
Chris and Soo,
my comments are inserted below (and marked with <Linh>). Hope,
they help clarify the scenario you are looking for.
Linh
---
TRUONG Hong Linh hlt(a)zurich.ibm.com
IBM Zurich Research Laboratory tel : +41 1 724 8434
CH-8803 Rueschlikon / Switzerland fax : +41 1 724 8955
_______________________________________________
Soo,
Yes, it is splendidly unclear, isn't it?
> I tried to get answer from implementors group and some other
> person, but I couldn't get …
[View More]any satisfiable answer.
>
> My question is here.
>
> In section 8.4.3.2(Figure 28/H.323-Non-MC invite signalling),
It's worth mentioning which standard here. For the benefit of anyone
needing to catch up, we're talking about H.323.
> when an
> endpoint(E1) which do not have active MC wants to invite other
> endpoint(E3), does E1 send an ARQ to its Gatekeeper for the invite or
> does E2 send the ARQ to its gatekeeper, or do both of them send ARQ's?
I would suggest that both ought to send ARQs. Both are logically setting up
calls, so both need to ask permission. However, E1's ARQ need ask for no
bandwidth as none will be used on the call between it and E2.
<Linh> Here I think we have to distinguish carefully between an endpoint and
an
MC (what the current H.323 achieves very badly!). In the above scenario, the
MC is hosted in the same device as E2 and E1 is sending the SETUP message
to the MC and not to E2 (H.323 Figure 28-30 are misleading, because they
only
show E2 and not the MC!). Therefore, IMO only E1 has to send an ARQ, not E2,
and an MC never sends ARQ!
> And, when Gatekeeper doesn't know which endpoint has active MC in any
> conference, what should Gatekeeper do if it receives ARQ(for
> invitation)
> from an endpoint which do not have active MC? I mean, if Gatekeeper
> receives ARQ from E1, what should Gatekeeper do? Does Gatekeeper send
> ACR with E2's CallTransportAddress instead of E3's
> CallTransportAddress?
E1's gatekeeper can conceivably spot that invite is probably what's wanted,
by matching up conferenceIDs, although there's nothing in the ARQ message to
say directly that invite is the desired outcome. The gatekeeper certainly
MUST return the address to which E1 should send its Setup message, so in the
direct-routed model that will be E2. However, a non-routing gatekeeper will
have no way of knowing where the active MC is. I believe this is a genuine
"hole" in the standard.
Linh,
I know you've implemented some of this stuff: how do you get around this?
<Linh>The point here is in general the GK does not (and needs not) know
where
the MC is actually located! It therefore, in response to the ARQ sent by E1,
returns
the transport address of either E3 (direct model) or itself (GK-routed
model).
In both cases, E1 has to send its SETUP message to the MC (which is in
our specific scenario colocated with E2).Then the MC will relay that message
to
either E3 or the GK, depending on which transport address is included in the
SETUP message sent by E1.
Regards,
Chris
--
Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND
Phone: +44 1753 661 359 email: cpurvis(a)madge.com
[View Less]
> -----Original Message-----
> From: Ying, Wen-Ping [SMTP:wen-ping.ying@ATTWS.COM]
> Sent: Thursday, March 04, 1999 3:35 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323/VoIP QoS
>
[[TomT]] snip...
> 7. transport efficiency - concerns about header overhead that triggers
> the
> proposed solution hop2hop header compression (rfc-2508) and the recent
> work
> in MEGACO regarding g.729/udp/rtp/ip/atm & g.729/aal2/atm interworking.
>
…
[View More] [[TomT]] Sorry, [[TomT]] we've discussed a lot of things on the
MEGACO list, but not this.
[View Less]
