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: 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/