- sg16-avd - lists.packetizer.com

Re: H.323 mobility draft
by Edgar Martinez [1] 07 Sep '99

07 Sep '99

Roberto, Tell me more... Roberto Winkler wrote: > Edgar, all > > thanks for the reply, but I have some more.... > > Again, with reference to the WAU, whose capabilities and role I still don't > quite understand, I don't see how can it 'intercept' messages belonging to > the RAS channel (i.e. addressed to or coming from the Gatekeeper), without > a true redefinition of the whole system. I disagreed with your last statement " without a true redefinition of the whole … [View More]system". If we designed a system that needs to be redefined everytime we provide a new service then we did something wrong. It may be true for some other systems you are looking at, like G _ _ _ or 3_ _ _. The Radio sub-system WAU is just a (GW) which provides the Radio Control Function (RCF) and bearer connection. It maintains the state of the radio links connections, for a given call, between the a user agent/terminal agent and the network as perceived by the RCF. It establishes, maintains, modifies and releases a radio and fixed line bearer connection between a mobile and the network. The MT to WAU relationship we hope to re-use the Radio technology defined by UMTS/3GPP. The MT to H.323 IP relationship we plan to re-use the H.323 elements and the TIPHON system. > > But, most important, I think that Mr. Martinez's contribution cannot be > appreciated in its entirety without a clear and precise description of the > functionalities and capabilities of the blocks in the proposed reference > architecture, which I feel is missing from the picture as it is now. As a > matter of example, with reference to the WAU, the following items should be > clarified: > - capabilities and functions > - protocol stack > - differences to other Gateways > - differences to Gatekeepers All of the above is already available in one form or another, it has been presented in other contributions I had provided to ITU and WG7. The contributions can modified specificity for the new H.323 Annex H 'user and services mobility" once the framework is agreed on. Plus Annex H it is open for contributions and you or anyone are welcome to provide some. > > > To my humble opinion, this should be the first task to be accomplished, > before aiming at message flows. We need both and will have both, but this is the same old problem that network architects face and everyone has their own opinion. I rather first know from a high level, what we are trying to provide before jumping in to details. Have you ever been asked to "show me a call flow or block diagarm" what you are trying to do? Call flows without the intended protocols message to be used, in a specific system makes little sense to me. Regards, Ed > > > Thanks very much and best regards everybody > > Roberto Winkler > > Roberto Winkler > Senior Researcher > Fondazione Ugo Bordoni > Via B. Castiglione, 59 > 00142 Rome Italy > > tel +39 0654803411 > fax. +39 0654804404 > e-mail wnk(a)fub.it > > ------------------------------------------------------------------- > Mail archive for TIPHON_WG7 can be browsed at the following url : > > http://www.etsi.org/tiphon/mailing.htm > ------------------------------------------------------------------- -- Forwarded -- Subject: Re: H.323 mobility draft Date: Mon, 06 Sep 1999 10:54:19 -0400 From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> Organization: NSS-NAT To: Roberto Winkler <wnk(a)FUB.IT> CC: TIPHON_WG7(a)LIST.ETSI.FR References: 1 Dear Roberto, Thank you for your comments. Responses follow: Roberto Winkler wrote: > hello > I have the following basic questions about the document in subject: > > - what does IMIS mean ? ASN.1 data type IMIS in section 8.5 and the call flows is a typo it will be correct. IMSI ::= TBCD-STRING (SIZE (3..8)) imsi IMIS OPTIONAL (typo in document) should be imsi IMSI OPTIONAL (correction) > > - I have the impression that many message flows in section 8 break the > usual RAS channel definition, because messages that in the 'original' H.323 > are exchanged between endpoint and gatekeeper are now intercepted by WAU, > whose role (and mapping to UMTS architecture) is really unclear to me. > As > an example, there is the GRQ/GCF exchange in 8.2.1.2 > and ARQ/ACF exchanged between WAU and GK in 8.3.1.1. The WAU is not that much different that a MCU or Gateway which may register a single Transport Address or multiple Transport Addresses. To the GateKeeper the WAU will look like (GW) end-point. Of course of we want to support wireless mobility some tweets will have to be done in the H.323 procedures to handle H.323 (MT) wireless or Fixed Terminal mobility. But, it should not beak the under lining core set procedures for basic H.323. > Text from H.323v3 section 7.2.2 http://standard.pictel.com/ftp/avc-site/Incoming/ 7.2.2 Endpoint registration: Registration is the process by which an endpoint joins a Zone, and informs the Gatekeeper of its Transport Address and alias addresses. As part of their configuration process, all endpoints shall register with the Gatekeeper identified through the discovery process. Registration shall occur before any calls are attempted and may occur periodically as necessary (for example, at endpoint power-up). A Gateway or MCU may register a single Transport Address or multiple Transport Addresses. The use of multiple Transport Addresses may simplify the routing of calls to specific ports. An endpoint shall send a Registration Request (RRQ) to a Gatekeeper. This is sent to the Gatekeeper's RAS Channel Transport Address. The endpoint has the Network Address of the Gatekeeper from the Gatekeeper discovery process and uses the well-known RAS Channel TSAP Identifier. The Gatekeeper shall respond with either a Registration Confirmation (RCF) or a Registration Reject (RRJ). See Figure 8. An endpoint shall only register with a single Gatekeeper. The RRQ may be repeated periodically (i.e. at terminal power-up), so the Gatekeeper shall be able to handle multiple requests from the same endpoint. If a Gatekeeper receives an RRQ having the same alias address and the same Transport Address as an active registration previous RRQ, it shall respond with RCF. Snip... Regards, Ed > > > Clarifications are appreciated > > best regards > > Roberto Winkler > > Roberto Winkler > Senior Researcher > Fondazione Ugo Bordoni > Via B. Castiglione, 59 > 00142 Rome Italy > > tel +39 0654803411 > fax. +39 0654804404 > e-mail wnk(a)fub.it > > ------------------------------------------------------------------- > Mail archive for TIPHON_WG7 can be browsed at the following url : > > http://www.etsi.org/tiphon/mailing.htm > ------------------------------------------------------------------- -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ [View Less]

1 0

Queries related to H.341 !!
by Aparna Saha 07 Sep '99

07 Sep '99

Hello , I have a few queries related to H.341- Draft 7 ( dated May 1999 ) 1. What is the concept of an interface in H.341 ? For instance, the callSignalConfigEntry in the callSignalConfigTable is indexed by the ifIndex i.e. the interface index. What does this imply ? 2. Why is the field callsignalConfigAvailableConnections in callSignalConfigTable ? ( Page 29 ) The information about available connections should not be a part of the configuration info. 3. The explanation for the … [View More]

2 1

Video Conference Sept 12-15, 1999
by videoconf＠nfmail.com 07 Sep '99

07 Sep '99

ANNUAL CONFERENCE September 12 - 15, 1999 Sacramento Convention Center Sacramento, California http://www.pug.com/apug/conf.htm

1 0

Re: RAS to INAP
by Edgar Martinez [1] 07 Sep '99

07 Sep '99

Dear Chatras, Thank for your comments, but the Terminal ARQ/ACF can easily be mapped to the ssf-BCSM (reference q.1124). If the H.323 terminal had a subset of the ssf-BCSM. Below is just an example, these issues would best be handle by SG11/5 or ETSI SPAN3. But, this was the idea I had, wend I proposed the mapping of RAS messages to the INAP messages. The H.323 terminal BCSM for example, would start a call from: PIC: O_Null Start DP: action (Terminal ARQ is send to GK) Terminal go to DP:… [View More] Orgination_Attempt PIC: Authorize_Origination_Attempt. Wait ..for next DP: action (GK ACF is returned to the terminal ) Terminal go to DP: Origination_Attempt_Authorized, PIC: Collect _Infromation. then to (opitonal DP) DP: Collected _Information. PIC: Analyze_information then to (opitonal DP) DP: Analyzed _Information. PIC: Authorize_Call_Setup then to action (H.225 Setup to EP or GK) PIC: Send_Call Wait ..for next DP: action (H.225 Call Proc/Alert from EP or GK to terminal) Terminal go to DP: O_Term_Seized PIC: O_Alerting Wait ..for next DP: action (H.225 Connect from EP or GK) DP: O_Answer PIC: O_Active Terminal is in call Wait ..for next DP: action (Disconnect, etc..) Regards, Ed CHATRAS Bruno CNET/DAC/ISS wrote: > Dear All, > > The mapping proposed in this document (i.e. ARQ/ACF mapped to IDP/Connect) > suggests that the RAS procedures are included in the BCSM. I do not think > that this is valid, because the admission procedure occurs before call > set-up initiation (i.e. it is too early for creating a BCSM instance). > Indeed, in case the "direct" call model is used, no BCSM instance will be > created after completion of the admission procedure. Moreover, it is almost > impossible to find an obvious mapping between many of the ARQ/ACF parameters > and the IDP/Connect parameters. > > Before trying to map the RAS messages on to INAP operations, we should first > study how the RAS procedures can be modelled in terms of state machines. At > a first glance, it seems that the RAS procedures might be considered as > being some sort of non call related feature very much like a CCBS procedure. > Therefore, it would be wise to study their mapping on to the BCUSM/CUSF > model. If this model appears to be suitable, the ARQ/ACF message will > naturally be mapped to the InitialAssociationDP and ContinueAssociation > operations. However the mapping of parameters will still need to be > considered. > > Alternatively, a deeper analysis may reveal that a completely new kind of > state model (and associated set of operations) would better suit such kind > of procedures. > > Regards, > > > ---------- > > De : Edgar Martinez [1][SMTP:martinze@cig.mot.com] > > Répondre à : Edgar Martinez [1] > > Date : mardi 10 août 1999 16:26 > > A : TSG11Q5 > > Cc : TIPHON : Entirely; Entirely SG16 > > Objet : RAS to INAP > > > > <<Fichier : 13td049.doc>> > > Dear All, > > > > Attached is part of a document I presented in TIPHON 13 and > > the Santiago ITU-SG16 meeting to support > > INAP interworking in H.323. Which help to start the groups > > (TIPHON and SG16), to look at INAP-IPT interworking. > > The reason I sending this out I promise some reps. from > > TSG11 to send the Mapping of the RAS to INAP messages > > as a start. > > > > Regards, > > -- > > Edgar Martinez - Principal Staff Engineer > > Email mailto:martinze@cig.mot.com > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > > > > > -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ [View Less]

1 0

Re: Queries related to H.341 !!
by Irina Suconick 06 Sep '99

06 Sep '99

I added my comments below. Irina > -----Original Message----- > From: Pratima Shah [SMTP:shahp@agcs.com] > Sent: Tuesday, September 07, 1999 11:32 AM > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: Re: Queries related to H.341 !! > > Hi Aparna, > > See my answers below. > > Aparna Saha wrote: > > > Hello , > > > > I have a few queries related to H.341- Draft 7 ( dated May 1999 ) > > > > 1. What is the concept of … [View More]an interface in H.341 ? For instance, the > > callSignalConfigEntry in the callSignalConfigTable is indexed by > > the ifIndex i.e. the interface index. What does this imply ? > > > > Pratima - Here the ifIndex applys to the H.225 call signaling channel. > Each call > signaling channel will have a unique ifIndex. > [Irina Suconick] interface index is used as a logical number representing an interface to a particular H.323 entity. An example of a multiple entities in one system could be several gateways and a gatekeeper. The interfaces to these entities will be system specific and will be numbered from 1 to n. Therefore each row of a particular table contains the variables that represent a particular entity in a system. Therefore configuration table will contain a row for each entity in a system. If the system consists of only one entity there will be only one row in configuration table. > > 2. Why is the field callsignalConfigAvailableConnections in > > callSignalConfigTable ? ( Page 29 ) The information about available > > connections should not be a part of the configuration info. > > Pratima - Each call signalling channel may support the finite number of > payload > connections and out of these max. number how many are available at a given > time. > > > 3. The explanation for the field rasRegistrationRasAddressTableIndex in > > rasRegistrationRasAddressTableEntry is incorrect. What > > is the correct explanation ?? ( Page 47 ) [Irina Suconick] This is cut and paste error and should be fixed. Instead of the aliases it should be ras addresses. > > 4. Why is rasRegistrationTableEntry indexed by both the > callSignallingAddress > > and the srcRasAddress ? ( Page 43 ) > > Pratima - A Gateway supporting multiple endpoints may register all > endpoints with > the Gatekeeper. And a Gateway may have one signalling address for multiple > RAS > addresses. > > > > > > > Thanks and regards, > > Aparna. > > Theese are my understandings. Someone can correct me if I am wrong. > > Pratima Shah > > -- > =============================================================== > Pratima Shah AG Communication Systems > Phone: (602) 581-4710 -A subsidiary of Lucent Technologies- > Fax: (602) 581-4636 2500 West Utopia Road > Email: shahp(a)agcs.com Phoenix AZ 85027 > =============================================================== > "Expand The Power Of Your Network" > http://www.agcs.com > ========= [View Less]

2 1

Re: ASN.1 Syntax of H.245
by Hidenobu Harasaki 06 Sep '99

06 Sep '99

Dear Mike, > An error has been found in the ASN.1 syntax of H.245 version 5. I support the correction of the error on genericModeParameters. But another correction should be made. TTC (The Telecommunication Technology Committee), Japan has reported me that H.245 version 5 does not have section 6 but eighteen "defined in section 6" descriptions are found in Annex C. They should be corrected as "defined in Annex A". It might be a good chance to correct them before the publication of … [View More]

1 0

H.323 mobility aspects
by Edgar Martinez [1] 05 Sep '99

05 Sep '99

Dear Mr. OKUBO, Please (delete/remove) h323mob01.zip. and accept the updated contribution h323mob01a.zip for our next Study Group 16, Q.12-14/16 Rapporteur Meeting in New Jersey, 18-22 October 1999 I have put h323mob01a.zip , in http://standard.pictel.com/ftp/avc-site/Incoming/ The contribution deals with H.323 user and service mobility aspects. Thank you, -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West … [View More]

2 1

RTP session related
by Sunil Chandra 05 Sep '99

05 Sep '99

Hi All, I have few doubts on the RTP session. 1. In any RTP direction of transmission, the destination TA that identifies the session, is also associated with a single RTP payload type. Let us say there is a MCU connected to three terminals a, b and c. a & b are transmitting G.711 A-law and c is transmitting G.729, then a & b can transmit to the same destination TA and for MCU be participant in the same session, whereas c has to transmit to a different TA and will be a … [View More]

1 0

Re: MC/MCU related
by Sunil Chandra 05 Sep '99

05 Sep '99

Hi Chris, >> 5. If a call signalling is routed through Gatekeeper, and there exists an >> MCU which is not involved in this call. Is it possible for the Gatekeeper >> to involve this MCU to create an ad-hoc conference from this call. If yes, >> what is the procedure? If not, why? > > You leave the biggest question until last... > And one close to my heart. > I've written a number of documents on this, and now I can't find any … [View More]of them... > > The tricky bit is working out that this is what you want to do. > I assume you have a gatekeeper which routes both H.225.0 (extended Q.931) call > signalling and H.245 control signalling. > > First off, the gatekeeper uses terminal type for master-slave determination as > if it had the MCU functionality built-in. This is permitted because wherever > the standard talks about a gatekeeper having an MCU it uses the phrase "access > to an MCU". > When the gatekeeper decides a call needs to be split out into a conference (for > example, one of the parties in the call sends a setup using the same > conferenceID and different CallID & CRV) - or even on ARQ for this new call - > the gatekeeper does the following: > 1. Make two calls to the MCU, and get them to state "connected". > 2. Send the MCU the terminal capability sets for the endpoints in the existing > call (one on each call). > 3. Do master-slave determination on each call (the gatekeeper will be "master" > on the original calls, otherwise you're stuffed - but in this case there was > already an MCU in the call, so no problem) - in which the gatekeeper will end > up as "slave" (all MCUs beat all GKs). > 4. "Wire things up" internally such that instead of all the Q.931 and H.245 > messages going directly from one endpoint to the other, each endpoint talks to > the MCU on a different call. > ...and you have a two-party conference (as opposed to a call). The MCU will > now generate various exotic messages, and the endpoints will respond > beautifully - the gatekeeper just passes things through transparently now. Assume that the gatekeeper uses the half call model. Let us say that the callId of the original call was CIo, and callIds of the new calls from gatekeeper to the MCU are CIn1 and CIn2. Now, at the gatekeeper, there are two calls in the conference, one call has one call leg with callId CIo and other call leg with callId CIn1, and the other call has one call leg with callId CIo and the other call leg with callId CIn2. Now, if one of the terminals, want to send any call signalling message e.g. facility to its peer (terminal does not know it is connected to MCU), it will send this message with callId CIo. In this case, gatekeeper has to interpret the message and change its contents to reflect the new callId. This will make the gatekeeper very complex and lead to many interoperability issues as it will be very specific implementation of this feature as opposed to a well defined scenario in the protocol itself. > > Alternatives/extras: > If you trust people to have implemented H.450.2, or you care about everybody > paying properly for everything, > How are various charging models for supplementary services like H.450.2 and H.450.3. Are these very much same as SCN or some other models totally different from SCN models? How does charging issues affect the conversion of call into ad-hoc conference? > you could transfer the calls to the MCU using > H.450.2. > You could send some "CloseLogicalChannel"s to the endpoints in the original > call before connecting them up to the MCU, so that the MCU starts from a "clean > sheet". > > What I've given is a bit of an outline, and it does need a little refinement, > but essentially it should give you a call-to-conference transition with the > endpoints concerned having little or no knowledge of what's going on!!! > > Regards, > Chris > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 [View Less]

1 0

Redundant silenceSuppression fields
by Paul Long 03 Sep '99

03 Sep '99

It doesn't really matter, but I was wondering, why are there two, apparently redundant silenceSuppression fields in the H.245 ASN.1 syntax, one in AudioCapability.g7231 and another in H2250LogicalChannelParameters? Paul Long Smith Micro Software, Inc.

1 0