AW: ASN.1 question on supporting Redirecting Number in Annex G

[Horvath Ernst]

Mr. Michaely,

the transport of information elements in their SCN encoded form is also
foreseen in H.450 protocols. For this purpose H.450.1 defines the "generic"
type H225InformationElement, which is a simple OCTET STRING. Within the
octet string, any number of concatenated information elements can be
embedded. The idea is that the whole string can be handed over unchanged to
the Q.931 parsing process.

Ernst Horvath

> -----Ursprüngliche Nachricht-----
> Von: Logan Modahala [mailto:lmodahal at cisco.com]
> Gesendet am: Dienstag, 24. Oktober 2000 22:15
> An: ITU-SG16 at mailbag.cps.intel.com
> Betreff: Re: ASN.1 question on supporting Redirecting Number
> in Annex G
>
> Mr. Michaely:
>
> We can define something like this:
>
>    ieInfo        IEInfoType    OPTIONAL
>
> IEInfoType    ::=    SEQUENCE
> {
>     ieID                INTEGER (1..255),
>     ieContent        OCTET    STRING
>     .....
> }
>
>
> ieID will identify ProgIndIE, RedirectIE and so forth based
> on the IE Id assigned
> in PSTN world.
> ieContent is the actual encoding of the IE as per the Q.931 spec.
>
> - Logan
>
>
>
> Boaz Michaely wrote:
>
> > All,
> >
> > Following up the work started at Lovely Portland, we are
> investigating the
> > required additions to the AccessRequest et. al. messages of
> H.225.0 Annex G.
> > I will post a seperate note on that, but along the way, an
> interesting question
> > poped:
> >
> > The scenario: A VoIP network that is trying to terminate a
> call in PSTN, over
> > ISDN. The response from the CO indicates the call diversion
> and includes the
> > redirecting number element (which also indicates the
> diversion reason)
> > With H.225.0 v4 addition (TD-45 Osaka), this information
> can be naturaly
> > translated into H.225.0 setup message, while before that
> the only way to convey
> > the information was to translate it into H.450.3
> > Now, the network GK wishes to forward the call to the
> Service Zone for call
> > completion. In order to provide this information over
> AccessRequest, we may add
> > both H.450 element as well as RedirectingNumber element
> (for the questionable
> > sake of not mandating H.450 structures to do so).
> >
> > Now to my question:
> > Assuming that indeed there is objection to mandate H.450
> structure for this
> > purpose, how does one describe the RedirectingNumber IE
> within the ASN.1
> > structure of H.225.0 Annex G ?
> > After all, RedirectingNumber is imported from Q.931, and as
> such is bitwise
> > encoded. (there is probably a proper term for that which,
> in my ignorance, I
> > am unaware off - sorry).
> > I have not seen any similar case, so the only solution I
> came up with is to
> > embed it in a BIT STRING. Is this realy how it should be
> done ? If so, what
> > would the exact syntax be ?
> >
> > Thanks,
> >
> > Boaz Michaely
> > Senior System Architect, Corporate
> > Comverse Network Systems
> > Tel: +972 (3) 766-3844 , Mobile +972 (51) 62-58-44
> > mailto:boaz.michaely at ties.itu.int
> > http://people.itu.int/~michaely
> >
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com