Mr. Okubo,
I have placed a copy of the white paper draft for H.323v4 (which includes Annex D/H.323) in the incoming directory of the AVC site.
Thanks,
Paul
Daniel,
Non-ITU variants can have OIDs that are defined by the controlling body.
OID for non-ITU variants should not be defined by the ITU. It is too easy
to omit one and then there is a problem.
Bob
------------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
Tel: +1.561.923.1756 Fax: +1.561.923.1403
Email: Robert.Callaghan(a)ICN.Siemens.com
------------------------------------------------------------------
-----Original Message-----
…
[View More]From: Daniel Eskenazi [mailto:deskenaz@cisco.com]
Sent: Friday, July 07, 2000 3:40 PM
To: Francois Audet
Cc: Callaghan, Robert; 'Mailing list for parties associated with ITU-T
Study Group 16'; paulej(a)cisco.com
Subject: Re: Deficiency in Annex M, specifically M.2?
Hi Francois,
Are you saying that even if the OID hierarchy is underneath
ITU H 225, it is still not advisable to enumerate non-ITU variants?
I am not very knowledgeable about OID manners so I didn't realize
this is frowned upon.
Regarding variants for QSIG, I suppose you could have a complicated
OID hierarchy underneath Annex M (1) that lists the version for each
functional area (basic call, generic protocol, supp services, etc).
There's no reason the hierarchy can't be different underneath each
Annex M protocol, is there?
My original concern was for ISUP - I take it the ability to
discriminate version(s) is important for QSIG as well?
Thanks,
Daniel Eskenazi
> Francois Audet wrote:
>
> I don't think you want to use the ITU OID for ISUP
> when using, for example, the North American variant.
>
> An aditional problem is that there is no such thing as a version for
> QSIG. You have versions for basic call control, and another version
> for the
> generic functional protocol, others for individual supplementary
> services.
> I'm not sure how to solve that.
>
> > -----Original Message-----
> > From: Daniel Eskenazi [mailto:deskenaz@cisco.com]
> > Sent: Friday, July 07, 2000 12:02 PM
> > To: Callaghan, Robert; Audet, Francois [SC9:4K02:EXCH]
> > Cc: 'Mailing list for parties associated with ITU-T Study Group 16';
>
> > paulej(a)cisco.com
> > Subject: Re: Deficiency in Annex M, specifically M.2?
> >
> >
> >
> > Bob (and Francois, who also mentioned the same thing),
> >
> > Agreed, this would work too, and I'm not opposed
> > to that solution. My thinking was that adding the
> > new fields would be slightly easier for implementors,
> > since an endpoint that is interested in tunneling,
> > for example, all ISUP variants but no QSIG variants can
> > easily determine that the tunneled data is ISUP rather
> > than QSIG just by matching the hard-coded ISUP OID,
> > without having to "parse" the OID. On the other hand,
> > the OID approach has the advantage of not requiring any
> > ASN.1 changes.
> >
> > But even with OID approach, Annex M.2 (and potentially M.1) need
> > minor chang(es), since they are hard-coded to indicate a single
> > OID value for QSIG or ISUP. We would need to define a new
> > OID hierarchy for specifying Annex-M Protocol/Variant/Version,
> > and refer to the OID hierarchy from within Annex-M.2(and
> > possibly M.1). Agreed?
> >
> > Thanks,
> >
> > Daniel Eskenazi
> >
> > "Callaghan, Robert" wrote:
> > >
> > > Daniel,
> > >
> > > This problem can also be solved by having different Object
> > Ids for each
> > > variant of ISUP.
> > >
> > > Bob
> > >
> > >
> > --------------------------------------------------------------
> > --------------
> > > -----------------------------
> > >
> > > Hi Jan,
> > >
> > > Annex M.2 does not seem to provide any standard mechanism for
> > > specifying the variant of ISUP that is being tunneled.
> > Therefore ISUP
> > > tunneling as currently defined in Annex M.2 will only work
> properly
> > > if both H.323 endpoints are connected to ISUP equipment using the
> > > exact same type and version of ISUP. Do you agree?
> > >
> > > Assuming that I didn't miss something and this is a valid
> > > concern, the addition of type and version fields would solve
> > > this problem. I believe Protocol type and version information
> > > would be universally useful for all tunneled protocols, so I
> > > propose that the tunneledSignallingMessage construct be enhanced
> > > to provide fields for protocolType (or maybe it should be called
> > > protocolVariant?) and protocolVersion; exact format TBD.
> > >
> > > Any comments?
> > >
> > > Thanks,
> > >
> > > --
> > > Daniel Eskenazi .|. .|. dve(a)cisco.com OR
> deskenaz(a)cisco.com
> > > Cisco Systems ..::|::..::|::.. 919-472-3891
> > >
> > >
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > listserv(a)mailbag.intel.com
> >
> > --
> > Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com
>
> > Cisco Systems ..::|::..::|::.. 919-472-3891
> >
--
Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com
Cisco Systems ..::|::..::|::.. 919-472-3891
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Daniel,
The problem in the past with defining variants of ISUP is that many variants
are controlled by national bodies. This will make it hard to define these
in an ITU-T defined structure. (But you are welcome to try.)
I have no problem changing the OID to a list of.
Bob
------------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
Tel: +1.561.923.1756 Fax: +1.561.923.1403
Email: Robert.Callaghan(a)ICN.Siemens.com
--------------------…
[View More]----------------------------------------------
-----Original Message-----
From: Daniel Eskenazi [mailto:deskenaz@cisco.com]
Sent: Friday, July 07, 2000 3:02 PM
To: Callaghan, Robert; audet(a)nortelnetworks.com
Cc: 'Mailing list for parties associated with ITU-T Study Group 16';
paulej(a)cisco.com
Subject: Re: Deficiency in Annex M, specifically M.2?
Bob (and Francois, who also mentioned the same thing),
Agreed, this would work too, and I'm not opposed
to that solution. My thinking was that adding the
new fields would be slightly easier for implementors,
since an endpoint that is interested in tunneling,
for example, all ISUP variants but no QSIG variants can
easily determine that the tunneled data is ISUP rather
than QSIG just by matching the hard-coded ISUP OID,
without having to "parse" the OID. On the other hand,
the OID approach has the advantage of not requiring any
ASN.1 changes.
But even with OID approach, Annex M.2 (and potentially M.1) need
minor chang(es), since they are hard-coded to indicate a single
OID value for QSIG or ISUP. We would need to define a new
OID hierarchy for specifying Annex-M Protocol/Variant/Version,
and refer to the OID hierarchy from within Annex-M.2(and
possibly M.1). Agreed?
Thanks,
Daniel Eskenazi
"Callaghan, Robert" wrote:
>
> Daniel,
>
> This problem can also be solved by having different Object Ids for each
> variant of ISUP.
>
> Bob
>
>
----------------------------------------------------------------------------
> -----------------------------
>
> Hi Jan,
>
> Annex M.2 does not seem to provide any standard mechanism for
> specifying the variant of ISUP that is being tunneled. Therefore ISUP
> tunneling as currently defined in Annex M.2 will only work properly
> if both H.323 endpoints are connected to ISUP equipment using the
> exact same type and version of ISUP. Do you agree?
>
> Assuming that I didn't miss something and this is a valid
> concern, the addition of type and version fields would solve
> this problem. I believe Protocol type and version information
> would be universally useful for all tunneled protocols, so I
> propose that the tunneledSignallingMessage construct be enhanced
> to provide fields for protocolType (or maybe it should be called
> protocolVariant?) and protocolVersion; exact format TBD.
>
> Any comments?
>
> Thanks,
>
> --
> Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com
> Cisco Systems ..::|::..::|::.. 919-472-3891
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
--
Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com
Cisco Systems ..::|::..::|::.. 919-472-3891
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
> Hi Francois,
>
> Are you saying that even if the OID hierarchy is underneath
> ITU H 225, it is still not advisable to enumerate non-ITU variants?
> I am not very knowledgeable about OID manners so I didn't realize
> this is frowned upon.
No, I'm saying the current OID for ISUP refers specifically to an ITU-T
Recomendation, not the concept of "ISUP" (the OID is owned by ITU). To
refer to, lets say, an ANSI version would require an ANSI OID.
> Regarding variants for QSIG,…
[View More] I suppose you could have a complicated
> OID hierarchy underneath Annex M (1) that lists the version for each
> functional area (basic call, generic protocol, supp services, etc).
> There's no reason the hierarchy can't be different underneath each
> Annex M protocol, is there?
Yeah. So this seems to be too complicated, which is why we just say "QSIG".
> My original concern was for ISUP - I take it the ability to
> discriminate version(s) is important for QSIG as well?
I don't think it is as important since most implementation have already
converged to the ISO standard
[View Less]
I don't think you want to use the ITU OID for ISUP
when using, for example, the North American variant.
An aditional problem is that there is no such thing as a version for
QSIG. You have versions for basic call control, and another version for the
generic functional protocol, others for individual supplementary services.
I'm not sure how to solve that.
> -----Original Message-----
> From: Daniel Eskenazi [mailto:deskenaz@cisco.com]
> Sent: Friday, July 07, 2000 12:02 PM
> To: …
[View More]Callaghan, Robert; Audet, Francois [SC9:4K02:EXCH]
> Cc: 'Mailing list for parties associated with ITU-T Study Group 16';
> paulej(a)cisco.com
> Subject: Re: Deficiency in Annex M, specifically M.2?
>
>
>
> Bob (and Francois, who also mentioned the same thing),
>
> Agreed, this would work too, and I'm not opposed
> to that solution. My thinking was that adding the
> new fields would be slightly easier for implementors,
> since an endpoint that is interested in tunneling,
> for example, all ISUP variants but no QSIG variants can
> easily determine that the tunneled data is ISUP rather
> than QSIG just by matching the hard-coded ISUP OID,
> without having to "parse" the OID. On the other hand,
> the OID approach has the advantage of not requiring any
> ASN.1 changes.
>
> But even with OID approach, Annex M.2 (and potentially M.1) need
> minor chang(es), since they are hard-coded to indicate a single
> OID value for QSIG or ISUP. We would need to define a new
> OID hierarchy for specifying Annex-M Protocol/Variant/Version,
> and refer to the OID hierarchy from within Annex-M.2(and
> possibly M.1). Agreed?
>
> Thanks,
>
> Daniel Eskenazi
>
> "Callaghan, Robert" wrote:
> >
> > Daniel,
> >
> > This problem can also be solved by having different Object
> Ids for each
> > variant of ISUP.
> >
> > Bob
> >
> >
> --------------------------------------------------------------
> --------------
> > -----------------------------
> >
> > Hi Jan,
> >
> > Annex M.2 does not seem to provide any standard mechanism for
> > specifying the variant of ISUP that is being tunneled.
> Therefore ISUP
> > tunneling as currently defined in Annex M.2 will only work properly
> > if both H.323 endpoints are connected to ISUP equipment using the
> > exact same type and version of ISUP. Do you agree?
> >
> > Assuming that I didn't miss something and this is a valid
> > concern, the addition of type and version fields would solve
> > this problem. I believe Protocol type and version information
> > would be universally useful for all tunneled protocols, so I
> > propose that the tunneledSignallingMessage construct be enhanced
> > to provide fields for protocolType (or maybe it should be called
> > protocolVariant?) and protocolVersion; exact format TBD.
> >
> > Any comments?
> >
> > Thanks,
> >
> > --
> > Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com
> > Cisco Systems ..::|::..::|::.. 919-472-3891
> >
> >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
>
> --
> Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com
> Cisco Systems ..::|::..::|::.. 919-472-3891
>
[View Less]
Hi, Jaakko and Everyone:
It is nice to see that you and Mr. Kumar had a communication related to GRQ
and you have included in the contribution.
I wonder what happened to the emails that I sent to the SG16 email "public"
reflector related to MGA message! I have not seen any counter arguments
related to this in the email reflector. I like to see that MGA message is
also included (with both unicast and multicast option as suit the
implementation).
I would also appreciate that you should start …
[View More]discussing in the email
reflector before any further update is made in the document so that we can
participate in the process for updating the document. The discussion can be
formulated as follows:
1. What you want to propose and why
2. Pros and cons of the proposals
3. Invite comments from the members
4. Update the document based on item 3
Items 1 and 2 can be formulated in a simple and concise manner (in fact you
did in many cases).
Please note that I am encouraging for updating, but defining a process how
an editor can update a contribution in absence of any contributions (or
conference calls) from any members other than the editor.
(I also plan to provide my comments on the latest document. However, I am
busy with so many works that I am yet to find time.)
Finally, I appreciate your efforts in carrying this work.
Best regards,
Radhika R. Roy
> -----Original Message-----
> From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com]
> Sent: Friday, July 07, 2000 8:40 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: [H.323 Mobility:] A new H.323 Annex H Draft
>
> Hi all,
>
> I have uploaded the new H.323 Annex H Draft to URL:
> ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-101b_H323Annex
> HDraft.zip
>
>
> Most changes to the previous version are in chapter 7 (H.323 Mobility
> Functional Requirements), most parts of which have been rewritten.
>
> Some changes have been introduced also to section 10.5.1 concerning the
> contents of the authentication messages towards the AuF. Mr. Kumaar has
> pointed out that authentication values are (normally) calculated over the
> whole GRQ message and thus it is necessary to send the whole GRQ message
> to
> the AuF. I have not found anything that would disprove this point and thus
> I
> assume that this is the way we must specify the authentication procedure.
> I'm also quite aware that the effects of the inclusion of the GRQ message
> have probably not been throughly added to the section, but I wanted to get
> this version out before weekend and still have a mention of the issue in
> the
> draft. I would like to hear (or read) any comments that the experts have
> regarding this section as I'm not a very good expert on H.235.
>
> Furthermore, I'll try to work out the next version of the annex as soon as
> possible and I'm hoping to add quite much stuff on the information flow
> and
> message content definitions. I would also like to see contributions
> especially on these areas.
>
> I hope that not all of you are spending your holidays and I actually get
> some comments ;-).
>
> Anyway, have a nice weekend, everyone!
>
> ------------------------------------------------
> Jaakko Sundquist *
> +358 50 3598281 * Audere est Facere!
> jaakko.sundquist(a)nokia.com *
> ------------------------------------------------
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Daniel,
This problem can also be solved by having different Object Ids for each
variant of ISUP.
Bob
----------------------------------------------------------------------------
-----------------------------
Hi Jan,
Annex M.2 does not seem to provide any standard mechanism for
specifying the variant of ISUP that is being tunneled. Therefore ISUP
tunneling as currently defined in Annex M.2 will only work properly
if both H.323 endpoints are connected to ISUP equipment using the
exact same …
[View More]type and version of ISUP. Do you agree?
Assuming that I didn't miss something and this is a valid
concern, the addition of type and version fields would solve
this problem. I believe Protocol type and version information
would be universally useful for all tunneled protocols, so I
propose that the tunneledSignallingMessage construct be enhanced
to provide fields for protocolType (or maybe it should be called
protocolVariant?) and protocolVersion; exact format TBD.
Any comments?
Thanks,
--
Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com
Cisco Systems ..::|::..::|::.. 919-472-3891
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
&#*&?$"@,
I also copied M.1 from some other draft (I don't remember which one). I will
insert the "not" and send it back to the ITU.
I suspect that M.2 may have the same problem since I believe it was copied
from M.1.
> -----Original Message-----
> From: Espen Skjæran (ETO) [mailto:Espen.Skjaeran@ETO.ERICSSON.SE]
> Sent: Friday, July 07, 2000 6:46 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: Intellectual property/patents on H.323 Annex K???
>
>
> …
[View More]Frank,
> This is positively a mistake. I copied the whole header from
> H.323 Annex M.1 in Geneva (PL-39.doc), which of some reason
> had this text instead of the original (claiming "... not
> received..."). This has now been updated in the latest
> version of Annex M.1.
>
> To my knowledge, ITU has not received any notice about this.
> I haven't done any exhaustive IPR search on this, but do not
> know of anything that will block this recommendation.
>
> Regards,
> Espen
>
> -----Original Message-----
> From: Frank Derks [mailto:frank.derks@PHILIPS.COM]
> Sent: 5. juli 2000 11:26
> To: ITU-SG16(a)mailbag.cps.intel.com
> Subject: Intellectual property/patents on H.323 Annex K???
>
>
> H.323 Annex K/APC-1811 (May 2000 meeting), states that the
> ITU has "...received notice of intellectual property,
> protected by patents, which may be required to implement this
> recommendation". Is anyone in a position to inform me which
> patent(s) are
> involved?
>
> Regards,
>
> Frank
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
[View Less]
Hi Jan,
Annex M.2 does not seem to provide any standard mechanism for
specifying the variant of ISUP that is being tunneled. Therefore ISUP
tunneling as currently defined in Annex M.2 will only work properly
if both H.323 endpoints are connected to ISUP equipment using the
exact same type and version of ISUP. Do you agree?
Assuming that I didn't miss something and this is a valid
concern, the addition of type and version fields would solve
this problem. I believe Protocol type and version …
[View More]information
would be universally useful for all tunneled protocols, so I
propose that the tunneledSignallingMessage construct be enhanced
to provide fields for protocolType (or maybe it should be called
protocolVariant?) and protocolVersion; exact format TBD.
Any comments?
Thanks,
--
Daniel Eskenazi .|. .|. dve(a)cisco.com OR deskenaz(a)cisco.com
Cisco Systems ..::|::..::|::.. 919-472-3891
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
I have placed 2 liaisons from SG11 on the Pictel avc-site:
APC-1872: Liaison to SG16 On Interaction Between Intelligent Network
Systems and H.248
APC-1873: Liaison to SG16 On Interworking Between H.323 Systems and
Intelligent Network Systems
Regards,
Glen
--
Glen Freundlich ggf(a)lucent.com
Lucent Technologies office: +1 303 538 2899
11900 N. Pecos fax: +1 303 538 3907
Westminster, Colorado 80234 USA
~~~~~~~~~~~~~~~~~~~~~~~~~~…
[View More]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
