January 2005 - sg16-avd - lists.packetizer.com

Contributions to the Melbourne meeting
by OKUBO Sakae 30 Jan '05

30 Jan '05

Dear WP2/16 experts, This is to remind you of the following dates: /// Registration of the document: by 23:59 UTC, 18 February 2005 /// /// Distribution of the document: by 23:59 UTC, 21 February 2005 /// The current list of registered documents can be found at the following place: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/0502_Mel.html http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/0502_Mel.xls So far AVD-2588 through AVD-2631 have been registered. You can download documents by ftp with the following URL: ftp://avguest:Avguest@ftp3.itu.int/avc-site/2005-2008/0502_Mel -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 0

RE: Proposal to support AMR codec in H.245 using RFC3267
by Venkata Nanduri 27 Jan '05

27 Jan '05

Hi, Thanks for the information. please see in line.... At 09:32 AM 1/27/2005 +0200, ari.lakaniemi(a)nokia.com wrote: >hello, > >Although the background of the issues I mentioned about the "mode-set" and >"mode-change-period" parameters is the limitations of the GSM signaling, >this is not explicitly mentioned in RFC 3267. This will be at least >somewhat clarified in the updated version. However, the point I was trying >to make is that a user that is not a gateway to GSM system should be >discouraged to set up a session with limitations in mode changes to avoid >interoperability problems. Maybe this could somehow addressed in your draft? <vnanduri> I think it will be good if the limitations about GSM signaling are mentioned in your updated draft rather than the proposal that I will be submitting which is based on RFC 3267 so that readers of RFC 3267 get that info from your updated draft. Any idea on when this latest draft mentioned below will replace RFC3267? Do you think the proposal to H.245 should be based on this latest draft now? Venkata >The problem about the "mode-change-period"'s actual meaning (i.e. is it a >sender capability or a receiver limitation) was identified only after the >RFC 3267 was published in this is not mentioned in the spec. > >We have tried to clarify these issues in the new draft revision of the >update to RFC 3267 publishded on Jan. 26 (see >http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-bis-01.txt) >Note that there are major changes only in section 8, see especially a new >parameter "mode-change-capability" and slightly changed definitions for >parameters "mode-change-period" and "mode-change-neighbor". > >br, >Ari > >-----Original Message----- >From: ext Venkata Nanduri [mailto:vnanduri@cisco.com] >Sent: 27 January, 2005 08:13 >To: Lakaniemi Ari (Nokia-NRC/Helsinki) >Cc: roni.even(a)polycom.co.il; itu-sg16(a)external.cisco.com; Hagqvist Jari >(Nokia-NRC/Tampere); vdukki(a)cisco.com >Subject: RE: Proposal to support AMR codec in H.245 using RFC3267 > > >Hi, > >Please see on line.... > >At 09:58 AM 1/26/2005 +0200, ari.lakaniemi(a)nokia.com wrote: > >hello Venkata, > >Thanks for the explanations. It seems that I was not reading thoroughly >enough since I missed the CRC and robust-sorting features incorporated >into the octetAlign parameter. > >Some furhter comments below. > >modeSet: >OK, I can see the reasoning behind the modeSet definition as it is written >in your draft. However, since absence of modeSet would mean a session >without any allowed modes, wouldn't it make sense to make this parameter >mandatory? > ><vnanduri> This parameter can be made mandatory. > > >(Note also that in RFC 3267 the parameter mode-set is introduced only to >enable connections (through a gateway) to GSM networks, which can only >support mode-sets of up to 4 AMR modes. I think in 'normal' VoIP usage the >full set of AMR modes should be supported.) > > ><vnanduri> I think RFC3267 does not mention about the restrictions >mentioned above. If so, can you please point me to the section? > > > > >modeChangePeriod: >This is also something that is defined in RFC 3267 only for interopreation >with GSM (where the signaling is limited in such a way that mode changes >are restricted to happen in 2-frame intervals). Thus, I think other values >than (1 or) 2 are not meaningful in practice. I do not know if this >document would be a right place to include an informational note about this... > >There is actually an identified problem regarding this in RFC 3267: does >the parameter mode-change-period indicate sender's capability to send >(also) using mode-change-period=2 (since the AMR _codec_ does not have >such limitation) or receiver's capability to _only_ receive using >mode-change-period=2? We are currently preapring an update for RFC 3267 >(which will be eventually published with different RFC number) to clarify >this (among some other things). > > ><vnanduri> I think RFC3267 does not mention about the restrictions >mentioned above. If so, can you please point me to the section? > >On Internet I could find ietf-avt-rtp-amr-bis-00.txt. But, that may not be >the latest. >Can you please send me the latest draft that is in progress(updated rfc3267)? > >Thanks >Venkata > > > > > >br, >Ari > > > -----Original Message----- > > From: ext Venkata Nanduri [mailto:vnanduri@cisco.com] > > Sent: 26 January, 2005 00:16 > > To: Lakaniemi Ari (Nokia-NRC/Helsinki) > > Cc: roni.even(a)polycom.co.il; itu-sg16(a)external.cisco.com; > > Hagqvist Jari > > (Nokia-NRC/Tampere) > > Subject: RE: Proposal to support AMR codec in H.245 using RFC3267 > > Importance: High > > > > > > Hi, > > > > Please see in line..... > > > > Look for vnanduri > > > > At 03:47 PM 1/25/2005 +0200, ari.lakaniemi(a)nokia.com wrote: > > >hello Venkata, > > > > > >Thanks for preparing the document. > > > > > >I have more or less the same comment as Roni Even already made: > > >There seems to be no parameters for controlling the "crc" and > > >"robust-sorting" options available in RFC 3267. Are these > > options somehow > > >problematic in the scope of H.245? > > > > > > <vnanduri> > > > > In-order to apply CRC, interleaving and robust-sorting , > > frame format shall > > be octet aligned. > > Since there is a dependency among different parameters, octetAlign > > parameter is defined in > > H245 which also handles CRC and robust-sorting. May be I need > > to rename > > this octetAlign > > parameter to something that is meaningful for octetAlign, CRC and > > robust-sorting (Any suggestions??) > > The presence of octetAlign parameter itself indicates octet > > aligned frame > > format. > > > > The octetAlign parameter is defined as booleanArray to take > > care of CRC and > > robust-sorting > > values. Bit 0 is used for CRC and Bit 1 for robust-sorting. > > > > But, interleaving can also be only applied if the frame format is > > octet-aligned and the value for > > interleaving is number of frame blocks which cannot be > > defined as part of > > booleanArray. So, a > > new parameter is defined. Interleaving parameter shall be absent if > > octetAlign parameter is absent. > > > > The main intention of consolidating the parameters is to > > minimize the bits > > that will be transmitted > > across the wire... > > > > > > >Another question is about the definition of the capability > > parameter modeSet. > > >Currently the draft specifies that > > > > > > "... If present, specifies the subset of modes available > > for current > > > session. If absent, no modes are supported." > > > > > >However, in RFC 3267 the definition of the corresponding > > MIME parameter says > > > "... If not present, all codec modes are allowed for the session." > > > > > >Maybe it would be clearer to use the same interpretation as > > in RFC 3267 in > > >case the paramter modeSet is not present? > > > > > > <vnanduri> > > > > For some of the parameters defined in RFC3267, similar parameters are > > defined with a different interpretation in H.245 > > to take care of conference scenarios. > > > > Please look below for details about why they are defined > > differently in H.245: > > > > > > 1) octet-align(SDP) -------->octetAlign--booleanArray (also > > accommodates > > crc and robust-sorting)(H.245) > > > > described above > > > > 2) mode-set(SDP) ---------->modeSet and modeSetExtended. > > modeSetExtended is > > used only AMR-WB(H245) > > > > modeSet is defined as booleanArray which can accommodate only > > 8 boolean > > values. Since AMR-NB has only > > 8 bit rates, modeSet parameter will be sufficient for AMR-NB. > > How ever, > > since AMR-WB has 9 modes, first > > 8 modes will be accommodated in modeSet parameter and 9th > > mode will be > > accommodated in > > modeSetExtended parameter. > > > > Suppose an MC that is not aware of AMR codec capability, gets this > > capability from three endpoints A, B and C > > and wants to create a common capability description. Suppose > > A sends no > > modeSet, B sends a modeSet with > > 10000011 and C sends a modeSet with 10000001. Now, a common > > capability > > description should contain the > > modeSet as 10000001. But the MC has to ignore those > > parameters that are not > > supported by all endpoints. > > > > So the MC will send out a cap description without a modeSet, > > which will > > imply support for all modes, which is not > > the expected behavior. So, absence of this parameter is > > defined as lack of > > support of any modes. > > > > The same comment applies for modeSetExtended - the absence of > > the parameter > > should indicate lack of support for > > the 9th mode, and this parameter should be present if the > > 9th mode is > > supported. > > > > 3) mode-change-period(SDP) ----->modeChangePeriod(H245). > > > > For modeChangePeriod, for example, if A sent a period of 5, B > > sent 3 and C > > did not > > send anything, the common cap description prepared by the MC > > will not contain a > > modeChangePeriod. So A, which could only change modes once in > > 5 frames will > > now receive audio that may changes mode at every frame which > > is not the > > expected > > behavior. Hence, this parameter is made mandatory and is > > defined as unsignedMax > > which indicates to MC that it has to select the largest value > > it receives > > from different > > end points. With this definition in H.245 Now, C has to > > send 0 as the value, > > and MC will select 5 which is the appropriate value. > > > > 4) mode-change-neighbor(SDP) -----> modeChangeAll(H245) > > > > For example, if A did not send, B sent with value 1, C sent > > value of 0, > > > > Again, an MC that does not include the value because one > > endpoint did not > > include. > > It will be creating a common capability description that indicates > > permission to > > switch to any mode(absence of param from A or a value 0 from > > C). Again > > this is not > > the expected behavior. > > > > So, this parameter is defined as 'ModeChangeAll'. The > > presence of this > > parameter > > means 'change from any to any mode is permitted'. Then if a > > combining MC > > creates > > a cap description that does not have ModeChangeAll (because > > one endpoint > > did not send it), > > it will be correctly forcing all endpoints to the common > > subset which is > > change to neighboring > > modes only is permitted'. > > > > > > 5) maxptime(SDP) ----------> alAduFrames(H.245) > > 6) ptime(DSP)-------> alAduFrames(H245) > > > > numFrames parameter will correspond to the value for maxptime > > when used in > > TCS messages and will correspond to value for ptime when used > > in OLC and MR > > messages. > > > > 7) crc(SDP) -----------> octetAlign(H.245) > > > > described above > > > > 8) robust-sorting(SDP) ------> octetAlign(H.245) > > > > described above > > > > 9) interleaving(SDP) -----> interleaving(H.245) > > > > described above > > > > 10) channels(SDP) -----> numChannels(H245) > > > > Same as SDP > > > > Please let me know if you have any other questions... > > > > Thanks > > Venkata > > > > > > >BR, > > >Ari Lakaniemi > > >Nokia Research Center > > > > > > > -----Original Message----- > > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > > Sent: 25 January, 2005 10:10 > > > > To: Venkata Nanduri; itu-sg16(a)external.cisco.com; Lakaniemi Ari > > > > (Nokia-NRC/Helsinki) > > > > Subject: RE: Proposal to support AMR codec in H.245 using RFC3267 > > > > > > > > > > > > Hi, > > > > I just scanned through the draft. I noticed that there is no full > > > > mapping of the SDP parameters from RFC3267 to generic > > parameters. Is > > > > there a reason for the difference. > > > > I think that there should be some text that will explain the > > > > relationship to H.245 annex I. > > > > Roni Even > > > > > > > > -----Original Message----- > > > > From: Venkata Nanduri [mailto:vnanduri@cisco.com] > > > > Sent: Tuesday, January 25, 2005 12:33 AM > > > > To: itu-sg16(a)external.cisco.com; ari.lakaniemi(a)NOKIA.COM > > > > Cc: vnanduri(a)cisco.com > > > > Subject: Proposal to support AMR codec in H.245 using RFC3267 > > > > > > > > Dear SG16 experts, > > > > > > > > I would like the attached proposal to be submitted to > > next meeting of > > > > SG16 > > > > group to be held at > > > > Melbourne in February last week, 2005. > > > > > > > > Before I submit the proposal formally, I would like to > > get some early > > > > feedback on the proposal > > > > from experts in the group. > > > > > > > > Can you please review the document and let me know your comments? > > > > > > > > Thanks > > > > Venkata > > > > > >

1 0

RE: Proposal to support AMR codec in H.245 using RFC3267
by Venkata Nanduri 27 Jan '05

27 Jan '05

Hi, Please see on line.... At 09:58 AM 1/26/2005 +0200, ari.lakaniemi(a)nokia.com wrote: hello Venkata, Thanks for the explanations. It seems that I was not reading thoroughly enough since I missed the CRC and robust-sorting features incorporated into the octetAlign parameter. Some furhter comments below. modeSet: OK, I can see the reasoning behind the modeSet definition as it is written in your draft. However, since absence of modeSet would mean a session without any allowed modes, wouldn't it make sense to make this parameter mandatory? <vnanduri> This parameter can be made mandatory. (Note also that in RFC 3267 the parameter mode-set is introduced only to enable connections (through a gateway) to GSM networks, which can only support mode-sets of up to 4 AMR modes. I think in 'normal' VoIP usage the full set of AMR modes should be supported.) <vnanduri> I think RFC3267 does not mention about the restrictions mentioned above. If so, can you please point me to the section? modeChangePeriod: This is also something that is defined in RFC 3267 only for interopreation with GSM (where the signaling is limited in such a way that mode changes are restricted to happen in 2-frame intervals). Thus, I think other values than (1 or) 2 are not meaningful in practice. I do not know if this document would be a right place to include an informational note about this... There is actually an identified problem regarding this in RFC 3267: does the parameter mode-change-period indicate sender's capability to send (also) using mode-change-period=2 (since the AMR _codec_ does not have such limitation) or receiver's capability to _only_ receive using mode-change-period=2? We are currently preapring an update for RFC 3267 (which will be eventually published with different RFC number) to clarify this (among some other things). <vnanduri> I think RFC3267 does not mention about the restrictions mentioned above. If so, can you please point me to the section? On Internet I could find ietf-avt-rtp-amr-bis-00.txt. But, that may not be the latest. Can you please send me the latest draft that is in progress(updated rfc3267)? Thanks Venkata br, Ari > -----Original Message----- > From: ext Venkata Nanduri [mailto:vnanduri@cisco.com] > Sent: 26 January, 2005 00:16 > To: Lakaniemi Ari (Nokia-NRC/Helsinki) > Cc: roni.even(a)polycom.co.il; itu-sg16(a)external.cisco.com; > Hagqvist Jari > (Nokia-NRC/Tampere) > Subject: RE: Proposal to support AMR codec in H.245 using RFC3267 > Importance: High > > > Hi, > > Please see in line..... > > Look for vnanduri > > At 03:47 PM 1/25/2005 +0200, ari.lakaniemi(a)nokia.com wrote: > >hello Venkata, > > > >Thanks for preparing the document. > > > >I have more or less the same comment as Roni Even already made: > >There seems to be no parameters for controlling the "crc" and > >"robust-sorting" options available in RFC 3267. Are these > options somehow > >problematic in the scope of H.245? > > > <vnanduri> > > In-order to apply CRC, interleaving and robust-sorting , > frame format shall > be octet aligned. > Since there is a dependency among different parameters, octetAlign > parameter is defined in > H245 which also handles CRC and robust-sorting. May be I need > to rename > this octetAlign > parameter to something that is meaningful for octetAlign, CRC and > robust-sorting (Any suggestions??) > The presence of octetAlign parameter itself indicates octet > aligned frame > format. > > The octetAlign parameter is defined as booleanArray to take > care of CRC and > robust-sorting > values. Bit 0 is used for CRC and Bit 1 for robust-sorting. > > But, interleaving can also be only applied if the frame format is > octet-aligned and the value for > interleaving is number of frame blocks which cannot be > defined as part of > booleanArray. So, a > new parameter is defined. Interleaving parameter shall be absent if > octetAlign parameter is absent. > > The main intention of consolidating the parameters is to > minimize the bits > that will be transmitted > across the wire... > > > >Another question is about the definition of the capability > parameter modeSet. > >Currently the draft specifies that > > > > "... If present, specifies the subset of modes available > for current > > session. If absent, no modes are supported." > > > >However, in RFC 3267 the definition of the corresponding > MIME parameter says > > "... If not present, all codec modes are allowed for the session." > > > >Maybe it would be clearer to use the same interpretation as > in RFC 3267 in > >case the paramter modeSet is not present? > > > <vnanduri> > > For some of the parameters defined in RFC3267, similar parameters are > defined with a different interpretation in H.245 > to take care of conference scenarios. > > Please look below for details about why they are defined > differently in H.245: > > > 1) octet-align(SDP) -------->octetAlign--booleanArray (also > accommodates > crc and robust-sorting)(H.245) > > described above > > 2) mode-set(SDP) ---------->modeSet and modeSetExtended. > modeSetExtended is > used only AMR-WB(H245) > > modeSet is defined as booleanArray which can accommodate only > 8 boolean > values. Since AMR-NB has only > 8 bit rates, modeSet parameter will be sufficient for AMR-NB. > How ever, > since AMR-WB has 9 modes, first > 8 modes will be accommodated in modeSet parameter and 9th > mode will be > accommodated in > modeSetExtended parameter. > > Suppose an MC that is not aware of AMR codec capability, gets this > capability from three endpoints A, B and C > and wants to create a common capability description. Suppose > A sends no > modeSet, B sends a modeSet with > 10000011 and C sends a modeSet with 10000001. Now, a common > capability > description should contain the > modeSet as 10000001. But the MC has to ignore those > parameters that are not > supported by all endpoints. > > So the MC will send out a cap description without a modeSet, > which will > imply support for all modes, which is not > the expected behavior. So, absence of this parameter is > defined as lack of > support of any modes. > > The same comment applies for modeSetExtended - the absence of > the parameter > should indicate lack of support for > the 9th mode, and this parameter should be present if the > 9th mode is > supported. > > 3) mode-change-period(SDP) ----->modeChangePeriod(H245). > > For modeChangePeriod, for example, if A sent a period of 5, B > sent 3 and C > did not > send anything, the common cap description prepared by the MC > will not contain a > modeChangePeriod. So A, which could only change modes once in > 5 frames will > now receive audio that may changes mode at every frame which > is not the > expected > behavior. Hence, this parameter is made mandatory and is > defined as unsignedMax > which indicates to MC that it has to select the largest value > it receives > from different > end points. With this definition in H.245 Now, C has to > send 0 as the value, > and MC will select 5 which is the appropriate value. > > 4) mode-change-neighbor(SDP) -----> modeChangeAll(H245) > > For example, if A did not send, B sent with value 1, C sent > value of 0, > > Again, an MC that does not include the value because one > endpoint did not > include. > It will be creating a common capability description that indicates > permission to > switch to any mode(absence of param from A or a value 0 from > C). Again > this is not > the expected behavior. > > So, this parameter is defined as 'ModeChangeAll'. The > presence of this > parameter > means 'change from any to any mode is permitted'. Then if a > combining MC > creates > a cap description that does not have ModeChangeAll (because > one endpoint > did not send it), > it will be correctly forcing all endpoints to the common > subset which is > change to neighboring > modes only is permitted'. > > > 5) maxptime(SDP) ----------> alAduFrames(H.245) > 6) ptime(DSP)-------> alAduFrames(H245) > > numFrames parameter will correspond to the value for maxptime > when used in > TCS messages and will correspond to value for ptime when used > in OLC and MR > messages. > > 7) crc(SDP) -----------> octetAlign(H.245) > > described above > > 8) robust-sorting(SDP) ------> octetAlign(H.245) > > described above > > 9) interleaving(SDP) -----> interleaving(H.245) > > described above > > 10) channels(SDP) -----> numChannels(H245) > > Same as SDP > > Please let me know if you have any other questions... > > Thanks > Venkata > > > >BR, > >Ari Lakaniemi > >Nokia Research Center > > > > > -----Original Message----- > > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > > Sent: 25 January, 2005 10:10 > > > To: Venkata Nanduri; itu-sg16(a)external.cisco.com; Lakaniemi Ari > > > (Nokia-NRC/Helsinki) > > > Subject: RE: Proposal to support AMR codec in H.245 using RFC3267 > > > > > > > > > Hi, > > > I just scanned through the draft. I noticed that there is no full > > > mapping of the SDP parameters from RFC3267 to generic > parameters. Is > > > there a reason for the difference. > > > I think that there should be some text that will explain the > > > relationship to H.245 annex I. > > > Roni Even > > > > > > -----Original Message----- > > > From: Venkata Nanduri [mailto:vnanduri@cisco.com] > > > Sent: Tuesday, January 25, 2005 12:33 AM > > > To: itu-sg16(a)external.cisco.com; ari.lakaniemi(a)NOKIA.COM > > > Cc: vnanduri(a)cisco.com > > > Subject: Proposal to support AMR codec in H.245 using RFC3267 > > > > > > Dear SG16 experts, > > > > > > I would like the attached proposal to be submitted to > next meeting of > > > SG16 > > > group to be held at > > > Melbourne in February last week, 2005. > > > > > > Before I submit the proposal formally, I would like to > get some early > > > feedback on the proposal > > > from experts in the group. > > > > > > Can you please review the document and let me know your comments? > > > > > > Thanks > > > Venkata > > > >

1 0

RE: Proposal to support AMR codec in H.245 using RFC3267
by simao.campos＠ITU.INT 26 Jan '05

26 Jan '05

All, I think that it would be too confusing to have two annexes dealing with the same coding. I suggest that Annex I be revised, even if it means a total rewriting of it. Just consider whether the previous definitions should be maintained as a matter of backward compatibility with existing systems. Best regards, Simao > -----Original Message----- > From: Venkata Nanduri [mailto:vnanduri@cisco.com] > Sent: 26 January 2005 03:04 > To: Dave Lindbergh > Cc: itu-sg16(a)external.cisco.com; ari.lakaniemi(a)NOKIA.COM > Subject: Re: Proposal to support AMR codec in H.245 using RFC3267 > > Hi, > > I think existing Annex - I in H.245 is written much before > RFC3267 is written and hence it out of sync in content. > > The RTP format mentioned in Annex - I is different from what > is mentioned in RFC3267. > > Even if we want to incorporate this material in existing > Annex - I, it will be like replacing the entire Annex - I > content with the new content.. > > Thanks > Venkata > > > At 07:50 PM 1/25/2005 -0500, Dave Lindbergh wrote: > >Is there a reason why this needs to be a separate Annex to > H.245? I'd > >prefer to incorporate this material into an existing Annex, just to > >reduce the amount of clutter in H.245. > > > >--Dave > > > >At 05:32 PM 1/24/2005, Venkata Nanduri wrote: > >>Dear SG16 experts, > >> > >>I would like the attached proposal to be submitted to next > meeting of > >>SG16 group to be held at > >>Melbourne in February last week, 2005. > >> > >>Before I submit the proposal formally, I would like to get > some early > >>feedback on the proposal from experts in the group. > >> > >>Can you please review the document and let me know your comments? > >> > >>Thanks > >>Venkata > > > >---------- > >Dave Lindbergh > >Polycom, Inc. > >100 Minuteman Road > >Andover MA 01810 USA > >Voice: +1 978 292 5366 > >Email: lindbergh(a)92F1.com > >H.320, H.323 video by arrangement >

1 0

Re: Proposal to support AMR codec in H.245 using RFC3267
by Venkata Nanduri 25 Jan '05

25 Jan '05

Hi, I think existing Annex - I in H.245 is written much before RFC3267 is written and hence it out of sync in content. The RTP format mentioned in Annex - I is different from what is mentioned in RFC3267. Even if we want to incorporate this material in existing Annex - I, it will be like replacing the entire Annex - I content with the new content.. Thanks Venkata At 07:50 PM 1/25/2005 -0500, Dave Lindbergh wrote: >Is there a reason why this needs to be a separate Annex to H.245? I'd >prefer to incorporate this material into an existing Annex, just to reduce >the amount of clutter in H.245. > >--Dave > >At 05:32 PM 1/24/2005, Venkata Nanduri wrote: >>Dear SG16 experts, >> >>I would like the attached proposal to be submitted to next meeting of >>SG16 group to be held at >>Melbourne in February last week, 2005. >> >>Before I submit the proposal formally, I would like to get some early >>feedback on the proposal >>from experts in the group. >> >>Can you please review the document and let me know your comments? >> >>Thanks >>Venkata > >---------- >Dave Lindbergh >Polycom, Inc. >100 Minuteman Road >Andover MA 01810 USA >Voice: +1 978 292 5366 >Email: lindbergh(a)92F1.com >H.320, H.323 video by arrangement

1 0

Re: Proposal to support AMR codec in H.245 using RFC3267
by Dave Lindbergh 25 Jan '05

25 Jan '05

Is there a reason why this needs to be a separate Annex to H.245? I'd prefer to incorporate this material into an existing Annex, just to reduce the amount of clutter in H.245. --Dave At 05:32 PM 1/24/2005, Venkata Nanduri wrote: >Dear SG16 experts, > >I would like the attached proposal to be submitted to next meeting of SG16 >group to be held at >Melbourne in February last week, 2005. > >Before I submit the proposal formally, I would like to get some early >feedback on the proposal >from experts in the group. > >Can you please review the document and let me know your comments? > >Thanks >Venkata ---------- Dave Lindbergh Polycom, Inc. 100 Minuteman Road Andover MA 01810 USA Voice: +1 978 292 5366 Email: lindbergh(a)92F1.com H.320, H.323 video by arrangement

1 0

RE: Proposal to support AMR codec in H.245 using RFC3267
by Venkata Nanduri 25 Jan '05

25 Jan '05

Hi, Please see in line..... Look for vnanduri At 03:47 PM 1/25/2005 +0200, ari.lakaniemi(a)nokia.com wrote: >hello Venkata, > >Thanks for preparing the document. > >I have more or less the same comment as Roni Even already made: >There seems to be no parameters for controlling the "crc" and >"robust-sorting" options available in RFC 3267. Are these options somehow >problematic in the scope of H.245? <vnanduri> In-order to apply CRC, interleaving and robust-sorting , frame format shall be octet aligned. Since there is a dependency among different parameters, octetAlign parameter is defined in H245 which also handles CRC and robust-sorting. May be I need to rename this octetAlign parameter to something that is meaningful for octetAlign, CRC and robust-sorting (Any suggestions??) The presence of octetAlign parameter itself indicates octet aligned frame format. The octetAlign parameter is defined as booleanArray to take care of CRC and robust-sorting values. Bit 0 is used for CRC and Bit 1 for robust-sorting. But, interleaving can also be only applied if the frame format is octet-aligned and the value for interleaving is number of frame blocks which cannot be defined as part of booleanArray. So, a new parameter is defined. Interleaving parameter shall be absent if octetAlign parameter is absent. The main intention of consolidating the parameters is to minimize the bits that will be transmitted across the wire... >Another question is about the definition of the capability parameter modeSet. >Currently the draft specifies that > > "... If present, specifies the subset of modes available for current > session. If absent, no modes are supported." > >However, in RFC 3267 the definition of the corresponding MIME parameter says > "... If not present, all codec modes are allowed for the session." > >Maybe it would be clearer to use the same interpretation as in RFC 3267 in >case the paramter modeSet is not present? <vnanduri> For some of the parameters defined in RFC3267, similar parameters are defined with a different interpretation in H.245 to take care of conference scenarios. Please look below for details about why they are defined differently in H.245: 1) octet-align(SDP) -------->octetAlign--booleanArray (also accommodates crc and robust-sorting)(H.245) described above 2) mode-set(SDP) ---------->modeSet and modeSetExtended. modeSetExtended is used only AMR-WB(H245) modeSet is defined as booleanArray which can accommodate only 8 boolean values. Since AMR-NB has only 8 bit rates, modeSet parameter will be sufficient for AMR-NB. How ever, since AMR-WB has 9 modes, first 8 modes will be accommodated in modeSet parameter and 9th mode will be accommodated in modeSetExtended parameter. Suppose an MC that is not aware of AMR codec capability, gets this capability from three endpoints A, B and C and wants to create a common capability description. Suppose A sends no modeSet, B sends a modeSet with 10000011 and C sends a modeSet with 10000001. Now, a common capability description should contain the modeSet as 10000001. But the MC has to ignore those parameters that are not supported by all endpoints. So the MC will send out a cap description without a modeSet, which will imply support for all modes, which is not the expected behavior. So, absence of this parameter is defined as lack of support of any modes. The same comment applies for modeSetExtended - the absence of the parameter should indicate lack of support for the 9th mode, and this parameter should be present if the 9th mode is supported. 3) mode-change-period(SDP) ----->modeChangePeriod(H245). For modeChangePeriod, for example, if A sent a period of 5, B sent 3 and C did not send anything, the common cap description prepared by the MC will not contain a modeChangePeriod. So A, which could only change modes once in 5 frames will now receive audio that may changes mode at every frame which is not the expected behavior. Hence, this parameter is made mandatory and is defined as unsignedMax which indicates to MC that it has to select the largest value it receives from different end points. With this definition in H.245 Now, C has to send 0 as the value, and MC will select 5 which is the appropriate value. 4) mode-change-neighbor(SDP) -----> modeChangeAll(H245) For example, if A did not send, B sent with value 1, C sent value of 0, Again, an MC that does not include the value because one endpoint did not include. It will be creating a common capability description that indicates permission to switch to any mode(absence of param from A or a value 0 from C). Again this is not the expected behavior. So, this parameter is defined as 'ModeChangeAll'. The presence of this parameter means 'change from any to any mode is permitted'. Then if a combining MC creates a cap description that does not have ModeChangeAll (because one endpoint did not send it), it will be correctly forcing all endpoints to the common subset which is change to neighboring modes only is permitted'. 5) maxptime(SDP) ----------> alAduFrames(H.245) 6) ptime(DSP)-------> alAduFrames(H245) numFrames parameter will correspond to the value for maxptime when used in TCS messages and will correspond to value for ptime when used in OLC and MR messages. 7) crc(SDP) -----------> octetAlign(H.245) described above 8) robust-sorting(SDP) ------> octetAlign(H.245) described above 9) interleaving(SDP) -----> interleaving(H.245) described above 10) channels(SDP) -----> numChannels(H245) Same as SDP Please let me know if you have any other questions... Thanks Venkata >BR, >Ari Lakaniemi >Nokia Research Center > > > -----Original Message----- > > From: ext Even, Roni [mailto:roni.even@polycom.co.il] > > Sent: 25 January, 2005 10:10 > > To: Venkata Nanduri; itu-sg16(a)external.cisco.com; Lakaniemi Ari > > (Nokia-NRC/Helsinki) > > Subject: RE: Proposal to support AMR codec in H.245 using RFC3267 > > > > > > Hi, > > I just scanned through the draft. I noticed that there is no full > > mapping of the SDP parameters from RFC3267 to generic parameters. Is > > there a reason for the difference. > > I think that there should be some text that will explain the > > relationship to H.245 annex I. > > Roni Even > > > > -----Original Message----- > > From: Venkata Nanduri [mailto:vnanduri@cisco.com] > > Sent: Tuesday, January 25, 2005 12:33 AM > > To: itu-sg16(a)external.cisco.com; ari.lakaniemi(a)NOKIA.COM > > Cc: vnanduri(a)cisco.com > > Subject: Proposal to support AMR codec in H.245 using RFC3267 > > > > Dear SG16 experts, > > > > I would like the attached proposal to be submitted to next meeting of > > SG16 > > group to be held at > > Melbourne in February last week, 2005. > > > > Before I submit the proposal formally, I would like to get some early > > feedback on the proposal > > from experts in the group. > > > > Can you please review the document and let me know your comments? > > > > Thanks > > Venkata > >

1 0

RE: Proposal to support AMR codec in H.245 using RFC3267
by Even, Roni 25 Jan '05

25 Jan '05

Hi, I just scanned through the draft. I noticed that there is no full mapping of the SDP parameters from RFC3267 to generic parameters. Is there a reason for the difference. I think that there should be some text that will explain the relationship to H.245 annex I. Roni Even -----Original Message----- From: Venkata Nanduri [mailto:vnanduri@cisco.com] Sent: Tuesday, January 25, 2005 12:33 AM To: itu-sg16(a)external.cisco.com; ari.lakaniemi(a)NOKIA.COM Cc: vnanduri(a)cisco.com Subject: Proposal to support AMR codec in H.245 using RFC3267 Dear SG16 experts, I would like the attached proposal to be submitted to next meeting of SG16 group to be held at Melbourne in February last week, 2005. Before I submit the proposal formally, I would like to get some early feedback on the proposal from experts in the group. Can you please review the document and let me know your comments? Thanks Venkata

1 0

Proposal to support AMR codec in H.245 using RFC3267
by Venkata Nanduri 24 Jan '05

24 Jan '05

Dear SG16 experts, I would like the attached proposal to be submitted to next meeting of SG16 group to be held at Melbourne in February last week, 2005. Before I submit the proposal formally, I would like to get some early feedback on the proposal from experts in the group. Can you please review the document and let me know your comments? Thanks Venkata

1 0

Meeting Announcement Joined session Q.29/16 with SG19 in Melbour
by Leo.Lehmann＠bakom.admin.ch 24 Jan '05

24 Jan '05

Dear experts and colleagues, I have the pleasure to announce a joined session of Q.29/16 together with SG19 during our WP2 Rapporteuer Meeting in Melbourne. SG19 will held an Rapporteuer meeting from March 1st until March 3rd 2005 also in Melbourne. This givese a good opportunity for the exchange and handling of questions on mobility of SG16 and SG19. Unfortunally SG16/WP2 and SG19 uses different meeting locations in Melbourne, which are about 2 hours driving time away from each other. So far one joined session is planned on morning March 1st at SG19 meeting place with WP2 participants , the other on March 2nd at WP2/16 meeting place with SG16 participants. Topics for this joined meeting will be so far - Consolidation of Mobility definitions - new Revision of Technical report on combined mobility betewwen H.323 systems and GPRS/UMTS networks - Further issues Regarding the first both items I am expecting two contributions until beginning of February. If you would like to send further contributions for this Session, please do not hesitate to bring them up until February 12th 2005. If you are interested to participate in the session at the SG19 meeting place, please send the attached registration to 'Leslie.Graf(a)ericsson.com'and please let me also know for information. Best regards Leo Leo Lehmann Rapporteur Q.29/16 Federal Office of Communication (OFCOM) Biel-Bienne Switzerland Tel: +41 32 327 5752 __________________________________________________________________________ __ ___________________________________________________ Dear Mr. Lehmann, At 11:45 +0100 05/01/24, Leo.Lehmann(a)bakom.admin.ch wrote: >I had a telefon conversation with Mr Probst. As this is a good >opportunity for Questions on mobility of SG16 and >SG19 to meet, Mr Probst fully support an additional setting of a >Q.29/16 meeting in Melbourne to enable a joined session with SG19 >qusetions. Thank you very much. Please publicize the Melbourne sessions on mobility through the mailing list. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** Dear Mr Okubo, I had a telefon conversation with Mr Probst. As this is a good opportunity for Questions on mobility of SG16 and SG19 to meet, Mr Probst fully support an additional setting of a Q.29/16 meeting in Melbourne to enable a joined session with SG19 qusetions. Best regards Leo -----Ursprüngliche Nachricht----- Von: OKUBO Sakae [mailto:okubo@mxz.mesh.ne.jp] Gesendet: Sonntag, 23. Januar 2005 17:57 An: Lehmann Leo Cc: Simao Campos-Neto Betreff: Fwd:Re: Fwd:Q.29 interim meeting/joint meeting with SG19 Dear Mr. Lehmann, I have received the following auto-reply to my message seeking his agreement. Could you please kindly get in touch with him via the advised mobile phone and convey our request? It would be too late if we start after 30 March. >From: probst-pa(a)bluewin.ch >Subject: Re: Fwd:Q.29 interim meeting/joint meeting with SG19 >To: okubo(a)mxz.mesh.ne.jp >Date: Sun, 23 Jan 2005 16:43:56 +0000 >Delivered-To: probst-pa(a)bluewin.ch >X-Biglobe-VirusCheck: Mon, 24 Jan 2005 01:43:59 +0900 > >Thank you very much for your message. >I am away from my office for two weeks and will process your mail only >later (30.1.2005). For urgent issues, you have the possibility to reach >me on my mobile >phone: +41 79 229 96 56. > >Best regards, > >P.A.Probst -----Ursprüngliche Nachricht----- Von: OKUBO Sakae [mailto:okubo@mxz.mesh.ne.jp] Gesendet: Sonntag, 23. Januar 2005 17:44 An: Pierre-Andre PROBST Cc: Istvan Sebestyen; Simao Campos-Neto; Lehmann Leo; Christian Groves Betreff: Fwd:Q.29 interim meeting/joint meeting with SG19 Dear Mr. Probst, This is to seek your agreement on that Q.29 will meet in Melbourne early March as requested by Mr. Lehmann. Strictly speaking, the WP2/16 report of last SG16 meeting says that Q.29 will meet only in May and the current SG16 web page <http://www.itu.int/ITU-T/studygroups/com16/meetings.html> also indicates so. As this is a good opportunity for Questions on mobility of SG16 and SG19 to meet, I hope you could accept this additional setting. Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** -----Ursprüngliche Nachricht----- Von: John Visser [mailto:jvisser@nortelnetworks.com] Gesendet: Mittwoch, 19. Januar 2005 16:56 An: David.Mcfarlane(a)nokia.com; 'Farrokh Khatibi'; 'Felix,Zhang'; 'leo.lehmann(a)bakom.admin.ch' Cc: peter.m.adams(a)bt.com; Leslie Graf; tatiana.kurakova(a)itu.int Betreff: RE: documents for joint rapporteurs meeting Colleagues: I think everyone is aware of Q.29/16 "Mobility for Multimedia Systems and Services" http://www.itu.int/ITU-T/studygroups/com16/sg16-q29. Leo Lehman is the Rapporteur and he and I have had several discussions on how best to coordinate our mobility studies. Q.2 and 5/19 and Q.6/13 are meeting jointly in Melbourne 1-3 March. Q.29/16 is meeting in Marysville the week of 28 Feb. Marysville is about 2 hours drive outside Melbourne. In my discussions with Leo, we addressed how best to coordinate our work and we came up with the following proposal: Tuesday, 1 March, Leo (and possibly others) would come to Melbourne for the afternoon to take part in the Q.2 and 5/19 and Q.6/13 joint discussions. The objective would be to identify mobility-related definitions and terminology and work towards alignment so that these would be common across all mobility discussions. I anticipate that Leo would also be willing to provide an overview of the Work of Q.5/16 in the previous study period, and the current work anticipated in Q.29/16. Wednesday, 2 March, I (and possibly others) would go to Marysville to sit in on the Q.29/16 discussions. The objective would be to support alignment on mobility-related definitions and terminology from the previous day. I anticipate that I would also provide an overview of the work of Q.2 and 5/19 and Q.6/13. I would appreciate any comments and concerns from you prior to formalizing this further (though we don't want to get very formal at a rapporteurs' meeting.) Regards, John John Visser, P.Eng. Chairman, ITU-T SG 19 "Mobile Telecommunication Networks" http://www.itu.int/ITU-T/studygroups/com19 Phone: +1-613-763-7028 Fax: +1-613-763-2697 Mobile: +1-613-276-6096 Email: jvisser(a)nortel.com

1 0

Meeting Announcement Joined session Q.29/16 with SG19 in Melbourne
by Leo.Lehmann＠bakom.admin.ch 24 Jan '05

24 Jan '05

Dear experts and colleagues, I have the pleasure to announce a joined session of Q.29/16 together with SG19 during our WP2 Rapporteuer Meeting in Melbourne. SG19 will held an Rapporteuer meeting from March 1st until March 3rd 2005 also in Melbourne. This givese a good opportunity for the exchange and handling of questions on mobility of SG16 and SG19. Unfortunally SG16/WP2 and SG19 uses different meeting locations in Melbourne, which are about 2 hours driving time away from each other. So far one joined session is planned on morning March 1st at SG19 meeting place with WP2 participants , the other on March 2nd at WP2/16 meeting place with SG16 participants. Topics for this joined meeting will be so far - Consolidation of Mobility definitions - new Revision of Technical report on combined mobility betewwen H.323 systems and GPRS/UMTS networks - Further issues Regarding the first both items I am expecting two contributions until beginning of February. If you would like to send further contributions for this Session, please do not hesitate to bring them up until February 12th 2005. If you are interested to participate in the session at the SG19 meeting place, please send the attached registration to 'Leslie.Graf(a)ericsson.com'and please let me also know for information. Best regards Leo Leo Lehmann Rapporteur Q.29/16 Federal Office of Communication (OFCOM) Biel-Bienne Switzerland Tel: +41 32 327 5752 __________________________________________________________________________ __ ___________________________________________________ Dear Mr. Lehmann, At 11:45 +0100 05/01/24, Leo.Lehmann(a)bakom.admin.ch wrote: >I had a telefon conversation with Mr Probst. As this is a good >opportunity for Questions on mobility of SG16 and >SG19 to meet, Mr Probst fully support an additional setting of a >Q.29/16 meeting in Melbourne to enable a joined session with SG19 >qusetions. Thank you very much. Please publicize the Melbourne sessions on mobility through the mailing list. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** Dear Mr Okubo, I had a telefon conversation with Mr Probst. As this is a good opportunity for Questions on mobility of SG16 and SG19 to meet, Mr Probst fully support an additional setting of a Q.29/16 meeting in Melbourne to enable a joined session with SG19 qusetions. Best regards Leo -----Ursprüngliche Nachricht----- Von: OKUBO Sakae [mailto:okubo@mxz.mesh.ne.jp] Gesendet: Sonntag, 23. Januar 2005 17:57 An: Lehmann Leo Cc: Simao Campos-Neto Betreff: Fwd:Re: Fwd:Q.29 interim meeting/joint meeting with SG19 Dear Mr. Lehmann, I have received the following auto-reply to my message seeking his agreement. Could you please kindly get in touch with him via the advised mobile phone and convey our request? It would be too late if we start after 30 March. >From: probst-pa(a)bluewin.ch >Subject: Re: Fwd:Q.29 interim meeting/joint meeting with SG19 >To: okubo(a)mxz.mesh.ne.jp >Date: Sun, 23 Jan 2005 16:43:56 +0000 >Delivered-To: probst-pa(a)bluewin.ch >X-Biglobe-VirusCheck: Mon, 24 Jan 2005 01:43:59 +0900 > >Thank you very much for your message. >I am away from my office for two weeks and will process your mail only >later (30.1.2005). For urgent issues, you have the possibility to reach >me on my mobile >phone: +41 79 229 96 56. > >Best regards, > >P.A.Probst -----Ursprüngliche Nachricht----- Von: OKUBO Sakae [mailto:okubo@mxz.mesh.ne.jp] Gesendet: Sonntag, 23. Januar 2005 17:44 An: Pierre-Andre PROBST Cc: Istvan Sebestyen; Simao Campos-Neto; Lehmann Leo; Christian Groves Betreff: Fwd:Q.29 interim meeting/joint meeting with SG19 Dear Mr. Probst, This is to seek your agreement on that Q.29 will meet in Melbourne early March as requested by Mr. Lehmann. Strictly speaking, the WP2/16 report of last SG16 meeting says that Q.29 will meet only in May and the current SG16 web page <http://www.itu.int/ITU-T/studygroups/com16/meetings.html> also indicates so. As this is a good opportunity for Questions on mobility of SG16 and SG19 to meet, I hope you could accept this additional setting. Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ****************************************************************** -----Ursprüngliche Nachricht----- Von: John Visser [mailto:jvisser@nortelnetworks.com] Gesendet: Mittwoch, 19. Januar 2005 16:56 An: David.Mcfarlane(a)nokia.com; 'Farrokh Khatibi'; 'Felix,Zhang'; 'leo.lehmann(a)bakom.admin.ch' Cc: peter.m.adams(a)bt.com; Leslie Graf; tatiana.kurakova(a)itu.int Betreff: RE: documents for joint rapporteurs meeting Colleagues: I think everyone is aware of Q.29/16 "Mobility for Multimedia Systems and Services" http://www.itu.int/ITU-T/studygroups/com16/sg16-q29. Leo Lehman is the Rapporteur and he and I have had several discussions on how best to coordinate our mobility studies. Q.2 and 5/19 and Q.6/13 are meeting jointly in Melbourne 1-3 March. Q.29/16 is meeting in Marysville the week of 28 Feb. Marysville is about 2 hours drive outside Melbourne. In my discussions with Leo, we addressed how best to coordinate our work and we came up with the following proposal: Tuesday, 1 March, Leo (and possibly others) would come to Melbourne for the afternoon to take part in the Q.2 and 5/19 and Q.6/13 joint discussions. The objective would be to identify mobility-related definitions and terminology and work towards alignment so that these would be common across all mobility discussions. I anticipate that Leo would also be willing to provide an overview of the Work of Q.5/16 in the previous study period, and the current work anticipated in Q.29/16. Wednesday, 2 March, I (and possibly others) would go to Marysville to sit in on the Q.29/16 discussions. The objective would be to support alignment on mobility-related definitions and terminology from the previous day. I anticipate that I would also provide an overview of the work of Q.2 and 5/19 and Q.6/13. I would appreciate any comments and concerns from you prior to formalizing this further (though we don't want to get very formal at a rapporteurs' meeting.) Regards, John John Visser, P.Eng. Chairman, ITU-T SG 19 "Mobile Telecommunication Networks" http://www.itu.int/ITU-T/studygroups/com19 Phone: +1-613-763-7028 Fax: +1-613-763-2697 Mobile: +1-613-276-6096 Email: jvisser(a)nortel.com

1 0

Follow up: Question 2,3,4,5,21,22,24,25 and 29/16 Rapporteur Meeting
by Christian Groves 20 Jan '05

20 Jan '05

Hello all, As per the Meeting Announcement please send the your meeting registration to me. Please do so even if you had replied previously to my informal request on who intends to come. The registration from the meeting announcement means you are actually coming! Regards, Christian

1 0

Meeting Announcement: Question 2,3,4,5,21,22,24,25 and 29/16 Rapporteur Meeting
by Christian Groves 16 Jan '05

16 Jan '05

To Experts of ITU-T SG16 Questions 2,3,4,5,21,22,24,25 and 29/16. Cc Mr. P-A. Probst, Chairman of SG16 <probst-pa(a)bluewin.ch> Mr. Paul Barrett, Vice Chairman of SG16 <paul.barrett(a)psytechnics.com> Mr. Yushi Naito, Vice Chairman of SG16 <naitoy(a)attglobal.net> Ms. Claude Lamblin, Vice Chairman of SG16 <claude.lamblin(a)rd.francetelecom.com> Mr. I Sebestyen, Vice Chairman of SG16 <Istvan.Sebestyen(a)siemens.com> Mr. S. Campos-Neto, ITU TSB <simao.campos(a)itu.int> De P Jones Rapporteur for Q.2/16 <paulej(a)packetizer.com> C Groves Rapporteur for Q.3/16 <Christian.Groves(a)ericsson.com.au> S Okubo Rapporteur for Q.4/16 <sokubo(a)waseda.jp> R Gilman Rapporteur for Q.5/16 <rrg(a)avaya.com> B Lamer Rapporteur for Q.21(B)/16 <bastien.lamer(a)rd.francetelecom.com> S Okubo Interim Rapporteur for Q.22(C)/16 <sokubo(a)waseda.jp> S.H. Jeong Rapporteur for Q.24(F)/16 <shjeong(a)hufs.ac.kr> M Euchner Rapporteur for Q.25(G)/16 <Martin.Euchner(a)siemens.com> L Lehmann Rapporteur for Q.29(K)/16 <Leo.Lehmann(a)bakom.admin.ch> ------------------------------------------------------------------- Subject: Notice of Joint Rapporteur Meeting in Melbourne, Australia Date: 28 February - 4 March 2005 ------------------------------------------------------------------- Dear Experts of Questions 2,3,4,5,21,22,24,25 and 29/16, The subject meeting of ITU-T SG16 experts will be held in Marysville, outside of Melbourne, Australia at the Maryland Country House. Details of the meeting are contained herein. 1. Date ^^^^^^^ 28th (Monday) February - 4 (Friday) March 2005 Meeting will start at 9:00 AM on the first day Closing around 18:00 on the final day 2. Venue ^^^^^^^^ Maryland Country House, Marysville Victoria Australia Falls Rd, Marysville, Victoria 3779 Australia http://www.marylands.com.au/ Ph: +61 3 5963 3204 Fax: +61 3 5963 3251 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group activities 2) Q.2/16 Real-Time Audio, Video, and Data Communication over Packet-Switched Networks - Coordinate with other SDOs, Questions, or Study Groups - Review items proposed for the H.323-series Implementers Guide - Progress work on the following work items * H.323 Annex Gv2 * H.323 Annex I * H.323 Annex Ov2 * H.460.17 (RAS Tunneling) * H.460.cdor * H.460.geo * H.460.location * H.460.dhcp * H.460.gaam * H.460.presence * H.460.sms - Discuss miscellaneous and new work items 3) Q.3/16 Multimedia Gateway Control Architectures and Protocols - Coordinate with other SDOs, Questions, or Study Groups - Progress work on * H.248.1v3, * H.248.1 Annex F * Revised H.248.8 * H.248.36 * H Series Supplement BHCoA, * H.248.1 V1 IG * H.248 Sub-series IG * H Series Supplement 2 v7. - Consider new material. 4) Q.4/16 Advanced multimedia communication service features on top of the ITU-T defined multimedia system platforms - Progress work on * H.350-series maintenance * Addition to H.350-series * Study of new service features 5) Q.5/16 Control of NAT and Firewall Traversal for H.300-Series Multimedia Systems - Coordinate with other SDOs, Questions, or Study Groups - Work to finalize the requirements for NAT/FW traversal - Progress work on H.proxy - Consider various solution proposals for NAT/FW traversal 6) Q.21/16 Multimedia Architecture - Progress work on * Multimedia Architecture and End to end Open Services Architectural Framework. * Analysis of relevant Architectures prepared by other bodies 7) Q.22/16 Multimedia applications and services - Progress work on * F.VTIP, * F.MMCIP, * F.DL, * F.AVoD * Other new services ? Service description and requirements 8) Q.24/16 Quality of Service and End-to-end Performance in Multimedia Systems - Progress work on * H.323 Annex N (QoS) * H.priority (Service Priority) * H.trans.control (QoS Signalling to Transport Domains) - Discussion on new and miscellaneous items 9) Q.25/16 Multimedia Security in Next-Generation Networks The objectives for this meeting are: - Progress work on * H.235.x V4 subseries, * H.FSIC, * H.460.spn, - Coordination, - Maintenance H.235, - Consider new material. 10) Q.29/16 Mobility for Multimedia Systems and Services - Follow up status of work items - Finalization of technical report regarding combined mobility 11) Interaction with other groups 12) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 18 February 2005 /// /// Distribution of the document: by 23:59 UTC, 21 February 2005 /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify Sakae Okubo < sokubo(a)waseda.jp>, document manager of this meeting, as soon as possible, by 23:59 UTC, Friday 18 February 2005 at the latest. Document number AVD-nnnn will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "AVD" comes from Audio, Video and Data. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document AVD-{nnnn}| | Study Group 16 {Version m if relevant}| | 2,3,4,5,21,22,24,25 and 29/16 Rapporteur Meeting {Date}| | Melbourne, 28 February - 4 March 2005 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ Note: A template for the AVD document can be found at: <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/AVD-template.doc> This may be modified and used for the purpose of document submission at this meeting. 3) File format: Use of Word, PDF, ASCII or HTML is recommended. 4) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (23:59 UTC, Monday 21 February 2005 or before) by posting them at either of the following: - Uploading via FTP Site: ftp3.itu.int/ User ID: avguest Password: Avguest (Note the uppercase 'A') Directory: avc-site/Incoming - E-mail reflector E-mail address: itu-sg16(a)external.cisco.com To subscribe: Send e-mail to majordomo(a)cisco.com In the body of the message, put: subscribe itu-sg16 Please avoid the use of reflector when your document is voluminous. 5) Input documents can be retrieved from 0502_Mel directory of the ftp site once Mr. Okubo has an opportunity to put them into place. The documents will also be available through the following URLs: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel ftp://avguest:Avguest@ftp3.itu.int/avc-site/2005-2008/0502_Mel 6) The document distribution / presentation at the meeting will be all electronic. Participants must bring along a laptop, wireless lan card and/or Ethernet card, and Ethernet cable in order to access the documents. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ The meeting will be hosted by Ericsson Australia at the Maryland Country House in Marysville outside Melbourne Australia. The meeting invitation containing logistic information can be found at: <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/Mel_Invitation.do c> 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send e-mail to Christian Groves <Christian.Groves(a)ericsson.com>, providing the family name, given name, company name, and e-mail address of person(s) attending. Early registration of your attendance is welcome and encouraged. 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ The meeting will be held at the Maryland Country House. This will be a "live-in" meeting. To secure a room please fill in the hotel registration form in the meeting invitation (http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/Mel_Invitation.do c) as soon as possible and return as indicated on the form. We are looking forward to meeting with you in Melbourne. Sincerely yours, Paul JONES Christian GROVES (meeting organizer of this meeting) Sakae OKUBO (document manager of this meeting) Robert GILMAN Istvan Sebestyen Bastien LAMER Seong-ho JEONG Martin EUCHNER Leo LEHMANN ----------

1 0

Meeting Announcement: Question 2,3,4,5,21,22,24,25 and 29/16 Rapporteur
by Christian Groves 16 Jan '05

16 Jan '05

To Experts of ITU-T SG16 Questions 2,3,4,5,21,22,24,25 and 29/16. Cc Mr. P-A. Probst, Chairman of SG16 <probst-pa(a)bluewin.ch> Mr. Paul Barrett, Vice Chairman of SG16 <paul.barrett(a)psytechnics.com> Mr. Yushi Naito, Vice Chairman of SG16 <naitoy(a)attglobal.net> Ms. Claude Lamblin, Vice Chairman of SG16 <claude.lamblin(a)rd.francetelecom.com> Mr. I Sebestyen, Vice Chairman of SG16 <Istvan.Sebestyen(a)siemens.com> Mr. S. Campos-Neto, ITU TSB <simao.campos(a)itu.int> De P Jones Rapporteur for Q.2/16 <paulej(a)packetizer.com> C Groves Rapporteur for Q.3/16 <Christian.Groves(a)ericsson.com.au> S Okubo Rapporteur for Q.4/16 <sokubo(a)waseda.jp> R Gilman Rapporteur for Q.5/16 <rrg(a)avaya.com> B Lamer Rapporteur for Q.21(B)/16 <bastien.lamer(a)rd.francetelecom.com> S Okubo Interim Rapporteur for Q.22(C)/16 <sokubo(a)waseda.jp> S.H. Jeong Rapporteur for Q.24(F)/16 <shjeong(a)hufs.ac.kr> M Euchner Rapporteur for Q.25(G)/16 <Martin.Euchner(a)siemens.com> L Lehmann Rapporteur for Q.29(K)/16 <Leo.Lehmann(a)bakom.admin.ch> ------------------------------------------------------------------- Subject: Notice of Joint Rapporteur Meeting in Melbourne, Australia Date: 28 February - 4 March 2005 ------------------------------------------------------------------- Dear Experts of Questions 2,3,4,5,21,22,24,25 and 29/16, The subject meeting of ITU-T SG16 experts will be held in Marysville, outside of Melbourne, Australia at the Maryland Country House. Details of the meeting are contained herein. 1. Date ^^^^^^^ 28th (Monday) February - 4 (Friday) March 2005 Meeting will start at 9:00 AM on the first day Closing around 18:00 on the final day 2. Venue ^^^^^^^^ Maryland Country House, Marysville Victoria Australia Falls Rd, Marysville, Victoria 3779 Australia http://www.marylands.com.au/ Ph: +61 3 5963 3204 Fax: +61 3 5963 3251 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group activities 2) Q.2/16 Real-Time Audio, Video, and Data Communication over Packet-Switched Networks - Coordinate with other SDOs, Questions, or Study Groups - Review items proposed for the H.323-series Implementers Guide - Progress work on the following work items * H.323 Annex Gv2 * H.323 Annex I * H.323 Annex Ov2 * H.460.17 (RAS Tunneling) * H.460.cdor * H.460.geo * H.460.location * H.460.dhcp * H.460.gaam * H.460.presence * H.460.sms - Discuss miscellaneous and new work items 3) Q.3/16 Multimedia Gateway Control Architectures and Protocols - Coordinate with other SDOs, Questions, or Study Groups - Progress work on * H.248.1v3, * H.248.1 Annex F * Revised H.248.8 * H.248.36 * H Series Supplement BHCoA, * H.248.1 V1 IG * H.248 Sub-series IG * H Series Supplement 2 v7. - Consider new material. 4) Q.4/16 Advanced multimedia communication service features on top of the ITU-T defined multimedia system platforms - Progress work on * H.350-series maintenance * Addition to H.350-series * Study of new service features 5) Q.5/16 Control of NAT and Firewall Traversal for H.300-Series Multimedia Systems - Coordinate with other SDOs, Questions, or Study Groups - Work to finalize the requirements for NAT/FW traversal - Progress work on H.proxy - Consider various solution proposals for NAT/FW traversal 6) Q.21/16 Multimedia Architecture - Progress work on * Multimedia Architecture and End to end Open Services Architectural Framework. * Analysis of relevant Architectures prepared by other bodies 7) Q.22/16 Multimedia applications and services - Progress work on * F.VTIP, * F.MMCIP, * F.DL, * F.AVoD * Other new services ? Service description and requirements 8) Q.24/16 Quality of Service and End-to-end Performance in Multimedia Systems - Progress work on * H.323 Annex N (QoS) * H.priority (Service Priority) * H.trans.control (QoS Signalling to Transport Domains) - Discussion on new and miscellaneous items 9) Q.25/16 Multimedia Security in Next-Generation Networks The objectives for this meeting are: - Progress work on * H.235.x V4 subseries, * H.FSIC, * H.460.spn, - Coordination, - Maintenance H.235, - Consider new material. 10) Q.29/16 Mobility for Multimedia Systems and Services - Follow up status of work items - Finalization of technical report regarding combined mobility 11) Interaction with other groups 12) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 18 February 2005 /// /// Distribution of the document: by 23:59 UTC, 21 February 2005 /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify Sakae Okubo < sokubo(a)waseda.jp>, document manager of this meeting, as soon as possible, by 23:59 UTC, Friday 18 February 2005 at the latest. Document number AVD-nnnn will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "AVD" comes from Audio, Video and Data. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document AVD-{nnnn}| | Study Group 16 {Version m if relevant}| | 2,3,4,5,21,22,24,25 and 29/16 Rapporteur Meeting {Date}| | Melbourne, 28 February - 4 March 2005 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ Note: A template for the AVD document can be found at: <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/AVD-template.doc> This may be modified and used for the purpose of document submission at this meeting. 3) File format: Use of Word, PDF, ASCII or HTML is recommended. 4) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (23:59 UTC, Monday 21 February 2005 or before) by posting them at either of the following: - Uploading via FTP Site: ftp3.itu.int/ User ID: avguest Password: Avguest (Note the uppercase 'A') Directory: avc-site/Incoming - E-mail reflector E-mail address: itu-sg16(a)external.cisco.com To subscribe: Send e-mail to majordomo(a)cisco.com In the body of the message, put: subscribe itu-sg16 Please avoid the use of reflector when your document is voluminous. 5) Input documents can be retrieved from 0502_Mel directory of the ftp site once Mr. Okubo has an opportunity to put them into place. The documents will also be available through the following URLs: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel ftp://avguest:Avguest@ftp3.itu.int/avc-site/2005-2008/0502_Mel 6) The document distribution / presentation at the meeting will be all electronic. Participants must bring along a laptop, wireless lan card and/or Ethernet card, and Ethernet cable in order to access the documents. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ The meeting will be hosted by Ericsson Australia at the Maryland Country House in Marysville outside Melbourne Australia. The meeting invitation containing logistic information can be found at: <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/Mel_Invitation.do c> 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send e-mail to Christian Groves <Christian.Groves(a)ericsson.com>, providing the family name, given name, company name, and e-mail address of person(s) attending. Early registration of your attendance is welcome and encouraged. 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ The meeting will be held at the Maryland Country House. This will be a "live-in" meeting. To secure a room please fill in the hotel registration form in the meeting invitation (http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/Mel_Invitation.do c) as soon as possible and return as indicated on the form. We are looking forward to meeting with you in Melbourne. Sincerely yours, Paul JONES Christian GROVES (meeting organizer of this meeting) Sakae OKUBO (document manager of this meeting) Robert GILMAN Istvan Sebestyen Bastien LAMER Seong-ho JEONG Martin EUCHNER Leo LEHMANN ----------

1 0

Fwd:Update on AAP Status for SG 16 Recs Consented in November 04
by OKUBO Sakae 14 Jan '05

14 Jan '05

*** FYI *** >Subject: Update on AAP Status for SG 16 Recs Consented in November 04 >Date: Thu, 13 Jan 2005 22:00:19 +0100 >From: <simao.campos(a)itu.int> >To: <tsg16mgt(a)ties.itu.int> > >Dear all, > >for your info: >- all 35 Recs that started LC on Dec 1st [AAP#3] have been approved >- the two Recs that started LC on Dec 16 [AAP#4] have also been approved >- F.750 will start LC this weeked (16 Jan) [AAP#5] >- H.264, H.264.1 and H.264.2 will start LC on Feb 1st [AAP#6], >taking advantage of the Q.6 Rapporteurs meeting starting next week > >Cheers, >Simao > >===================================================================== >Sim黍 Ferraz de Campos Neto Counsellor, ITU-T SG 6&16 >International Telecommunication Union Tel: +41-22-730-6805 >Place des Nations Fax: +41-22-730-5853 >Geneva CH1211 - Switzerland E-mail: simao.campos(a)itu.int >On the web: www.itu.int/ITU-T/studygroups/com16 >===================================================================== > ***** Practice random kindness and senseless acts of beauty ***** >=====================================================================

1 0

RE: H.460.cdor
by Even, Roni 13 Jan '05

13 Jan '05

Paul, I support Ernst view. This is also my recollection of the issues in San Jose. A caller asking to retarget against my diversions or filtering is considered to be a spammer. Roni _____ From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.COM] Sent: Thursday, January 13, 2005 4:19 PM To: 'Paul E. Jones'; itu-sg16(a)external.cisco.com Cc: 'Danilo Kempf' Subject: RE: H.460.cdor Paul, I consider the concerns serious enough to discontinue work on this item unless the author will provide a significantly amended draft. My recollection of the San Jose discussions is: * the scope of the service is not precise enough; currently it covers all forms of "retargeting", even such things as the "diversion" of a party to an MCU in order to join it to a conference; the scope should be narrowed to real diversion cases; * the service is quite complex and would need to be supported by a large number of entities, otherwise it would not work in the desired way; * due to the complexity and the vague scope interoperable implementations may be hard to achieve; * people were concerned about possible mis-use of the service for spamming. So, in order to move forward, is the editor prepared to have another go on this service along the lines indicated above? Maybe what is needed is something like a simple "preference indication" for reaching the original destination only. I would also like to mention that in H.450.x there is already an operation defined for overriding diversion-on-busy; this is needed to enable services like call intrusion. Regards, Ernst -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Donnerstag, 13. Jänner 2005 08:47 To: itu-sg16(a)external.cisco.com Cc: 'Danilo Kempf' Subject: H.460.cdor Dear Experts, We need to bring closure to the open work item H.460.cdor. The last discussion did not end up with any decision. The concerns I noted were that people might abuse the functionality and that it might cause some confusion. In my opinion, neither of those concerns are serious enough to delay the work further. Can we get agreement to move this forward? Paul

1 0

RE: H.460.cdor
by Horvath Ernst 13 Jan '05

13 Jan '05

Paul, I consider the concerns serious enough to discontinue work on this item unless the author will provide a significantly amended draft. My recollection of the San Jose discussions is: * the scope of the service is not precise enough; currently it covers all forms of "retargeting", even such things as the "diversion" of a party to an MCU in order to join it to a conference; the scope should be narrowed to real diversion cases; * the service is quite complex and would need to be supported by a large number of entities, otherwise it would not work in the desired way; * due to the complexity and the vague scope interoperable implementations may be hard to achieve; * people were concerned about possible mis-use of the service for spamming. So, in order to move forward, is the editor prepared to have another go on this service along the lines indicated above? Maybe what is needed is something like a simple "preference indication" for reaching the original destination only. I would also like to mention that in H.450.x there is already an operation defined for overriding diversion-on-busy; this is needed to enable services like call intrusion. Regards, Ernst -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Donnerstag, 13. Jänner 2005 08:47 To: itu-sg16(a)external.cisco.com Cc: 'Danilo Kempf' Subject: H.460.cdor Dear Experts, We need to bring closure to the open work item H.460.cdor. The last discussion did not end up with any decision. The concerns I noted were that people might abuse the functionality and that it might cause some confusion. In my opinion, neither of those concerns are serious enough to delay the work further. Can we get agreement to move this forward? Paul

1 0

H.460.cdor
by Paul E. Jones 13 Jan '05

13 Jan '05

Dear Experts, We need to bring closure to the open work item H.460.cdor. The last discussion did not end up with any decision. The concerns I noted were that people might abuse the functionality and that it might cause some confusion. In my opinion, neither of those concerns are serious enough to delay the work further. Can we get agreement to move this forward? Paul

1 0

FW: RFC 3944 on H.350 Directory Services
by simao.campos＠ITU.INT 05 Jan '05

05 Jan '05

Dear colleagues, FYI Simao -----Original Message----- From: rfc-editor(a)rfc-editor.org Sent: 11 December 2004 01:24 To: ietf-announce(a)ietf.org Cc: rfc-editor(a)rfc-editor.org Subject: RFC 3944 on H.350 Directory Services A new Request for Comments is now available in online RFC libraries. RFC 3944 Title: H.350 Directory Services Author(s): T. Johnson, S. Okubo, S. Campos Status: Informational Date: December 2004 Mailbox: Tyler_Johnson(a)unc.edu, sokubo(a)waseda.jp, simao.campos(a)itu.int Pages: 30 Characters: 61160 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-johnson-h350-directory-serv-02.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3944.txt The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to 'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store. Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community. This document contains the entire normative text of ITU-T Recommendations H.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST(a)IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST(a)RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info(a)RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info(a)RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager(a)RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR(a)RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute .. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs.

1 0