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@cisco.com] Gesendet am: Dienstag, 24. Oktober 2000 22:15 An: ITU-SG16@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@ties.itu.int http://people.itu.int/~michaely
> For help on this mail list, send "HELP ITU-SG16" in a message to > listserv@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com