Dear All,
I have uploaded a draft on H.GEF.1 (Guidelines for the Use of the Generic
Extensible Framework) to the PictureTel Incoming directory.
Unfortunately I've lost the email describing what the formal submission
procedure is, so if one of the rapporteurs could help me out on that it
would be appreciated.
-----------
Summary
This Recommendation gives guidelines on how to use the "Generic
extensibility Framework" specified in H.323v4. It describes when to use the
framework, and how to …
[View More]specify features using the framework. It also gives
examples on how the GEF negotiation scheme works.
-----------
There are a couple of items worth debating, the main one being...
- I have defined a syntax way of defining GEF modules. Opinion is sought on
whether this stays in the document.
Regards,
Pete.
=============================================
Pete Cordell
Tech-Know-Ware
pete(a)tech-know-ware.com
+44 1473 635863
=============================================
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
All,
I'll be lazy and ask rather than looking through the ASN.1 to find it...
Is there support in H.323 for signaling to use RTCP?
There is a current thread on the IETF AVT e-mail reflector where
talk is of making RTCP mandatory (i.e.-changing it from a SHOULD
to a MUST in the RTP specification). The last I heard was that the
MUST would apply to implementing RTCP, and not necessarily to
using it. Presumably the application level call signaling protocol can
be responsible for signaling …
[View More]whether RTCP was to be used.
If an endpoint implemented RTCP it should at least benignly ignore
received RTCP reports and would not need to send any. So a given
operator could specify that RTCP not be signaled if it were not
practical in their network. Obvious examples would be wireless
networks and cable networks where there are access bandwidth
constraints.
Cheers,
Rex
[View Less]
There are at least four contributions to the upcoming Study Group 11 meeting
(May 14-May 25)related to this topic. If you have ITU TIES access, they are
under Delayed Contributions 207, 212, 214, and 215.
-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ericsson.com]
Sent: Wednesday, May 09, 2001 1:41 AM
To: Petros N. Mouchtaris
Cc: Rosen, Brian; megaco; SG16; Oskar vanDeventer
Subject: Re: IP Type of Service
I think that any work on QoS parameters should be aligned …
[View More]with the work
occuring in ETSI Tiphon, ITU SG16, ITU SG11 etc. There's been a
considerable amount of effort in trying to come up with common
parameters for QoS. Any solution should tap into this.
Cheers, Christian
"Petros N. Mouchtaris" wrote:
>
> Brian,
>
> Actually there was a long discussion on this topic last year on the
mailing
> list i.e. whether MGC should be able to signal an MG which TOS bit to use.
> The whole topic ended up being dropped. Check the archive for e-mails with
> title "MG and DiffServ".
>
> By the way, Flemming had volunteered to do some work but I assume it
didn't
> have high enough priority.
>
> Excerpt from e-mail:
>
> "Tom-PT Taylor wrote:
>
> > You are correct that packages should be drawn up
(and/or SDP defined) to
> > allow QOS parameter setting. Volunteers?
>
> Sure - I can put a package proposal together.
>
> -- Flemming
>
> Petros
>
> "Rosen, Brian" <Brian.Rosen(a)marconi.com> on 05/08/2001 03:29:44 PM
>
> To: "'Tom-PT Taylor'" <taylor(a)nortelnetworks.com>, "'Madhu Babu
> Brahmanapally'" <madhubabu(a)kenetec.com>, "Rosen, Brian"
> <Brian.Rosen(a)marconi.com>, "'Chuong Nguyen'"
> <Chuong.Nguyen(a)usa.alcatel.com>, megaco <megaco(a)fore.com>
> cc: (bcc: Petros N. Mouchtaris/Telcordia)
> Subject: RE: IP Type of Service
>
> I'll look into this. I agree.
>
> Brian
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Tuesday, May 08, 2001 10:07 AM
> To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen'; megaco
> Subject: RE: IP Type of Service
>
> That makes sense.
>
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Tuesday, May 08, 2001 10:08 AM
> To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong Nguyen';
> megaco
> Subject: RE: IP Type of Service
>
> Hi All,
> Another suggestion. Why cant the SDP be extended to incorporate a TOS
> parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that use
SDP
> need not define extra properties/parameter for supporting this.
>
> Regards
> Madhubabu
>
> -----Original Message-----
> From: owner-megaco(a)pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> Sent: Tuesday, May 08, 2001 9:24 AM
> To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen';
> megaco(a)fore.com
> Subject: RE: IP Type of Service
>
> I don't agree. The TOS for a particular stream should be set on that
> stream, not
> on the MG as a whole. For example, if I have a multimedia MG, I will want
> to set
> the priority of voice higher than video, and video higher than normal. If
> I
> implement a
> Multilevel Pre-emption and Priority scheme, some calls will have higher
> priority than
> others. The TOS/frame priority has to be per stream.
>
> Brian
>
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Tuesday, May 08, 2001 9:24 AM
> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco(a)fore.com
> Subject: RE: IP Type of Service
>
> Hi All,
>
> The default TOS type should be defined on the ROOT termination for the
> default TOS used for all media packets generated from the MG. There should
> be a method (might be through some property) of specifying stream level
TOS
> bits.
>
> I'm interested to work on RSVP.
>
> Regards
> Madhubabu
>
> -----Original Message-----
> From: owner-megaco(a)pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> Sent: Tuesday, May 08, 2001 8:10 AM
> To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco(a)fore.com'
> Subject: RE: IP Type of Service
>
> TOS should not be ignored at the edge router if the router is configured
to
> enable DiffServ.
>
> It would be pretty simple to create one package that had the appropriate
> controls for
> DiffServ and 802.1p. RSVP needs it's own package because there is
> messaging,
> and you at least an event or two
>
> The former could be an enumeration: QosMarking, that had values None, TOS
> and
> FramePriority, plus another integer, Value. That would suffice I think,
> although you
> could conceivably get more clever with DiffServ.
>
> Shall I write something up along those lines?
>
> RSVP takes some more work. Any volunteers?
>
> Brian
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Monday, May 07, 2001 9:15 PM
> To: 'Chuong Nguyen'; 'megaco(a)fore.com'
> Subject: RE: IP Type of Service
>
> No such package has yet been defined.
>
> Various QOS architectures can be imagined. Each would give rise to its
own
> package, since the MGC-MG information flow would differ from one
> architecture to the next. One question: unless the MG is itself the edge
> router, won't the ToS be ignored when the media packets reach the latter?
>
> -----Original Message-----
> From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> Sent: Monday, May 07, 2001 5:14 PM
> To: 'megaco(a)fore.com'
> Subject: IP Type of Service
>
> All
>
> In MGCP, MGC can specify IP Type of Service to the MG.
> Do we have an equivalent in Megaco?
>
> Is there or has anyone defined a package for IP Type of Service?
>
> Thanks
> Chuong
>
> --
>
> Alcatel USA, Inc Internet: Chuong.Nguyen(a)usa.alcatel.com
>
> 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613
>
> **** The opinions expressed are not those of Alcatel USA, Inc ****
>
> ------------------------------------------------------------------------
> Name: att1.htm
> att1.htm Type: Hypertext Markup Language (text/html)
> Encoding: base64
[View Less]
Paul,
the user-data field is a container for a "real" Q.931 user-user information
element. Since H.225.0 re-defines the User-user IE for its own use, Q.931
user-user information, if present, must be put somewhere else, that's why
the user-data field was included in H323-UserInformation. I don't know if it
is ever used in practice.
Ernst Horvath
Siemens AG
-----Ursprüngliche Nachricht-----
Von: Paul Long [mailto:plong@IPDIALOG.COM]
Gesendet am: Dienstag, 08. Mai 2001 17:43
An: ITU-SG16(a)…
[View More]mailbag.cps.INTEL.COM
Betreff: Re: How to get the heel of RAS Message.
Delphi,
1. I have no idea what the user-data component is used for.
2. I don't know what you mean by "get and set," but RAS does not use Q.931
or UUIEs in its encoding. It uses ASN.1 PER exclusively. I assume by your
other question that you are asking what the outer-most encoding is for RAS.
With call-signaling, it's Q.931; with RAS, it's ASN.1 PER--RAS uses ASN.1
PER throughout.
Paul Long
ipDialog, Inc.
-----Original Message-----
From: Mailing list for parties associated with ITU-T Study Group 16
[mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf Of Delphi
Sent: Tuesday, May 08, 2001 1:53 AM
To: ITU-SG16(a)mailbag.cps.INTEL.COM
Subject: How to get the heel of RAS Message.
Hi, all:
I have two problems concerning H.323 ASN.1.
1>
H.323 ASN.1 states as follows:
>>>>>>>>>
H323-UserInformation::=SEQUENCE
{
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Dear SG16 experts,
The following draft by Mr. Mike Nilsson, Editor, is now available for your
review toward the Porto Seguro meeting:
http://standard.pictel.com/ftp/avc-site/0105_Por/h245wcmp.zip
Best regards,
OKUBO Sakae
*********************************************************
Global Information and Telecommunication Institute (GITI)
Waseda University
29-7 Waseda University Bldg.
1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo
169-0051 Japan
e-mail: okubo(a)giti.waseda.ac.jp
Tel:…
[View More] +81 3 3204 8194
Fax: +81 3 5286 3832
*********************************************************
My contract with TAO finished on 31 March. Please change
my e-mail address as above, though okubo(a)giti.or.jp will
continue to work for some time.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
I think that any work on QoS parameters should be aligned with the work
occuring in ETSI Tiphon, ITU SG16, ITU SG11 etc. There's been a
considerable amount of effort in trying to come up with common
parameters for QoS. Any solution should tap into this.
Cheers, Christian
"Petros N. Mouchtaris" wrote:
>
> Brian,
>
> Actually there was a long discussion on this topic last year on the mailing
> list i.e. whether MGC should be able to signal an MG which TOS bit to use.
> The …
[View More]whole topic ended up being dropped. Check the archive for e-mails with
> title "MG and DiffServ".
>
> By the way, Flemming had volunteered to do some work but I assume it didn't
> have high enough priority.
>
> Excerpt from e-mail:
>
> "Tom-PT Taylor wrote:
>
> > You are correct that packages should be drawn up (and/or SDP defined) to
> > allow QOS parameter setting. Volunteers?
>
> Sure - I can put a package proposal together.
>
> -- Flemming
>
> Petros
>
> "Rosen, Brian" <Brian.Rosen(a)marconi.com> on 05/08/2001 03:29:44 PM
>
> To: "'Tom-PT Taylor'" <taylor(a)nortelnetworks.com>, "'Madhu Babu
> Brahmanapally'" <madhubabu(a)kenetec.com>, "Rosen, Brian"
> <Brian.Rosen(a)marconi.com>, "'Chuong Nguyen'"
> <Chuong.Nguyen(a)usa.alcatel.com>, megaco <megaco(a)fore.com>
> cc: (bcc: Petros N. Mouchtaris/Telcordia)
> Subject: RE: IP Type of Service
>
> I'll look into this. I agree.
>
> Brian
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Tuesday, May 08, 2001 10:07 AM
> To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen'; megaco
> Subject: RE: IP Type of Service
>
> That makes sense.
>
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Tuesday, May 08, 2001 10:08 AM
> To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong Nguyen';
> megaco
> Subject: RE: IP Type of Service
>
> Hi All,
> Another suggestion. Why cant the SDP be extended to incorporate a TOS
> parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that use SDP
> need not define extra properties/parameter for supporting this.
>
> Regards
> Madhubabu
>
> -----Original Message-----
> From: owner-megaco(a)pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> Sent: Tuesday, May 08, 2001 9:24 AM
> To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen';
> megaco(a)fore.com
> Subject: RE: IP Type of Service
>
> I don't agree. The TOS for a particular stream should be set on that
> stream, not
> on the MG as a whole. For example, if I have a multimedia MG, I will want
> to set
> the priority of voice higher than video, and video higher than normal. If
> I
> implement a
> Multilevel Pre-emption and Priority scheme, some calls will have higher
> priority than
> others. The TOS/frame priority has to be per stream.
>
> Brian
>
> -----Original Message-----
> From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Tuesday, May 08, 2001 9:24 AM
> To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco(a)fore.com
> Subject: RE: IP Type of Service
>
> Hi All,
>
> The default TOS type should be defined on the ROOT termination for the
> default TOS used for all media packets generated from the MG. There should
> be a method (might be through some property) of specifying stream level TOS
> bits.
>
> I'm interested to work on RSVP.
>
> Regards
> Madhubabu
>
> -----Original Message-----
> From: owner-megaco(a)pit.comms.marconi.com
> [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian
> Sent: Tuesday, May 08, 2001 8:10 AM
> To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco(a)fore.com'
> Subject: RE: IP Type of Service
>
> TOS should not be ignored at the edge router if the router is configured to
> enable DiffServ.
>
> It would be pretty simple to create one package that had the appropriate
> controls for
> DiffServ and 802.1p. RSVP needs it's own package because there is
> messaging,
> and you at least an event or two
>
> The former could be an enumeration: QosMarking, that had values None, TOS
> and
> FramePriority, plus another integer, Value. That would suffice I think,
> although you
> could conceivably get more clever with DiffServ.
>
> Shall I write something up along those lines?
>
> RSVP takes some more work. Any volunteers?
>
> Brian
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Monday, May 07, 2001 9:15 PM
> To: 'Chuong Nguyen'; 'megaco(a)fore.com'
> Subject: RE: IP Type of Service
>
> No such package has yet been defined.
>
> Various QOS architectures can be imagined. Each would give rise to its own
> package, since the MGC-MG information flow would differ from one
> architecture to the next. One question: unless the MG is itself the edge
> router, won't the ToS be ignored when the media packets reach the latter?
>
> -----Original Message-----
> From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com]
> Sent: Monday, May 07, 2001 5:14 PM
> To: 'megaco(a)fore.com'
> Subject: IP Type of Service
>
> All
>
> In MGCP, MGC can specify IP Type of Service to the MG.
> Do we have an equivalent in Megaco?
>
> Is there or has anyone defined a package for IP Type of Service?
>
> Thanks
> Chuong
>
> --
>
> Alcatel USA, Inc Internet: Chuong.Nguyen(a)usa.alcatel.com
>
> 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613
>
> **** The opinions expressed are not those of Alcatel USA, Inc ****
>
> ------------------------------------------------------------------------
> Name: att1.htm
> att1.htm Type: Hypertext Markup Language (text/html)
> Encoding: base64
[View Less]
Folks,
I have received requests to bring to the attention of the H.323 community
the fact that a couple of H.323 books have recently been published. Paul
Long put together a nice page showing those books and other IP Telephony
books on Packetizer. You can find the link here:
http://www.packetizer.com/bookshelf/list.html
Happy Reading!
Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
Hi, all:
I have two problems concerning H.323 ASN.1.
1>
H.323 ASN.1 states as follows:
>>>>>>>>>
H323-UserInformation::=SEQUENCE
{
h323-uu-pdu H323-UU-PDU,
user-data SEQUENCE
{
protocol-discriminator INTEGER (0..255),
user-information OCTET STRING (SIZE(1..131)),
.....
}OPTIONAL,
....
}
<<<<<<<<<<
My question is," What's the use of "user-date" field and what its
protocol-…
[View More]discriminator field stand for? " Can anyone present me an example?
2>
The H.323 ASN.1 tells us that following the path
"H323-UserInformation>>h323-uu-pdu>>h323-message-body", we can get and set
UUIE of Q931 messages. But how can we do the same thing with RAS messages?
Or, what are the "ABSOLUTE PATH", the root, of the messages?
Thanks,
-Delphi
[View Less]
G'Day all,
I have come up with an interim version of the H.248 Implementors' Guide
Additions v5. It contains additional correction to ones reviewed at the
SG16 Launceston meeting.
It can be found at:
ftp://standard.pictel.com/avc-site/Incoming/
filenames:
TD-xxx_H248_Implementors_Additions_v5.doc
TD-xxx_H248_Implementors_Additions_v5.pdf
Please check it for correctness and that it contains the points
discussed on the list. There were also some corrections added that were
not discussed on the …
[View More]list. If you have an issue please propose a
solution giving the wording that you would like to see. As mentioned in
the introduction this document is liable to change until final approval.
v4 was my own edition and was not published to any external network/list
so please don't look for it.
Let the editor bashing begin.
Cheers, Christian
[View Less]
Also check H.323 Annex D in version 4. It has the call signaling flows.
Version 4 includes switching from voice to fax.
> -----Original Message-----
> From: chimura730(a)AINET.OKI.CO.JP [mailto:chimura730@AINET.OKI.CO.JP]
> Sent: Sunday, May 06, 2001 9:08 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: [wg5-3: 3592] H.323 annex D
>
>
> Hi, Arie
>
> The Fax call flow diagram is described on T.38 Appendix II.
>
> Best Regards,
>
> Yasubumi …
[View More]CHIMURA
> OKI Electric industry Co.,Ltd.
> e-mail: chimura730(a)oki.co.jp
> -----Original Message-----
> ·ol : Arie Rehes <rehes(a)GADLINE.COM>
> ^¶æ : ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM>
> "úZz : 13"N2OEZ20"ú OEß'O 12:54
> OE-¼ : [wg5-3: 3592] H.323 annex D
>
>
> >Hello,
> >
> >Do you know when I can see an example for Fax call flow diagram
> >
> >Thank you all.
> >
> >Arie Reches
> >Program Manager
> >Voice Systems Division, Com21
> >P.O Box 45138
> >Jerusalem 91450
> >Israel
> >
> >Tel : +972 2 541 1568
> >Fax: +972 2 586 7590
> >E-mail: areches(a)com21.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]
