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/