May 2001 - sg16-avd - lists.packetizer.com

RTCP support in H.323
by Rex Coldren 09 May '01

09 May '01

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 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

2 1

Re: IP Type of Service
by Michael Brown 09 May '01

09 May '01

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 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

1 0

AW: How to get the heel of RAS Message.
by Horvath Ernst 09 May '01

09 May '01

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)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

1 0

Latest draft H.245
by OKUBO Sakae 09 May '01

09 May '01

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: +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

2 3

Re: IP Type of Service
by Christian Groves 09 May '01

09 May '01

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 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

1 0

H.323 Books and Others
by Paul E. Jones 09 May '01

09 May '01

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

1 0

How to get the heel of RAS Message.
by Delphi 09 May '01

09 May '01

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-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

2 2

H.248 Implementors' Guide Additions V5 Update
by Christian Groves 07 May '01

07 May '01

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 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

5 6

Re: [wg5-3: 3592] H.323 annex D
by Francois Audet 07 May '01

07 May '01

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 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 >

1 0

Re: [wg5-3: 3592] H.323 annex D
by çº Û¶ 07 May '01

07 May '01

Hi, Arie The Fax call flow diagram is described on T.38 Appendix II. Best Regards, Yasubumi 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> ú : 13N220ú ßO 12:54 ¼ : [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

1 0