RAS to INAP

[Edgar Martinez [1]]

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