SDP and H.245 Data Structures

[Tom-PT Taylor]

Boy Chip,

You are one forward-thinking Guy. In fact, your email is ONE
MONTH in the future :-)

Regards,

Danny Eskenazi

Chip Sharp wrote:
>
> At 10:43 AM 5/7/99 +0200, Karl.Klaghofer at ICN.SIEMENS.DE wrote:
> >Glen and others,
> >
> >It was a mistake to exclude the octet 3a in H.225.0 (v1 and v2) Calling
> >party number IE.  It has led to interoperability problems with the SCN in
> >the past (where octet 3a is used) !
>
> I agree.  I might be okay in an enterprise environment, but in a Service
> Provider environment the lack of Octet 3a makes it impossible to support
> the CLIP/CLIR service as defined in Q.951 in an standard manner.
>
> >Now, it is time to fix this error as discussed in the Monterey Rapporteuts
> >meeting in February (i.e. for H.225.0v3 but also for H.225.0v2 via
> >Implementors Guide !). There may be procucts already planning on that
> >announced correction.
> >
> >An endpoint B - not supporting octet 3a of Calling Party Number Information
> >element - should treat this situation as a "non-mandatory information
> >element content error". The reaction to such an type of error shall be:
> >*       Take actions on the SETUP received and on all the information
> >elements that are recognized and have valid contents; i.e. ignore only the
> >Calling party Number IE
> >*       A STATUS may optionally be returned with Cause #100.
> >
> >Refer also to Q.931 clause 5.8.7.2 (which should applicable also to H.225.0,
> >since H.225.0 is so much based on the Q.931).
> >
> >So, if such an endpoint B receives an octet 3a in Calling party Number set
> >to "presentation allowed", all that happens is that the Number would not be
> >displayed at B.
>
> The only problem I see is the optional STATUS message.  Implementations
> using the STATUS message option will generate unnecessary traffic.  In a
> low-volume environment, this shouldn't be too bad.
>
> >But for the really critical case where the octet 3a is received by such an
> >endpoint B being set to "presentation restrictet", we have even the behavier
> >we intend, namely NOT to display the number to the endpoint B (since the
> >whole IE should be ignored anyway).
>
> In the case of interoperating with a v1/v2 implementation that doesn't
> recognize Octet 3a, the receiver will drop the Information Element and,
> worst case, send a STATUS message.  Thus, worst case is that the Calling
> Party Number will not be available to the receiving endpoint.  This seems
> to be a sufficient failsafe to me.
>
> Since the SCN Gateway must implement policy anyway, it could also have a
> policy to act on Octet 3a differently (e.g., drop the Calling Party Number
> if "presentation restricted" is encoded or the digits aren't available and
> pass it on without Octet 3a otherwise.).
>
> >A miscoded optional Information element should never lead to a clearing of
> >the call !
> >
> >Regards,
> >Karl
> >------------------------------------------------
> >Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1
> >Hofmannstr. 51, D-81359 Munich, Germany
> >Tel.: +49 89 722 31488, Fax.: +49 89 722 37629
> >e-mail: karl.klaghofer at icn.siemens.de
> >
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von:  Glen Freundlich [SMTP:ggf at lucent.com]
> >> Gesendet am:  Donnerstag, 6. Mai 1999 22:11
> >> An:   ITU-SG16 at mailbag.cps.intel.com
> >> Betreff:      caller ID and implementer's guide
> >>
> >> At the Monterey meeting we discussed the possibility of an addition to
> >> the Implementer's Guide to support caller ID features (APC-1527).
> >> H.225.0 V2 (and V1) forbids the use of octet 3a in the Calling Party
> >> Number IE (and also specifies that the octet 3 extension bit shall be
> >> set to 1). The proposal calls for removing the restriction through the
> >> Implementer's Guide. (See also the meeting report in APC-1554b.)
> >>
> >> Fixing this brings up the possibility of interoperability problems with
> >> existing products. Please respond if you think this change will be a
> >> problem. You can respond to me individually, rather than to the entire
> >> list, if you prefer.
> >>
> >> Thanks,
> >> Glen
> >>
> >>
> >> --
> >> Glen Freundlich                           ggf at lucent.com
> >> Lucent Technologies                       office: +1 303 538 2899
> >> 11900 N. Pecos                            fax: +1 303 538 3907
> >> Westminster, Colorado 80234  USA
>
> --------------------------------------------------
> Chip Sharp                 voice: +1 (919) 851-2085
> Cisco Systems              Consulting Eng. - Telco
> Reality - Love it or Leave it.
> --------------------------------------------------