- sg16-avd - lists.packetizer.com

Provisional report of the Red Bank meeting
by Sakae OKUBO 25 Oct '99

25 Oct '99

Dear Q12-14/16 experts, Please be advised that a provisional report of the Red Bank meeting is available at the following place: ftp://standard.pictel.com/avc-site/Incoming/APC-1748.zip or http://standard.pictel.com/ftp/avc-site/Incoming/APC-1748.zip This is an integration of TD-53a (general, Q12), TD-54a (Q13) and TD-47c (Q14) with minimum editing. I will later refine it with all Annexes and the list of participants. I hope this will be useful for your debriefing. Please also be advised that all TDs and missing APC documents have been uploaded to /9910_Red directory. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Question on Intels new annex-j h.246 proposal..
by Edgar Martinez 24 Oct '99

24 Oct '99

Dear Paul, An offical new annex-j for h.246 has been opened, proposed by Intel. Which is Interworking H.323 terminals with the legacy GSM and ANSI wireless networks. What this is proposing is a (MSC+VLR) Gateway that provides H.323 access to the Public Land Mobile Network (PLMN). All the voice and supplementary services will still be provided by the Legacy MSCs. And the data services only by H.323. APC 1671 "H.323 with USIM and PLMN Interworking" and APC 1672 "User Mobility and Service Mobility Services for Wireless Subscribers with H.323 terminals accessing MM over IP and PLMN Networks" Question: Does Intel foresee the same concepts, that is using an adjunct (swithed/IP) Gateway used with the legacy Class-5 switches PSTN? to support H.323 terminals on Class 5 switches? Thanks, Edgar Martinez

1 0

All in One
by Harris 24 Oct '99

24 Oct '99

Start your own 1-900 business or Adult Web Site Business! People are making $$$ week, after week in the 1-900 business. We'll teach you all of our incredible secrets that will take your new exciting business to a whole new level! It's The Simplest and Most Exciting Business You Could Ever Start! *You'll use our "state" of the art equipment! *You'll use our "Live 1 on 1 Psychics" & "Chat Line" girls! *You'll use our incredible Date Line program(s)! No chargebacks! Quick payouts! No expertise needed! Complete programs start at only $99 (no additional charges) The only thing you'll have to do is advertise! This is an excellent turnkey business. We also have excellent turnkey programs if you want to own your own "top" of the line adult web site. ACT NOW!!! For a free color brochure: reply to: mailto:santl9@enotify.com?subject=brochure With the following information: Name:_________________ Address:_________________ City/State/Zip:_________________ email address:_________________ Telephone:_________________ (optional) ///////////////////////////////////////////// To be removed permanantly from this list reply to: mailto:p.deen@angelfire.com?subject=remove /////////////////////////////////////////////

1 0

H323mobility:Meeting report
by Edgar Martinez 23 Oct '99

23 Oct '99

Dear All, Please see attached TD-65 from the NJ meeting. We still need to add sections for interworking for example: Non-H.323 Roaming, Mobility and Handover Interworking with H.323 Networks and Terminals. Additional Parameters to Support H.323 Mobile Network and non-H.323 Mobile Station Interworking. Non-H.323 Mobile Station Automatic Registration and Roaming H.323 Interworking Call Flows. H.323 IP Mobility Network Interworking with C7/SS7 INAP. Thanks, Edgar Martinez

1 0

Re: RTCP port number
by El-Gebaly, Hani 22 Oct '99

22 Oct '99

First, I apologize to the reflector if this question has been answered multiple times before. Is there a FAQ for this mailing list? IMO, option 1 is absolutely valid. Some apps may not honor the odd/even rule, and if I recall correctly this requirement has been relaxed a bit in H.323 (correct me if I am wrong). It has been suggested in a few occasions that the odd/even rule is an RTP rule and not an H.225.0 despite the fact that it is mentioned in the spec. Also it is not only "+1", rather the following odd number since the "+1" port may be busy. You can specify an RTCP odd address in OLC for RTCP receive reports and once you get the OLC from the remote endpoint, use the same odd RTCP for Tx reports, and use the lower even number for RTP port and that way you will still be fully compliant. Here is an example START_PDU: ============================= START PDU ============================ LAYER: H245 DIRECTION: Sent PDU_TYPE: OpenLogicalChannel Forward Logical Channel Number: 257 Unicast Address: IP, 209.218.18.91 TSAPIdentifier: 1161 END_PDU: ================================ END PDU ============================= START_PDU: ============================= START PDU ============================ LAYER: H245 DIRECTION: Sent PDU_TYPE: OpenLogicalChannelAck Forward Logical Channel Number: 257 frwrdMltplxAckPrmtrs: H2250LCAPs_mdChnnl: Unicast Address: IP, 209.218.18.91 TSAPIdentifier: 1160 H2250LCAPs_mdCntrlChnnl: Unicast Address: IP, 209.218.18.91 TSAPIdentifier: 1161 END_PDU: ================================ END PDU ============================= START_PDU: ============================= START PDU ============================ LAYER: H245 DIRECTION: Received PDU_TYPE: OpenLogicalChannelAck Forward Logical Channel Number: 257 frwrdMltplxAckPrmtrs: H2250LCAPs_mdChnnl: Unicast Address: IP, 209.218.18.82 TSAPIdentifier: 1030 H2250LCAPs_mdCntrlChnnl: Unicast Address: IP, 209.218.18.82 TSAPIdentifier: 1031 END_PDU: ================================ END PDU ============================= START_PDU: ============================= START PDU ============================ LAYER: H245 DIRECTION: Received PDU_TYPE: OpenLogicalChannel Forward Logical Channel Number: 257 H2250LCPs_mdCntrlChnnl: Unicast Address: IP, 209.218.18.82 TSAPIdentifier: 1031 END_PDU: ================================ END PDU ============================= regards, Hani -----Original Message----- From: Mohamed Mustafa [mailto:M.Mustafa@SDXPLC.COM] Sent: Friday, October 22, 1999 6:15 AM To: ITU-SG16(a)MAILBAG.INTEL.COM <mailto:ITU-SG16@MAILBAG.INTEL.COM> Subject: Re: RTCP port number Hani, Thanks for your reply. There are still a few points I'm not clear on. Your first four points are consistent with my current understanding of the OLC/OLCA messages. I'll elaborate on these points just to try and avoid the ambiguities of my previous email: There are two optional TransportAddress fields (mediaChannel and mediaControlChannel) within the forward logical channel parameters section of the OLC request message. H.245 specifies that the mediaChannel field should not be included in the OLC request when the transport is unicast. The mediaControlChannel field, if present in the OLC request, specifies the address on which the sender of the OLC will be listening for media control messages. If the mediaControlChannel field is not present in the OLC request, this indicates that a control session is not required. The mediaChannel and mediaControlChannel fields are also present in the OLCA response message. The mediaChannel field must be present in a OLCA response when the transport is unicast, and it specifies the address to which the sender of the corresponding OLC must transmit the media. The mediaControlChannel field in the OLCA response specifies the address on which the sender of the OLCA will be listening for media control messages for this session. The mediaControlChannel should only be included in the OLCA response if a media control channel is required (i.e., only if the mediaControlChannel field was present in the corresponding OLC request). Therefore, assuming a control channel is required, each endpoint must transmit and receive three transport address in order to establish a bi-directional media stream; 1) RTCP address in OLC (a1), 2) RTP address in OLCA (a2), and 3) RTCP address in OLCA (a3). To use a single bi-directional RTCP channel, each endpoint must specify the same address in a1 and a3. The +1 rule requires the port numbers in a1 and a3 to be odd, and that a2 and a3 are identical except for the port number where it is one less in a2 compared to a3. My initial question was regarding the case where one of the endpoints supplies a set of addresses where a1 and a2 do not conform to the +1 rule. There are two possibilities in this case: 1) a1 and a3 are the identical - i.e., single bi-directional RTCP channel, but a2 and a3 do not conform to the +1 rule. 2) a2 and a3 conform to the +1 rule - i.e., 2 unidirectional RTCP channels. My original question can be more precisely worded as: Is option 1 valid? Thanks again, Mohamed

1 0

H.450.x related
by Sunil Chandra 22 Oct '99

22 Oct '99

Dear Karl, Why do the H.450 recommendations not talk about the use of RAS protocol? Is it not required (unlikely, I feel it is required)? With regards, Sunil

1 0

Re: RTCP port number
by Mohamed Mustafa 22 Oct '99

22 Oct '99

Hani, Thanks for your reply. There are still a few points I'm not clear on. Your first four points are consistent with my current understanding of the OLC/OLCA messages. I'll elaborate on these points just to try and avoid the ambiguities of my previous email: There are two optional TransportAddress fields (mediaChannel and mediaControlChannel) within the forward logical channel parameters section of the OLC request message. H.245 specifies that the mediaChannel field should not be included in the OLC request when the transport is unicast. The mediaControlChannel field, if present in the OLC request, specifies the address on which the sender of the OLC will be listening for media control messages. If the mediaControlChannel field is not present in the OLC request, this indicates that a control session is not required. The mediaChannel and mediaControlChannel fields are also present in the OLCA response message. The mediaChannel field must be present in a OLCA response when the transport is unicast, and it specifies the address to which the sender of the corresponding OLC must transmit the media. The mediaControlChannel field in the OLCA response specifies the address on which the sender of the OLCA will be listening for media control messages for this session. The mediaControlChannel should only be included in the OLCA response if a media control channel is required (i.e., only if the mediaControlChannel field was present in the corresponding OLC request). Therefore, assuming a control channel is required, each endpoint must transmit and receive three transport address in order to establish a bi-directional media stream; 1) RTCP address in OLC (a1), 2) RTP address in OLCA (a2), and 3) RTCP address in OLCA (a3). To use a single bi-directional RTCP channel, each endpoint must specify the same address in a1 and a3. The +1 rule requires the port numbers in a1 and a3 to be odd, and that a2 and a3 are identical except for the port number where it is one less in a2 compared to a3. My initial question was regarding the case where one of the endpoints supplies a set of addresses where a1 and a2 do not conform to the +1 rule. There are two possibilities in this case: 1) a1 and a3 are the identical - i.e., single bi-directional RTCP channel, but a2 and a3 do not conform to the +1 rule. 2) a2 and a3 conform to the +1 rule - i.e., 2 unidirectional RTCP channels. My original question can be more precisely worded as: Is option 1 valid? Thanks again, Mohamed -----Original Message----- From: El-Gebaly, Hani [mailto:hani.el-gebaly@intel.com] Sent: 21 October 1999 18:32 To: 'Mohamed Mustafa' Subject: Re: RTCP port number Mohamed, Here is how it works: (1) Openchannel specifies the reverse RTCP address (IP and port) that it will receive RTCP information on (RTCP receive reports). (2) It does not specify any RTP or RTCP send ports. (3) openchannelAck specifies the RTP address that the acknowledging terminal will receive on RTP data and the channel owner (one who initiated openchannel) will stream to (send) RTP data. (4) openchannelAck also specifies RTCP address that the channel owner (initiator) ought to send RTCP sener reports data of this channel on. (5) Note that RTP address != RTCP address. Usually the port numbers are shifted by one. (6) RTP uses an even port number and the corresponding RTCP stream uses the next higher (odd) port number (7) A Terminal may choose to retain the same IP port for RTCP Send and Receive reports. So the RTP port is not sent in the OLC rather returned in the OLCA. regards, Hani -----Original Message----- From: Mohamed Mustafa [mailto:M.Mustafa@SDXPLC.COM] Sent: Thursday, October 21, 1999 8:05 AM To: ITU-SG16(a)MAILBAG.INTEL.COM <mailto:ITU-SG16@MAILBAG.INTEL.COM> Subject: RTCP port number Hi Everyone, Annex A of recommendation H.225.0 states that "RTP uses an even port number and the corresponding RTCP stream uses the next higher (odd) port number". Can anyone clarify what the RTCP port number should be if an endpoint uses two different RTP port numbers (one for transmitting and one for receiving). To avoid confusion, I'll describe the specific scenario I'm trying to resolve; Following completion of the H.245 capability exchange and master/slave determination, the following messages are exchanged to establish a pair of unidirectional media streams between the two endpoints. 1). A transmits an OpenLogicalChannel request to B specifying the port number (a1) that it will use to transmit the RTP packets 2). B transmits an OpenLogicalChannel request to A specifying the port number (b1) that it will use to transmit the RTP packets 3). B transmits an OpenLogicalChannelAck response to A specifying the port number (b2) which the RTP packets should be transmitted to 4). A transmits an OpenLogicalChannelAck response to B specifying the port number (a2) which the RTP packets should be transmitted to Normally, a1 and a2 are the same so there is no confusion as to A's RTCP port number. However, the Phone Dialer application that comes with Windows 2000 does not use the same port numbers in the OLC and the OLCA messages. Thanks, Mohamed

1 0

RTCP port number
by Mohamed Mustafa 21 Oct '99

21 Oct '99

Hi Everyone, Annex A of recommendation H.225.0 states that "RTP uses an even port number and the corresponding RTCP stream uses the next higher (odd) port number". Can anyone clarify what the RTCP port number should be if an endpoint uses two different RTP port numbers (one for transmitting and one for receiving). To avoid confusion, I'll describe the specific scenario I'm trying to resolve; Following completion of the H.245 capability exchange and master/slave determination, the following messages are exchanged to establish a pair of unidirectional media streams between the two endpoints. 1). A transmits an OpenLogicalChannel request to B specifying the port number (a1) that it will use to transmit the RTP packets 2). B transmits an OpenLogicalChannel request to A specifying the port number (b1) that it will use to transmit the RTP packets 3). B transmits an OpenLogicalChannelAck response to A specifying the port number (b2) which the RTP packets should be transmitted to 4). A transmits an OpenLogicalChannelAck response to B specifying the port number (a2) which the RTP packets should be transmitted to Normally, a1 and a2 are the same so there is no confusion as to A's RTCP port number. However, the Phone Dialer application that comes with Windows 2000 does not use the same port numbers in the OLC and the OLCA messages. Thanks, Mohamed

1 0

subscribe
by Fiorenzo Gamba 21 Oct '99

21 Oct '99

-- \\\|/// \\ ~ ~ // (/ @ @ /) +-------------------------oOOo-(_)-oOOo-----------------------------+ Engenieer School of Fribourg Fiorenzo GAMBA Project developer db. de Pérolles 80 1705 Fribourg -Switzerland- Phone : ++41 26 429 67 43 E_mail : fiorenzo.gamba(a)eif.ch http://www.eif.ch Our lab : http://artemis.eif.ch:8080 +-------------------------------------------------------------------+ Oooo. .oooO ( ) ) ( ) ) ) / \ ( (_/ \_)

1 0

Signaling Transport (Fwd: I-D ACTION:draft-ietf-sigtran-sctp-01.txt)
by Chip Sharp 19 Oct '99

19 Oct '99

FYI, This is the baseline text of the Simple Common Transport Protocol being defined by sigtran for transporting PSTN signaling. Chip >X-SMAP-Received-From: outside >Date: Tue, 19 Oct 1999 06:53:04 -0400 >Reply-To: Internet-Drafts(a)ietf.org >Sender: "Signaling Transport (sigtran)" > <SIGTRAN(a)STANDARDS.NORTELNETWORKS.COM> >Comments: RFC822 error: <W> Incorrect or incomplete address field >found and > ignored. >From: Internet-Drafts(a)ietf.org >Subject: I-D ACTION:draft-ietf-sigtran-sctp-01.txt >To: SIGTRAN(a)STANDARDS.NORTELNETWORKS.COM > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Signaling Transport Working Group of the >IETF. > > Title : Simple Control Transmission Protocol > Author(s) : R. Stewart, Q. Xie, K. Morneault, C. Sharp, > H. Schwarzbauer T. Taylor, I. Rytina, > M. Kalla, L. Zhang, V. Paxson > Filename : draft-ietf-sigtran-sctp-01.txt > Pages : 36 > Date : 18-Oct-99 > >This document describes the Simple Control Transmission Protocol >(SCTP). SCTP was designed to transport PSTN signalling messages over >IP networks, but is capable of broader application. >SCTP is an application-level datagram transfer protocol operating on >top of an unreliable datagram service such as UDP. It offers the >following services to its users: >- acknowledged error-free non-duplicated transfer of user data >- application-level segmentation to conform to discovered MTU size >- sequenced delivery of user datagrams within multiple streams, >with an option for order-of-arrival delivery of individual >datagrams >- optional multiplexing of user datagrams into SCTP datagrams, >subject to MTU size restrictions >- enhanced reliability through support of multi-homing at either or >both ends of the association. >The design of SCTP includes appropriate congestion avoidance behaviour >and resistance to flooding and masquerade attacks. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-01.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sigtran-sctp-01.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv(a)ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sigtran-sctp-01.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <19991018121940.I-D(a)ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sigtran-sctp-01.txt > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-01.txt> Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------

1 0

Re: H.248: Binary Encoding
by Pete Cordell 18 Oct '99

18 Oct '99

Chip, If we made the changes mentioned below (and changed pathID to IA5String as has been mentioned elsewhere), then we get something like: !/1.0 ip4=10.0.1.2 T={12345 C={- A={ds0_16/12/4 M={O=^{ M=sendrecv, P1/e=on, P1/enc=G.711mu, P1/gc=0 }} }, A={$ {M={O={ M=recvonly, P1/mjb=40, P1/vad=yes, P1/enc=PCMU;G.726-32 }}} } } and: !/1.0 ip4=10.0.1.1 R={12345 C={6789 A=ds0_16/12/4, A={rtp01 M={O={D=^{ v=0 c=IN IP4 10.68.122.99 m=audio 3456 RTP/AVP 0 96 a=rtpmap:96 G726-32/8000 }}} } } } which looks much less prophecy fulfilling! Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: Chip Sharp <chsharp(a)cisco.com> To: Pete Cordell <pete(a)TECH-KNOW-WARE.COM>; ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: 18 October 1999 19:57 Subject: Re: H.248: Binary Encoding >One of the unfortunate by-products of APC-1711/1712 is that it >approximately doubles the size of the text encoding. This of course >fulfills the prophecy of the binary proponents (who also seem to prefer >ASN.1) that text encoding is inefficient. > >Having encoded a simple message exchange (ADD and Reply) using both >APC-1735 and APC-1711 there are definite differences in the syntax. It >isn't clear that there is much semantic difference. I made up the package >info and tried to use the same pacakge info for both. > >Below is a message exchange (ADD/Reply) encoded in APC-1735 ABNF: >!/1.0 <10.0.1.2> T=12345{ > C=-{ > A=ds0_16/12/4{ > M{O{ > M=sendrecv, > P1/e=on, > P1/enc=G.711mu, > P1/gc=0 > }} > }, > A=${M{O{ > M=recvonly, > P1/mjb=40, > P1/vad=yes, > P1/enc=PCMU;G.726-32 > }} > } >} > > >!/1.0 <10.0.1.1> R=12345{ > C=6789{ > A=ds0_16/12/4, > A=rtp01{ > M{O=D{ > v=0 > c=IN IP4 10.68.122.99 > m=audio 3456 RTP/AVP 0 96 > a=rtpmap:96 G726-32/8000 > }} > } > } >} > >Below is an attempt to encode the same message exchange using the ABNF in 1711: > >!={/{1.0}dAddr={IP4=10.0.1.2}T={12345{{ > $A={PH={elname={nm="ds0_16/12/4"}} > M={ST={O={ > MO=SR > PP= > {{PI="e"{/PE="P1"}}on}, > {{PI="enc"{/PE="P1"}}G711mu}, > {{PI="gc"{/PE="P1"}}0} > }}} > }, > A={ > $M={ST={O={ > MO=RO > PP= > {{PI="mjb"{/PE="P1"}}40}, > {{PI="vad"{/PE="P1"}}yes}, > {{PI="enc"{/PE="P1"}}PCMU,G.726-32} > }}} > } >}}}} > >!={/{1.0}dAddr={IP4=10.0.1.1}P={12345 > AR={{spec=6789CR={ > A={{PH={elname={nm="ds0_16/12/4"}}}}, > A={{PH={elname={nm="rtp01"}}} > TA={M={ST={L=D=^{ > v=0 > c=IN IP4 10.68.122.99 > m=audio 3456 RTP/AVP 0 96 > a=rtpmap:96 G726-32/8000 > }}}} > } > }}} >}} > >I'm assuming that the lack of separators (e.g., between ContextID and first >Action and between Mode and PropParm) and the superfluous curly brackets >can be fixed. >I'm also assuming there are some mistakes in my encoding. > >enjoy. > >Chip > >At 12:43 PM 10/17/99 +0100, Pete Cordell wrote: >>Hi All, >> >>I'd like to propose a few things for discussion that might make the ABNF248 >>and ABNF1711 more aligned. In particular, one difference between the two is >>the number of brackets. >> >>ABNF248 has a lot of constructs of the following: >> >> token EQUAL id LBRKT param *( COMMA param ) RBRKT >> token LBRKT param *( COMMA param ) RBRKT >> >>and also does (which I suppose is the general case): >> token [ EQUAL id ] LBRKT param *( COMMA param ) RBRKT >> >>ABNF1711 naturally has the following structure: >> >> message = *( parameter ) >> parameter = *( tag EQUAL ) value-field *( COMMA value-field ) >> value-field = value / tag / "{" *( parameter ) "}" >> >>This is close to what is in ABNF248 if we move the position of LBRKT around >>in the first case: >> >> token EQUAL LBRKT id param *( COMMA param ) RBRKT >> >>and add an EQUAL in the second case: >> >> token EQUAL LBRKT param *( COMMA param ) RBRKT >> >>Unfortunately an optional untagged item at the beginning of a construct is a >>problem for ABNF1711. This is because in general (although not necessarily >>in the megaco case) it would make the identification of parameters >>ambiguous. This means that the third variant ideally needs to be: >> >> token EQUAL LBRKT ( id / "-" ) param *( COMMA param ) RBRKT >> >>This doesn't seem a radical change to ABNF248, and even if the code is hand >>crafted ought to be fairly easy to accommodate. Naturally, any use of tools >>should make this even easier. In my opinion it also looks more intuitive, >>although I guess it's a bit boring and lacks a bit of designer flair!!! >> >>Is it possible to discuss such changes? >> >>Pete >> >>P.S. The corresponding ASN.1 for the above are: >> >>token ::= SEQUENCE { id AS ? id, param AS ? SEQUENCE OF param } >>token ::= SEQUENCE { param AS ? SEQUENCE OF param } >>token ::= SEQUENCE { id AS ? CHOICE { present AS ? INTEGER, none AS - >>NULL }, >> param AS ? SEQUENCE OF param } >> >>============================================= >>Pete Cordell >>pete(a)tech-know-ware.com >>============================================= > >Support NetAid! http://www.netaid.org >-------------------------------------------------- >Chip Sharp Consulting Engineering >Cisco Systems Telco Bio-region >Reality - Love it or Leave it. >-------------------------------------------------- >

1 0

Re: H.248: Binary Encoding
by Pete Cordell 18 Oct '99

18 Oct '99

Brian, There's no muddling. The line would be: Add{<termID> blah, blah, blah} And before you tell me that there's no separator between <termID> and blah, you'll have to first convince me how it's impossible to read this sentence and how a C compiler can not parse the statement "unsigned int param1;" ! I think the change is minor. The syntax has changed a lot over the previous months. Relatively speaking I think the sweat is minor, and let's face, who said they could stop sweating!!! (And spilling a bit of sweat is preferable to spilling lots of blood if we go back to a text vs. binary war!!!) Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: Brian Rosen <brosen(a)ENG.FORE.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 18 October 1999 16:39 Subject: Re: H.248: Binary Encoding >The reason why the ABNF is usually >token=id LBRKT param *(COMMA param) RBRKT >is because the id is what the command operates ON, >whereas the parameters are what the operation DOES. > >Add=<termiD>{blah, blah, blah} >or >Stream=<streamID>{... >or >Context=<ContextID{ > >The bracketed items are the parameters to the command. >All parameters (uniformly now, I believe) are descriptors. > >Making the command >Add{<termID>, blah, blah, blah} >Muddies the id and the parameters. > >I don't feel all that strongly about this change other than >it's way too late to make it. It was suggested any time in >the last 4 months we have been dealing with syntax issues, >it could have been examined, weighed, and a judgment call >made on it. Now, it seems to me that it breaks too many >things we are trying to not change. People's parsers for >example, the current ABNF (which has a lot of sweat in >reviewers time) for another. > >It seems more reasonable to fix the compiler at this late date. > >Brian > >> -----Original Message----- >> From: Pete Cordell [mailto:pete@tech-know-ware.com] >> Sent: Sunday, October 17, 1999 7:43 AM >> To: ITU-SG16(a)mailbag.cps.intel.com >> Subject: Re: H.248: Binary Encoding >> >> >> Hi All, >> >> I'd like to propose a few things for discussion that might >> make the ABNF248 >> and ABNF1711 more aligned. In particular, one difference >> between the two is >> the number of brackets. >> >> ABNF248 has a lot of constructs of the following: >> >> token EQUAL id LBRKT param *( COMMA param ) RBRKT >> token LBRKT param *( COMMA param ) RBRKT >> >> and also does (which I suppose is the general case): >> token [ EQUAL id ] LBRKT param *( COMMA param ) RBRKT >> >> ABNF1711 naturally has the following structure: >> >> message = *( parameter ) >> parameter = *( tag EQUAL ) value-field *( COMMA value-field ) >> value-field = value / tag / "{" *( parameter ) "}" >> >> This is close to what is in ABNF248 if we move the position >> of LBRKT around >> in the first case: >> >> token EQUAL LBRKT id param *( COMMA param ) RBRKT >> >> and add an EQUAL in the second case: >> >> token EQUAL LBRKT param *( COMMA param ) RBRKT >> >> Unfortunately an optional untagged item at the beginning of a >> construct is a >> problem for ABNF1711. This is because in general (although >> not necessarily >> in the megaco case) it would make the identification of parameters >> ambiguous. This means that the third variant ideally needs to be: >> >> token EQUAL LBRKT ( id / "-" ) param *( COMMA param ) RBRKT >> >> This doesn't seem a radical change to ABNF248, and even if >> the code is hand >> crafted ought to be fairly easy to accommodate. Naturally, >> any use of tools >> should make this even easier. In my opinion it also looks >> more intuitive, >> although I guess it's a bit boring and lacks a bit of >> designer flair!!! >> >> Is it possible to discuss such changes? >> >> Pete >> >> P.S. The corresponding ASN.1 for the above are: >> >> token ::= SEQUENCE { id AS ? id, param AS ? SEQUENCE OF param } >> token ::= SEQUENCE { param AS ? SEQUENCE OF param } >> token ::= SEQUENCE { id AS ? CHOICE { present AS ? INTEGER, none AS - >> NULL }, >> param AS ? SEQUENCE OF param } >> >> ============================================= >> Pete Cordell >> pete(a)tech-know-ware.com >> ============================================= >> >

1 0

Re: H.248: Binary Encoding
by Pete Cordell 18 Oct '99

18 Oct '99

Hi All, I'd like to propose a few things for discussion that might make the ABNF248 and ABNF1711 more aligned. In particular, one difference between the two is the number of brackets. ABNF248 has a lot of constructs of the following: token EQUAL id LBRKT param *( COMMA param ) RBRKT token LBRKT param *( COMMA param ) RBRKT and also does (which I suppose is the general case): token [ EQUAL id ] LBRKT param *( COMMA param ) RBRKT ABNF1711 naturally has the following structure: message = *( parameter ) parameter = *( tag EQUAL ) value-field *( COMMA value-field ) value-field = value / tag / "{" *( parameter ) "}" This is close to what is in ABNF248 if we move the position of LBRKT around in the first case: token EQUAL LBRKT id param *( COMMA param ) RBRKT and add an EQUAL in the second case: token EQUAL LBRKT param *( COMMA param ) RBRKT Unfortunately an optional untagged item at the beginning of a construct is a problem for ABNF1711. This is because in general (although not necessarily in the megaco case) it would make the identification of parameters ambiguous. This means that the third variant ideally needs to be: token EQUAL LBRKT ( id / "-" ) param *( COMMA param ) RBRKT This doesn't seem a radical change to ABNF248, and even if the code is hand crafted ought to be fairly easy to accommodate. Naturally, any use of tools should make this even easier. In my opinion it also looks more intuitive, although I guess it's a bit boring and lacks a bit of designer flair!!! Is it possible to discuss such changes? Pete P.S. The corresponding ASN.1 for the above are: token ::= SEQUENCE { id AS ? id, param AS ? SEQUENCE OF param } token ::= SEQUENCE { param AS ? SEQUENCE OF param } token ::= SEQUENCE { id AS ? CHOICE { present AS ? INTEGER, none AS - NULL }, param AS ? SEQUENCE OF param } ============================================= Pete Cordell pete(a)tech-know-ware.com =============================================

2 1

TD-10 available (H.248 & T1 RBS)
by Chip Sharp 18 Oct '99

18 Oct '99

TD-10.zip has been uploaded to the meeting FTP server. This is a copy of document that has been submitted to IETF to be published as an Internet-Draft. It is being copied to SG16 for information for the H.248 work. It is a draft of an applicability statement showing how H.248 can be used to support T1 Robbed Bit Signaling (which is a type of Channel Associated Signaling). Support of CAS by H.248/megaco has been a discussion item for many months. This draft shows how it could work with the current protocol (APC-1735). This draft does not include any text proposed to be added to H.248, but does identify some parameters, events and signals (e.g., wink) that may need to be defined in a new package. Chip Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------

1 0

Re: H.248: Binary Encoding
by Brian Rosen 18 Oct '99

18 Oct '99

The reason why the ABNF is usually token=id LBRKT param *(COMMA param) RBRKT is because the id is what the command operates ON, whereas the parameters are what the operation DOES. Add=<termiD>{blah, blah, blah} or Stream=<streamID>{... or Context=<ContextID{ The bracketed items are the parameters to the command. All parameters (uniformly now, I believe) are descriptors. Making the command Add{<termID>, blah, blah, blah} Muddies the id and the parameters. I don't feel all that strongly about this change other than it's way too late to make it. It was suggested any time in the last 4 months we have been dealing with syntax issues, it could have been examined, weighed, and a judgment call made on it. Now, it seems to me that it breaks too many things we are trying to not change. People's parsers for example, the current ABNF (which has a lot of sweat in reviewers time) for another. It seems more reasonable to fix the compiler at this late date. Brian > -----Original Message----- > From: Pete Cordell [mailto:pete@tech-know-ware.com] > Sent: Sunday, October 17, 1999 7:43 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: H.248: Binary Encoding > > > Hi All, > > I'd like to propose a few things for discussion that might > make the ABNF248 > and ABNF1711 more aligned. In particular, one difference > between the two is > the number of brackets. > > ABNF248 has a lot of constructs of the following: > > token EQUAL id LBRKT param *( COMMA param ) RBRKT > token LBRKT param *( COMMA param ) RBRKT > > and also does (which I suppose is the general case): > token [ EQUAL id ] LBRKT param *( COMMA param ) RBRKT > > ABNF1711 naturally has the following structure: > > message = *( parameter ) > parameter = *( tag EQUAL ) value-field *( COMMA value-field ) > value-field = value / tag / "{" *( parameter ) "}" > > This is close to what is in ABNF248 if we move the position > of LBRKT around > in the first case: > > token EQUAL LBRKT id param *( COMMA param ) RBRKT > > and add an EQUAL in the second case: > > token EQUAL LBRKT param *( COMMA param ) RBRKT > > Unfortunately an optional untagged item at the beginning of a > construct is a > problem for ABNF1711. This is because in general (although > not necessarily > in the megaco case) it would make the identification of parameters > ambiguous. This means that the third variant ideally needs to be: > > token EQUAL LBRKT ( id / "-" ) param *( COMMA param ) RBRKT > > This doesn't seem a radical change to ABNF248, and even if > the code is hand > crafted ought to be fairly easy to accommodate. Naturally, > any use of tools > should make this even easier. In my opinion it also looks > more intuitive, > although I guess it's a bit boring and lacks a bit of > designer flair!!! > > Is it possible to discuss such changes? > > Pete > > P.S. The corresponding ASN.1 for the above are: > > token ::= SEQUENCE { id AS ? id, param AS ? SEQUENCE OF param } > token ::= SEQUENCE { param AS ? SEQUENCE OF param } > token ::= SEQUENCE { id AS ? CHOICE { present AS ? INTEGER, none AS - > NULL }, > param AS ? SEQUENCE OF param } > > ============================================= > Pete Cordell > pete(a)tech-know-ware.com > ============================================= >

1 0

HTML-ized ABNF from APC-1711
by Chip Sharp 18 Oct '99

18 Oct '99

I've attached a zip file containing a html version of the ABNF from APC-1711. APC1711 contains ABNF generated from the ASN.1 specification proposed by Lucent and Tech-Know-Ware for specifying H.248. I'm currently attempting to code up a simple H.248 message using both the APC1711 version of ABNF and the latest IETF megaco WG draft version of ABNF to see what the differences are. Hopefully the attached (and Tom's HTMLized megaco ABNF he sent out earlier) will make it easier for you to do the same comparison. One exercise I think would be worthwhile before the current SG16 meeting is over is for everyone to go to their respective corners (or hotel rooms) and code up a basic call setup and teardown. Then come back together and see how close we all are. If we come up with widely divergent encodings then we have some work to do. I think the spec is at the stage where this should be possible (at least for the text encoding). Chip Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------

1 0

Re: APC-1711, 1712 review
by Pete Cordell 17 Oct '99

17 Oct '99

I've attached a few comments below to clarify some of the issues raised by Abdallah... Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: Abdallah Rayhan <arayhan(a)NORTELNETWORKS.COM> To: MEGACO(a)STANDARDS.NORTELNETWORKS.COM <MEGACO(a)STANDARDS.NORTELNETWORKS.COM> Date: 14 October 1999 16:05 Subject: APC-1711, 1712 review I took a pass through APC-1711 and APC-1712 and I would like to post my analysis on the mailing list. I don't claim my analysis to be complete, however I tried to point out the main problems I came across while reading APC-1711 ABNF. My primary goal is the final ABNF and not the ASN.1 for two reasons. First, I am not an ASN.1 expert, so I would leave critiquing it to the ASN.1 experts. Second, it would be a big distraction to the IETF having the MEGACO ABNF at an advanced stage with a set of testbenches (ANNEX G). Hence, I will try to focus on APC-1711 ABNF which I call ABNF1711 and MEGACO/H.248 ABNF which I call ABNF248. Just to reassure you, the level of ASN.1 understanding required to work with the definition in 1711 is fairly easy to acquire. I would say slightly easier then ABNF, but then we're talking about fairly straight forward things in both cases so the differences are not really significant. I've attempted to put a bit of a tutorial about ASN.1 in APC-1712. I'm happy to expand this if it is felt to be desirable (I didn't want to go too far straight away in case the editors jumped on me!). In short, if you know C, SEQUENCE == struct, CHOICE == union (except type in union is also stored), and each parameter is "name type" rather than "type name". Each parameter can also be optional, in which case OPTIONAL appears at the end, and/or can appear multiple times, in which case the format is "name SEQUENCE OF type". Knowing that you should be able to pick up the rest by looking at 1711. (I for one learnt ASN.1 just by looking at examples of it.) To start with I have noted that the ABNF1711 does not take the ABNF248 as is but modifies it to suite ASN.1 encoding ( is ASN.1 so restrictive that it does not allow ABNF248 syntax ? ) These discrepancies are found in: (I started noting the different PRs but then found myself marking almost every one.) - Tagging every value. ABNF1711: PkgdName = LBRKT PkgItemID [ PkgName ] RBRKT PkgName = LBRKT "/" ( ( "PE" EQUAL Name ) / "*" ) RBRKT PkgItemID = ( ( "PI" EQUAL Name ) / "*" ) This is one construct the ASN.1 definition has a lot of trouble with. One proposal is just to make this an IA5String (in ASN.1 speak). It can then be coded in the same way as ABNF1711. ABNF248: pkgdName = [ (PackageName | "*") SLASH ] (ItemID | "*" ) PackageName = NAME ItemID = NAME A similar comment applies to this also, i.e. making IA5String removes the problem. You need "PE=" before package name and "PI=" before ItemID. These differences appear in many production rules. - Extra brackets as illustrated in the previous example. In ABNF1711, there is a curly bracket before and after PkgdName while ABNF248 does not have that. This is all over ABNF1711. The IA5String would also remove the need for the curly-wurlies around this. - Extensions do not appear any where in ABNF1711 while they are a major feature of ABNF248. Right, extensions to the ASN.1 are implicit. By that I mean that, every SEQUENCE and CHOICE can be extended. That's way there are a few more braces and there are restrictions on what is untagged. The encoding rules philosophy is that it should be possible to skip any parameter, and then re-start parsing the next parameter without losing parameters, and without interpreting tags as values and so on. -ABNF1711 changes the syntax of the MEGACO constructs. ABNF1711: RequestedActions = LBRKT RequestedAction [ "E" EQUAL SecondEventsDescriptor ] [ "SG" EQUAL SignalsDescriptor ] [ "IC" ] RBRKT ABNF248: requestedActions = requestedAction LWSP [COLON LWSP embeddedSignalEvents ] [COLON LWSP InterceptToken ] embeddedSignalEvents = firstEmbedding [COMMA firstEmbedding] as you can see the first level of embedding (firstEmbedding) is chopped in ABNF1711. As a matter of fact, it changes the syntax into something different. -ABNF1711 enforces ordering of descriptors and parameters while the ABNF248 does not. This issue was raised before and the resolution was made to enforce no order since there is no relationship between descriptors, e.g., modems or muxes, whichever comes first does not affect the other. I think I know what your referring to here, but I can't find it now that I look for it. But basically, the order of tagged parameters after the last untagged parameter is not important. It's a limitation of my ABNF skills that prevented me from being able to express both the multiplicity (if that's the right word for how many times a thing appears) and also say that it could appear in any order. - ABNF248 uses COMMA as a separator for commands, descriptors and parameters. This concept is gone in ABNF1711. - ABNF1711 changes the syntax and the semantics of MEGACO, e.g., ABNF1711: NotifyReply = LBRKT TerminationID [ "ER" EQUAL ErrorDescriptor ] RBRKT You always have TerminationID regardless of whether it is NotifyReply error or not, and ErrorDescriptor is tagged. ABNF248 notifyReply = NotifyToken ( commandError | [EQUAL TerminationID]) commandError = EQUAL TerminationID LBRKT errorDescriptor RBRKT TerminationID is optional in pure notify reply and mandatory in notify error. ErrorDescriptor is not tagged. Also, ABNF1711: SecurityParmIndex = ( 1( BASE64 ) BASE64END ) SequenceNum = ( 1( BASE64 ) BASE64END ) AuthData = ( 5( BASE64 ) BASE64END ) BASE64 = 4( BASE64CHAR ) BASE64END = 4( BASE64CHAR ) / ( 3( BASE64CHAR ) "?" ) / ( 2( BASE64CHAR ) "??" ) Where did "?" and "??" come from ? John has put the wrong modifier type for this OCTET STRING. It should be HEX OCTET STRING, which would result in the use of the two hex values per octet representation. I don't think base64 is used in megaco, but the reason for changing the base64 padding character is using = is ambiguous. It's not clear in the case when parsing parameters that have been added after the definition that the parser knows about whether the = are separating a tag from a value, or part of the value. A simple way to resolve this is to change the padding character. I think this is been done in some other protocol (can't remember which) and it's not difficult to do. Even if you have a black box base64 encoder you can always fix it up later by doing if( last-char == '=' ) last-char = '?' and same for the next to last. ABNF248: SecurityParmIndex = 8(HEXDIG) SequenceNum = 8(HEXDIG) AuthData = 32*64(HEXDIG) If the correct modifier is used as described above, the revised form of this becomes SP = 4 OCTET SN = 4 OCTET AD = 16*32( OCTET ) OCTET = ( HEXDIG HEXDIG ) These are some of the differences. If we review each PR, no PR in ABNF1711 will be saved. So I will stop here. I don't know if the kind of constraints ABNF1711 enforces on the ABNF are due to to the ASN.1 encoding constraints or because of ASN.12ABNF. Whatever the reasoning is, APC1711 should focus on completing the ASN.1 description and generate similar testbenches as in the MEGACO I-D either binary or text, or both. The binary will be definitely different than the text because of tagging, however the text should be same as the test benches written so far. In theory, bin and text should reflect the same protocol and should introduce the least entropy into the syntax. I agree with you that at the moment we have a serious issue that megaco might become two protocols; one binary, one text. I can also see that they may well diverge if we are not careful. We probably differ on the best way to prevent that though :). My recommendation is that rather than writing ASN.12ABNF tool, APC1711 should write examples that use the ASN.1 and bin2text and text2bin tools in order to test the ASN.1 encoding. Once that is out of the way and we know that the ASN.1 is ok, we could look into tools like ASN.12ABNF presuming that it would generate ABNF that is equivalent to ABNF248 syntactical and semantical wise. Otherwise, ABNF1711 approach is unproductive and waste of effort trying to verify every PR of ABNF1711. I'm not sure how you see the bin2text and text2bin working. Perhaps you could explain this further. In addition to that, if we assume that the ASN.1 is ok and the ASN.12ABNF is ok, from what I saw both are not, is there any guarantee that when they change the ASN.1, that will not introduce problems into the ABNF ? My feeling is that it would be a source of confusion and we would need to review the ABNF and probably hand craft some PRs to make it consistent and ambiguous free. If that is that is the case, why should we throw out ABNF248 which we have tested and have a high degree of confidence in. We are very familiar with ABNF248; we know the ins and outs of it; and we know how to fix any problem without disturbing the rest of the grammar. How would ABNF1711 do that ? One reason the ASN.1 definition is having a tough time matching the ABNF is because its fundamental to the way it works to be consistent and avoid ambiguity. By defining how parameters are encoded in a consistent way, and ensuring that that encoding allows them to be readily skipped when they are not understood means there's less (hopefully no) chance that you end up with something that's ambiguous, especially when a v1 implementation parses a v2 message etc. Fortunately, ABNF248 is already pretty consistent which is way its not an impossible task for the ASN.1. As for ASN.1, it is not compatible with the standard. This means that ASN.1 compilers can not produce a correct code. regards Abdallah Rayhan My over all feeling is that a lot of effort has been put in to the ASN.1 close to the ABNF. I'll admit it doesn't result in exactly the same ABNF as 248, but I hope that we can still be part of the consensus forming process that defines the ABNF if the functionality is not changed. Or put another way, I hope we are not precluded from being able to suggest changes to the ABNF because we are also trying to describe it in ASN.1. I'm also aware that this approach was adopted to get us out of the text vs. binary black hole. If this initiative fails then we are back to that, something that I would expect that none of us would want to go back to. So let's work together and try and sort this out once and for all.

1 0

FW: reqs-07: updated 11.2.9 Audio Resource Function
by Nancy-M Greene 16 Oct '99

16 Oct '99

The following update is proposed to the Megaco/H.248 requirements document (APC-1695). I am posting it to this group for information. If anyone has any comments on this updated section, please send me an email or speak to me in RedBank next week. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Greene, Nancy-M [CAR:5N10:EXCH] > Sent: Saturday, October 16, 1999 4:15 PM > To: 'megaco(a)standards.nortelnetworks.com' > Subject: reqs-07: updated 11.2.9 Audio Resource Function > > Below is proposed revised text for 11.2.9. Audio Resource Function > (formerly called IVR Unit). Michael Ramalho and David Cromwell have worked > on the wording, and have agreed on requirements for the speaker > verification/identification and auditory feature extraction/recognition > sections. > > 11.2.9.1 Play Audio, > 11.2.9.2 DTMF Collect, > 11.2.9.3 Record Audio, > 11.2.9.4 Speech Recognition, > 11.2.9.5 Speaker Verification/Identification, and > 11.2.9.6 Auditory Feature Extraction/Recognition, > 11.2.9.7 Audio Conferencing. > > Summary of changes: > - the word Audio Server was removed, and replaced by the more general term > Audio Enabled Gateway > - digit collection was qualified to be DTMF digit collection > - In Section 11.2.9.1, parts d and e on sequences and sets reworked to > eliminate the implementation specific language > - In Section 11.2.9.1 parts f, g, h removed > - reordering of sections, putting Audio Conferencing at the end > - requirements added to sections 11.2.9.5 and 11.2.9.6 > > If there are no comments by Tuesday or so, I will issue reqs-08 with this > updated section in it. Sometime very soon I expect Tom to issue WG last > call on this document. > > Thanks to Michael and David for their work on this. > > Nancy > > revised 11.2.9: > 11.2.9. Audio Resource Function > > An Audio Resource Function (ARF) consists of one or more functional > modules which can be deployed on an stand alone media gateway server IVR, > Intelligent Peripheral, speech/speaker recognition unit, etc. or a > traditional media gateway. Such a media gateway is known as an Audio > Enabled > Gateway (AEG) if it performs tasks defined in one or more of the following > > ARF functional modules: > > Play Audio, > DTMF Collect, > Record Audio, > Speech Recognition, > Speaker Verification/Identification, > Auditory Feature Extraction/Recognition, or > Audio Conferencing. > > > > Additional ARF function modules that support human to machine > communications > through the use of telephony tones (e.g., DTMF) or auditory means (e.g. > speech) > may be appended to the AEG definition in future versions of these > requirements. > > Generic scripting packages for any module must support all the > requirements for > that module. Any package extension for a given module must include, by > inheritance or explicit reference, the requirements for that given module. > > The protocol requirements for each of the ARF modules are provided in the > following subsections. > > > 11.2.9.1. Play Audio Module > > a. Be able to provide the following basic operation: > > - request an ARF MG to play an announcement. > > b. Be able to specify these play characteristics: > > - Play volume > > - Play speed > > - Play iterations > > - Interval between play iterations > > - Play duration > > c. Permit the specification of voice variables such as DN, number, date, > > time, etc. The protocol must allow specification of both the value > (eg 234-3456), and well as the type (Directory number). > > d. Using the terminology that a segment is a unit of playable speech, or > is > an abstraction that is resolvable to a unit of playable speech, > permit > specification of the following segment types: > > - A provisioned recording. > > - A block of text to be converted to speech. > > - A block of text to be displayed on a device. > > - A length of silence qualified by duration. > > - An algorithmically generated tone. > > - A voice variable, specified by type and value. Given a variable > type and value, the IVR/ARF unit would dynamically assemble the > phrases required for its playback. > > - An abstraction that represents a sequence of audio segments. Nesting > of > these abstractions must also be permitted. > > An example of this abstraction is a sequence of audio segments, the > first > of which is a recording of the words "The number you have dialed," > followed by a Directory Number variable, followed by a recording of > the > words "is no longer in service." > > - An abstraction that represents a set of audio segments and which is > resolved to a single segment by a qualifier. Nesting of these > abstractions must be permitted. > > For example take a set of audio segments recorded in different > languages > all of which express the semantic concept "The number you have dialed > is > no longer in service." The set is resolved by a language qualifier. > If > the qualifier is "French," the set resolves to the French version of > this > announcement. > > In the case of a nested abstraction consisting of a set qualified by > > language at one level and and a set qualified by gender at another > level, > it would be possible to specify that an announcement be played in > French > and spoken by a female voice. > > e. Provide two different methods of audio specification: > > - Direct specification of the audio components to be played by speci- > fying the sequence of segments in the command itself. > > - Indirect specification of the audio components to be played by > reference to a single identifier that resolves to a provisioned > sequence of audio segments. > > > 11.2.9.2. DTMF Collect Module > > The DTMF Collect Module must support all of the requirements in the Play > Module in addition to the following requirements: > > a. Be able to provide the following basic operation: > > > - request an AEG to play an announcement, which may optionally > terminated > by DTMF, and then collect DTMF > > b. Be able to specify these event collection characteristics: > > - The number of attempts to give the user to enter a valid DTMF pat- > tern. > > c. With respect to digit timers, allow the specification of: > > - Time allowed to enter the first digit. > > - Time allowed for user to enter each digit subsequent to the first > digit. > > - Time allowed for user to enter a digit once the maximum expected > number of digits has been entered. > > d. To be able to allow multiple prompt operations for DTMF digit > collection, > voice recording (if supported), and/or speech recognition analysis > (if > supported) provide the > following types of prompts: > > - Initial Prompt > > - Reprompt > > - Error prompt > > - Failure announcement > > - Success announcement. > > e. To allow digit pattern matching, allow the specification of: > > - maximum number of digits to collect. > > - minimum number of digits to collect. > > - a digit pattern using a regular expression. > > f. To allow digit buffer control, allow the specification of: > > - Ability to clear digit buffer prior to playing initial prompt > (default is not to clear buffer). > > - Default clearing of buffer following playing of un-interruptible > announcement segment. > > - Default clearing of buffer before playing a re-prompt in response > to previous invalid input. > > g. Provide a method to specify DTMF interruptibility on a per audio > segment basis. > > h. Allow the specification of definable key sequences for digit col- > lection to: > > - Discard collected digits in progress, replay the prompt, and resume > DTMF digit collection. > > - Discard collected digits in progress and resume DTMF digit > collection. > > - Terminate the current operation and return the terminating key > sequence to the MGC. > > i. Provide a way to ask the ARF MG to support the following definable > keys for DTMF digit collection and recording. These keys would then > be > able to be acted upon by the ARF MG: > > - A key to terminate playing of an announcement in progress. > > - A set of one or more keys that can be accepted as the first digit > to be collected. > > - A key that signals the end of user input. The key may or may not > be returned to the MGC along with the input already collected. > > - Keys to stop playing the current announcement and resume playing at > the beginning of the first segment of the announcement, last seg- > ment of the announcement, previous segment of the announcement, > next segment of the announcement, or the current announcement seg- > ment. > > > 11.2.9.3. Record Audio Module > > The Record Module must support all of the requirements in the Play > Module as in addition to the following requirements: > > a. Be able to provide the following basic operation: > > request an AEG to play an announcement and then record voice. > > b. Be able to specify these event collection characteristics: > > - The number of attempts to give the user to make a recording. > > c. With respect to recording timers, allow the specification of: > > - Time to wait for the user to initially speak. > > - The amount of silence necessary following the last speech segment > for the recording to be considered complete. > > - The maximum allowable length of the recording (not including pre- > and post-speech silence). > > d. To be able to allow multiple prompt operations for DTMF digit > collection > (if supported) voice recording, speech recognition analysis (if > supported) > and/or speech verification/identification (if supported) and then to > provide the > following types of prompts: > > - Initial Prompt > > - Reprompt > > - Error prompt > > - Failure announcement > > - Success announcement. > > e. Allow the specification of definable key sequences for digit > recording or speech recognition analysis (if supported) to: > > - Discard recording in progress, replay the prompt, and resume > recording. > > - Discard recording in progress and resume recording. > > - Terminate the current operation and return the terminating key > sequence to the MGC. > > f. Provide a way to ask the ARF MG to support the following definable > keys for recording. These keys would then be able to be acted upon > by the ARF MG: > > - A key to terminate playing of an announcement in progress. > > - A key that signals the end of user input. The key may or may not > be returned to the MGC along with the input already collected. > > - Keys to stop playing the current announcement and resume playing at > the beginning of the first segment of the announcement, last seg- > ment of the announcement, previous segment of the announcement, > next segment of the announcement, or the current announcement seg- > ment. > > g. While audio prompts are usually provisioned in IVR/ARF MGs, support > changing the provisioned prompts in a voice session rather than a > data session. In particular, with respect to audio management: > > - A method to replace provisioned audio with audio recorded during a > call. The newly recorded audio must be accessible using the iden- > tifier of the audio it replaces. > > - A method to revert from replaced audio to the original provisioned > audio. > > - A method to take audio recorded during a call and store it such > that it is accessible to the current call only through its own > newly created unique identifier. > > - A method to take audio recorded during a call and store it such > that it is accessible to any subsequent call through its own newly > created identifier. > > > > 11.2.9.4. Speech Recognition Module > > The speech recognition module can be used for a number of speech > recognition > applications, such as: > > Limited Vocabulary Isolated Speech Recognition (e.g., "yes", "no", > the number "four"), > > Limited Vocabulary Continuous Speech Feature Recognition (e.g., the > utterace "four hundred twenty-three dollars"),and/or > > Continuous Speech Recognition (e.g., unconstrained speech > recognition tasks). > > The Speech Recognition Module must support all of the requirements in the > Play > Module as in addition to the following requirements: > > a. Be able to provide the following basic operation: > > request an AEG to play an announcement and then perform speech > recognition > analysis. > > b. Be able to specify these event collection characteristics: > > - The number of attempts to give to perform speech recognition task. > > c. With respect to speech recognition analysis timers, allow the > specification > of: > > - Time to wait for the user to initially speak. > > - The amount of silence necessary following the last speech segment > for the speech recognition analysis segment to be considered > complete. > > - The maximum allowable length of the speech recognition analysis (not > > including pre- and post- speech silence). > > d. To be able to allow multiple prompt operations for DTMF digit > collection > (if supported), voice recording (if supported), and/or speech > recognition > analysis and then to provide the following types of prompts: > > - Initial Prompt > > - Reprompt > > - Error prompt > > - Failure announcement > > - Success announcement. > > e. Allow the specification of definable key sequences for digit > recording (if supported) or speech recognition analysis to: > > - Discard in process analysis, replay the prompt, and resume > analysis. > > - Discard recording in progress and resume analysis. > > - Terminate the current operation and return the terminating key > sequence to the MGC. > > f. Provide a way to ask the ARF MG to support the following definable > keys for speech recognition analysis. These keys would then be able to be > > acted upon by the ARF MG: > > - A key to terminate playing of an announcement in progress. > > - A key that signals the end of user input. The key may or may not > be returned to the MGC along with the input already collected. > > - Keys to stop playing the current announcement and resume playing at > the beginning of the first segment of the announcement, last seg- > ment of the announcement, previous segment of the announcement, > next segment of the announcement, or the current announcement seg- > ment. > > > 11.2.9.5. Speaker Verification/Identification Module > > The speech verification/identification module returns parameters that > indicate > either the likelihood of the speaker to be the person that they claim to > be > (verification task) or the likelihood of the speaker being one of the > persons > contained in a set of previously characterized speakers (identification > task). > > The Speaker Verification/Identification Module must support all of the > requirements in the Play Module in addition to the following requirements: > > a. Be able to download parameters, such as speaker templates (verification > > task) or sets of potential speaker templates (identification task), either > > prior to the session or in mid-session. > > b. Be able to download application specific software to the ARF either > prior > to the session or in mid-session. > > c. Be able to return parameters indicating either the likelihood of the > speaker to be the person that they claim to be (verification task) or the > likelihood of the speaker being one of the persons contained in a set of > previously characterized speakers (identification task). > > d. Be able to provide the following basic operation: > > request an AEG to play an announcement and then perform speech > verification/identification analysis. > > e. Be able to specify these event collection characteristics: > > - The number of attempts to give to perform speech > verification/identification task. > > > f. With respect to speech verification/identification analysis timers, > allow > the specification of: > > - Time to wait for the user to initially speak. > > - The amount of silence necessary following the last speech segment > for the speech verification/identification analysis segment to be > considered complete. > > - The maximum allowable length of the speech > verification/identification > analysis (not including pre- and post-speech silence). > > d. To be able to allow multiple prompt operations for DTMF digit > collection > (if supported), voice recording, (if supported), speech recognition > analysis (if supported) and/or speech verification/identification and > provide > the following types of prompts: > > - Initial Prompt > > - Reprompt > > - Error prompt > > - Failure announcement > > - Success announcement. > > e. Allow the specification of definable key sequences for digit > recording (if supported) or speech recognition (if supported) in the > speech > verification/identification analysis to: > > - Discard speech verification/identification in analysis, replay the > prompt, > and resume analysis. > > - Discard speech verification/identification analysis in progress and > resume > analysis. > > - Terminate the current operation and return the terminating key > sequence to the MGC. > > f. Provide a way to ask the ARF MG to support the following definable > keys for speech verification/identification analysis. These keys would > then > be able to be acted upon by the ARF MG: > > - A key to terminate playing of an announcement in progress. > > - A key that signals the end of user input. The key may or may not > be returned to the MGC along with the input already collected. > > - Keys to stop playing the current announcement and resume speech > verification/identification at > the beginning of the first segment of the announcement, last seg- > ment of the announcement, previous segment of the announcement, > next segment of the announcement, or the current announcement seg- > ment. > > > 11.2.9.6. Auditory Feature Extraction/Recognition Module > > The auditory feature extraction/recognition module is engineered to > continuously > monitor the auditory stream for the appearance of particular auditory > signals or > speech utterances of interest and to report these events (and optionally a > > signal feature representation of these events) to network servers or MGCs. > > The Auditory Feature Extraction/Recognition Module must support the > following > requirements: > > a. Be able to download application specific software to the ARF either > prior > to the session or in mid-session. > > b. Be able to download parameters, such as a representation of the > auditory > feature to extract/recognize, for prior to the session or in mid-session. > > c. Be able to return parameters indicating the auditory event found or a > representation of the feature found (i.e., auditory feature). > > > 11.2.9.7. Audio Conferencing Module > > The protocol must support: > > a. a mechanism to create multi-point conferences of audio only and > multimedia conferences in the MG. > > b. audio mixing; mixing multiple audio streams into a new composite > audio stream > > c. audio switching; selection of incoming audio stream to be sent out > to all conference participants. > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com >

1 0

Re: APC-1711, 1712 review
by John Segers 16 Oct '99

16 Oct '99

All, Last night I tried to post a reply to Abdallah Rayhan's message with comments on APC-1711 and APC-1712, but it seems that it didn't get through. Here's a second try. John -- John Segers email: jsegers(a)lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954

1 0

Re: List of documents
by Reddy, Paul K 16 Oct '99

16 Oct '99

Hi, I have uploaded APC-1671 and APC-1672 into Incoming directory. Also, please note the change in Titles. Current Title for APC-1671 : Proposal for Inter-working mechanisms between H.323 Terminals and Public Land Mobile Networks (PLMN). APC-1672: Scenarios of Inter-working between H.323 & Public Land Mobile Networks for Wireless Subscribers with H.323 terminals. Thanks, Paul Paul K. Reddy Standards and Architecture Broadband & IP Telephony Lab, Intel Architecture Labs, Intel Corporation, 2111 NE 25th Avenue, Hillsboro, OR - 97124, USA +1 (503)-264-9896 -----Original Message----- From: Sakae OKUBO [mailto:okubo@GITI.OR.JP] Sent: Friday, October 15, 1999 3:51 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: List of documents Dear Q12-14/16 experts, Please find attached a list of documents for the next week meeting in Red Bank. See you there! Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** TD-02 (Red Bank) Documents for Q.12-14/16 Rapporteur meeting in Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? # Late arrival document. * Yet to be uploaded (as of 19:30 Friday, 15 October, Tokyo time). ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653a PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 Nortel ISO/IEC 11571 addressing in H.323 Annex V Networks 1655 Hitachi Ltd. Real-time system of H.262 layered video transmission 1656 Nortel Networks Tunnelling of signalling messages in H.225.0 1657 Nortel Networks Applicability of signalling tunnelling mechanism to Q.SIG 1658 Editor (K Klaghofer) Draft H.450.9 Call Completion Supplementary Services for H.323 #1659 Nokia Functional Requirements for H.323 Annex H (Terminal, User and Service Mobility) 1660 Mitel, Siemens Proposed H.323 Annex L (Stimulus Protocol) 1661 VocalTec Communications Ltd. Resolution of H.245 ambiguity when using Fast Connect procedure 1662 Intel Corp, VocalTec Communications Ltd. Changes to H.323 to support operation behind basic NAT devices - version 2 1663 Editor (I Suconick) H.341 V2 contribution 1664 AT&T H.323 User, Service, and Service Provider Mobility Framework for Multimedia Intelligent Networking 1665 AT&T Viewgraph Presentation of H.323 User, Service, and Service Provider Mobility Framework for Multimedia Intelligent Networking 1666 Nortel and Siemens Megaco/H.248 Generic Packages 1667 Editor (P Jones) H.323v4 draft 1668 AT&T,VocalTec, Alcatel, Motorola, and 3Com Call Flows Supporting H.323 QOS 1669 AT&T,VocalTec, Alcatel, Motorola, and 3Com Extensions of H.225.0 and H.225.0 Annex G Signaling Messages and their ASN.1 Syntax to Support H.323 QOS 1670 AT&T,VocalTec, Alcatel, Motorola, and 3Com Framework for Mapping of H.323 QOS over Packet-based Networks #*1671 Intel The H.323 terminal with secured software based Universa Subscriber Identification Module (USIM) and Inter-working Function with PLMN (public land and mobile networks) #*1672 Intel User Mobility and Service Mobility services for Wireless Subscribers with H.323 terminals accessing Multimedia over IP (MoIP) and PLMN networks 1673 Hughes Software Systems Redundancy and Fault Tolerance Procedures in H.323 1674 Editor (M Euchner) H.323 Annex J: Security for H.323 Annex F 1675 Editor (M Euchner) H.235 Version 2 1676 Siemens AG ClearToken enhancement in H.235 Version 2 1677 Siemens AG AES support in H.235 Version 2 1678 Siemens AG Elliptic curve support in H.235 Version 2 1679 Siemens AG Security Profile negotiation in H.235 Version 2 1680 SG16 management Draft Questions for SG16 WP2 for the new study period 1681 Siemens AG Identification of Gateway Protocol #*1682 InterVoice Media Redirection and Replication 1683a UK ISUP Transport in H.225 using a Generic, Extensible Framework 1684 Lucent Technologies and VocalTec Multiple UsageIndications in Annex G #*1685 Lucent Technologies Using CPL with H.323 1686 Editor (R Bowen) Draft H.225.0 v4 1687 Lucent Technologies H.323 Annex F Hookflash Signaling Enhancements 1688 Editor (G Hellstrom) H.323 Annex G Text Conversation, draft 1689 Ericsson RTP-Text for H.323 Annex G Text Conversation 1690 Ericsson F.MCVS conversation service description with Total Conversation and Text telephony 1691 Ericsson H.248 packages and additions for text telephony and total conversation. 1692 Motorola Using SCTP as an Alternate H.248 Transport 1693 Editor (P Jones) H.323 Implementers Guide #1694 BT Object Profile for ISUP Transport in H.225 using Generic Extensible Framework 1695 IETF Megaco Working Group Megaco/H.248 Requirements - Communication from IETF 1696 Editor (E.Skjaeran, Ericsson) H.323 Annex K (HTTP based service control) 1697 Ericsson (E.Skjaeran) Additions of codepoints to H.225.0 for service control channel 1698 Siemens, Munich University of Technology Progressive AV coding for packet switched lossy networks - a principle approach 1699a Trillium Digital Systems Modifications to the H.225 Annex G protocol 1700 Rapporteur of Q.19/16 Support of proposed modifications on H.245 ASN.1 1701 NTT DoCoMo Multiplexed stream transmission over H.323 logical channel 1702 NEC Editorial errors in H.245 version 4, version 5 1703 Nortel Networks Tones and announcement in fast start 1704a Nortel Networks Modification to gateway decomposition architecture #1705 Nokia On H.323 QoS #1706 Nokia On H.323 Mobility 1707 Editor (P Jones) Early Termination of Fast Connect Procedure in H.323 1708 Cisco Systems Early Closure of the Call Signaling Channel 1709 Marc Roelands, Siemens ICN On Terminals, Users, Services and Mobility in H.323 1710 Lucent Technologies Changes to H.248 to allow use in non-IP environments 1711 Lucent Technologies, Tech-know-ware ASN.1 syntax definition for H.248 1712 Lucent,Ericsson,Tech-Know-Ware H.248/Megaco Structured Message Encoding using a Text Line Format 1713 LM Ericsson H.248 Line Encoding 1714 LM Ericsson H.248 IANA consideration for Package extension 1715 LM Ericsson H.248 Signal Direction 1716 LM Ericsson Cause Handling in H248 1717 LM Ericsson H.248 Functional Outage 1718 LM Ericsson H.248 ServiceChange 1719 LM Ericsson Monitoring in H248 1720 LM Ericsson H.248 Event Enhancements 1721 LM Ericsson H.248 Multiple Virtual MG Enhancements 1722 ITU-TSB (Frank Cohen) Terminology difference between T.35 and H.225.0 1723 LM Ericsson H.248 Priority calls 1724 LM Ericsson Native Descriptors in H248 1725 LM Ericsson H.248 Signalling Transport Converter for MTP 1726 LM Ericsson H.248 Description of the generic signalling 1727 Editor (Christian Groves) Draft H.246 Annex C 1728 LM Ericsson Negotiation of Protocol Capabilities in H225 RAS 1729 LM Ericsson Sigtran in H225 1730 LM Ericsson Architectural strives for Conversational Multi Media with Multi Access 1731 LM Ericsson Layered Mobility Management architecture in MultiMedia/ MultiAccess 1732 Cisco Systems Proposed FacilityReason Codepoint for New Tokens 1733 Cisco Systems Addition of Billing Information to RAS Messages #*1734 Cisco Systems Support for Multiple Payload Types in Logical Channels 1735 Editors (John Segers, Brian Rosen) Draft H.248 1736 FORE Systems H.248 Transport for ATM #1737 BT Methods of transporting ISUP across H.323: Issues for consideration 1738 Editor (Barry Aronson) H.323 Annex I Terms of Reference, v2 1739 Teles, Universitaet Bremen H.323 robustness mechanisms #*1740 Teles et al Organizing work on H.323 - SIP - Interworking #*1741 RADVision Clarifications for Fast Connect Procedure #*1742 RADVision Clarifications for the use of Call Signaling Address in H.225.0 SETUP Procedure #1743 Q.14 Rapporteur Resolving References to IETF Documents in H.248 #1744 Lucent MG Initiated Call Disconnect #1745 Cisco Clarification of the Alternate Gatekeeper Procedures 1746 SG8 Q4 Liaison Statement on Resolving T.38 Annex B inconsistencies with H.245/H.323 Annex D 1747 SG8 T.38 Call Establishment Ad Hoc Group SG16 Liaison Regarding H.248 & H.248 Call Establishment for T.38 ---------------------------------------------------------------------------- Temporary Documents - Red Bank TD- Source Title 01 Rapps. Q.12, Q.13, Q.14 Agenda for the Red Bank meeting - General 02 Rapps. Q.12, Q.13, Q.14 Documentation for the Red Bank meeting 03 Rapp. Q.12 Agenda for Q.12/16 04 Rapp. Q.13 Agenda for Q.13/16 05 Rapp. Q.14 Agenda for Q.14/16 06 Hughes Software System H.341 Entity-Relationship Diagram 07 Robert R. Gilman (informal contribution in support of Document APC-1660) 08 S Okubo TV Anytime Forum Press Release 09 Siemens Proposal for an enhancement of H.248 protocol for the support of Data connections 10 Cisco Systems Example Call Flows for H.248 support of T1 Robbed Bit Signaling

1 0

FW: H.248: Binary Encoding
by Tom-PT Taylor 16 Oct '99

16 Oct '99

I should add something that was so obvious to me that I didn't think to state it: I trust everyone agrees that the ABNF is the definitive specification of the text encoding for H.248v1. > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904-I:EXCH] > Sent: Friday, October 15, 1999 12:10 PM > To: megaco(a)standards.nortelnetworks.com > Subject: H.248: Binary Encoding > > Next week in Redbank promises to be very heavy. One of the more difficult > issues will be the status of the binary encoding sections. To make sure > we > don't waste time on non-issues, I would like to see if we can agree on > some > principles in advance of the discussion. > > First point: all our detailed work so far has been on the ABNF expression > of > the protocol. I would therefore hope that we can agree that the ABNF is > the > definitive statement of the protocol content for H.248v1. This could > change > in future versions. > > Corollary 1: This means that any additions or changes we agree to in > Redbank > should be expressed in terms of changes to the ABNF first, before > propagating them to any other form of specification. > > Second point: Any other form of specification must demonstrate its > conformance to the content of the ABNF, but this is not a requirement for > it > to conform to the exact expression of that content. In other words, if > APC-1711, for instance, demonstrates that the original ASN.1 specifies > every > field in its right place and with its right type, the fact that Pete's > tool > adds extra tags and brackets is irrelevant. > > Third point, more controversial: The purpose of an alternative form of > protocol specification should be carefully considered. The particular > form > of specification should meet that purpose. Concretely speaking, what I > have > in mind is that Pete's ASN.1 modifications could be a valuable tool to > confirm conformance of an ASN.1 specification to the ABNF content, but > they > also introduce a source of potential error in actual creation of binary > code. In my personal opinion, it would be better for H.248 to contain > either vanilla ASN.1 or a clause by clause mapping of the ABNF into a > hand-coded TLV representation within H.248. > > Final point: If work on the chosen binary-friendly representation seems to > be too rushed, I would strongly urge that we determine the related > annex(es) > separately from the main document. That way we could come into the > February > meeting with a high degree of confidence in the overall product. > Determining the binary-friendly specification at the February meeting > would > have the same practical effect as deciding it, since there would be no way > to change it before decision in the fall WTSA meeting. > > Tom Taylor > Advisor -- IPConnect Standards > E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961

1 0

Re: APC-1711, 1712 review
by John Segers 16 Oct '99

16 Oct '99

Abdallah, It's good to see that someone had a good look at APC-1711 and 1712. Below you find some responses to your observations. I'm x-posting to SG16 list, as the contributions will be discussed in the Red Bank meeting. John Abdallah Rayhan wrote: > > > I took a pass through APC-1711 and APC-1712 and I would like to post > my analysis > on the mailing list. I don't claim my analysis to be complete, however > I tried to point > out the main problems I came across while reading APC-1711 ABNF. My > primary > goal is the final ABNF and not the ASN.1 for two reasons. First, I am > not an ASN.1 > expert, so I would leave critiquing it to the ASN.1 experts. Second, > it would > be a big distraction to the IETF having the MEGACO ABNF at an advanced > > stage with a set of testbenches (ANNEX G). Hence, I will try to focus > on APC-1711 ABNF > which I call ABNF1711 and MEGACO/H.248 ABNF which I call ABNF248. > > To start with I have noted that the ABNF1711 does not take the ABNF248 > as is > but modifies it to suite ASN.1 encoding ( is ASN.1 so restrictive that > it does not > allow ABNF248 syntax ? ) In developing an ASN.1 to ABNF translation mechanism, you have to take into account that the ABNF that is generated must be unambiguous. One of the dangers of omitting tags (field names) is introducing ambiguity, for instance because a string value may happen to be the same as a tag. If you do an ABNF spec by hand, you can verify that this does not lead to ambiguity _for that ABNF specification_ but in a mechanical translation process this is much harder. That's why the mechanism proposed in APC-1712 puts restrictions on the use of "AS ?" > These discrepancies are found in: (I started > noting > the different PRs but then found myself marking almost every one.) Well, one grammar can be specified by different sets of PRs. So different sets of PRs I don't find worrying. Differences in the grammar is what's important. > > - Tagging every value. > ABNF1711: > PkgdName = LBRKT PkgItemID [ PkgName ] RBRKT > PkgName = LBRKT "/" ( ( "PE" EQUAL Name ) / "*" ) RBRKT > PkgItemID = ( ( "PI" EQUAL Name ) / "*" ) > > ABNF248: > pkgdName = [ (PackageName | "*") SLASH ] (ItemID | "*" ) > PackageName = NAME > ItemID = NAME > > You need "PE=" before package name and "PI=" before ItemID. > These differences appear in many production rules. Yes, this is true. But I don't think it is a major change because the structure isn't changed very much. > > - Extra brackets as illustrated in the previous example. In ABNF1711, > there is a curly bracket before and after PkgdName while ABNF248 does > not > have that. This is all over ABNF1711. There are indeed many instances where the generated ABNF has more braces. This is because braces are used to delimit sequences of parameters, consistently throughout the entire syntax. A packaged name is a sequence of two parameters: package name and item name. Hence it is surrounded by braces. > > - Extensions do not appear any where in ABNF1711 while they are a > major > feature of ABNF248. The ASN.1 has extension markers (the ellipses). These are not translated into ABNF, because the indicate that optional parameters may be added. If it is important, every extension marker in the ASN.1 of APC-1711 can be preceded by a sequence to produce the extension fields in the ABNF. > > -ABNF1711 changes the syntax of the MEGACO constructs. > > ABNF1711: > RequestedActions = LBRKT RequestedAction [ "E" EQUAL > SecondEventsDescriptor ] > [ "SG" EQUAL SignalsDescriptor ] [ "IC" ] RBRKT > > ABNF248: > requestedActions = requestedAction LWSP [COLON LWSP > embeddedSignalEvents ] [COLON LWSP InterceptToken ] > embeddedSignalEvents = firstEmbedding [COMMA firstEmbedding] > > as you can see the first level of embedding (firstEmbedding) is > chopped in ABNF1711. > As a matter of fact, it changes the syntax into something different. There's no more production for firstEmbedding, but in ABNF248, the syntax continues: firstEmbedding = (secondEvent | signalsDescriptor) secondEvent = EventsDescriptorToken EQUAL [...] signalsDescriptor = SignalsDescriptorToken [...] Noting that the EventsDescriptorToken is an "E" and that the SignalsDescriptorToken is the string "SG", you see that the differences are very minor. ABNF1711 does not use colons for separators, but I think that's not important. > > -ABNF1711 enforces ordering of descriptors and parameters while the > ABNF248 > does not. This issue was raised before and the resolution was made to > enforce no order > since there is no relationship between descriptors, e.g., modems or > muxes, whichever comes > first does not affect the other. True. This is not a problem of the approach per se, but my personal stubborness. ABNF1711 enforces ordering, but the syntax specifies that every descriptor can only occurs once in a list, while ABNF248 puts that in a comment (i.e., specifies it as a semantic constraint). It's a small operation to write ASN.1 that will produce ABNF that contains "descriptor *(COMMA descriptor)" constructs instead of the "[descr1][descr2][descr3]" constructs. > > - ABNF248 uses COMMA as a separator for commands, descriptors > and parameters. This concept is gone in ABNF1711. If we rewrite as explained above, you'll have your commas back. > > - ABNF1711 changes the syntax and the semantics of MEGACO, e.g., > ABNF1711: > NotifyReply = LBRKT TerminationID [ "ER" EQUAL ErrorDescriptor ] > RBRKT > You always have TerminationID regardless of whether it is NotifyReply > error or not, > and ErrorDescriptor is tagged. > > ABNF248 > notifyReply = NotifyToken ( commandError | [EQUAL > TerminationID]) > commandError = EQUAL TerminationID LBRKT errorDescriptor RBRKT > TerminationID is optional in pure notify reply and mandatory in notify > error. > ErrorDescriptor is not tagged. I explained about the tagging above, so let that go. The optional TerminationID presented a bit of a problem for the ASN.1. Because I couldn't for the life of me remember why it's important to be able to leave TerminationIDs out in NotifyReply, I made them mandatory. > > Also, ABNF1711: > SecurityParmIndex = ( 1( BASE64 ) BASE64END ) > SequenceNum = ( 1( BASE64 ) BASE64END ) > AuthData = ( 5( BASE64 ) BASE64END ) > BASE64 = 4( BASE64CHAR ) > BASE64END = 4( BASE64CHAR ) / ( 3( BASE64CHAR ) "?" ) / ( 2( > BASE64CHAR ) "??" ) > Where did "?" and "??" come from ? They ensure that the number of characters in the BASE64 encoded octet string is a multiple of 4. I was told that BASE64 works that way. > > ABNF248: > SecurityParmIndex = 8(HEXDIG) > SequenceNum = 8(HEXDIG) > AuthData = 32*64(HEXDIG) > > These are some of the differences. If we review each PR, no PR in > ABNF1711 > will be saved. So I will stop here. Once again, the PRs aren't the most important, the differences in grammar are. > > I dont know if the kind of constraints ABNF1711 enforces on the ABNF > are due to > to the ASN.1 encoding constraints or because of ASN.12ABNF. > Whatever the reasoning is, APC1711 should focus on completing the > ASN.1 > description and generate similar testbenches as in the MEGACO I-D > either > binary or text, or both. The binary will be definitely different than > the text because of > tagging, however the text should be same as the test benches written > so far. > In theory, bin and text should reflect the same protocol and should > introduce the least > entropy into the syntax. > > My recommendation is that rather than writing ASN.12ABNF tool, APC1711 > > should write examples that use the ASN.1 and bin2text and text2bin > tools in order to > test the ASN.1 encoding. Once that is out of the way and we know that > the ASN.1 is ok, > we could look into tools like ASN.12ABNF presuming that it would > generate ABNF > that is equivalent to ABNF248 syntactical and semantical wise. > Otherwise, ABNF1711 > approach is unproductive and waste of effort trying to verify every PR > of ABNF1711. I agree that examples are useful, but this comment is counter productive. > > In addition to that, if we assume that the ASN.1 is ok and the > ASN.12ABNF is > ok, from what I saw both are not, Well, if you define ABNF248 as being right and anything that's different as being wrong, then obviously your right, right? Otherwise, your're wrong, right? As far as I can tell, the ASN.1 is ok, but it definitely needs review. I'm glad you took the effort to be the first to comment. And I'm glad that you didn't find any semantic errors (barring the mandatory TerminationID, which I don't consider an error but a difference). > is there any guarantee that when > they change > the ASN.1, that will not introduce problems into the ABNF ? My feeling > is that > it would be a source of confusion and we would need to review the ABNF > and > probably hand craft some PRs to make it consistent and ambiguous free. > > If that is that is the case, why should we throw out ABNF248 which > we have tested and have a high degree of confidence in. We are very > familiar > with ABNF248; we know the ins and outs of it; and we know how to fix > any problem > without disturbing the rest of the grammar. How would ABNF1711 do that > ? Using the mechanical translation mechanism gives me a higher degree of confidence. I don't have to worry anymore about having accidentally omitted a closing brace, or being inconsistent with the use of separators. > > As for ASN.1, it is not compatible with the standard. This means that > ASN.1 compilers > can not produce a correct code. APC-1712 addresses this. The extensions that were added to deal with the different types of separators and brackets in ABNF248 can be put into special comments in the ASN.1. They take the form "--& <extension> --" A tool that does the text encoding as described, recognizes these comments, a normal ASN.1 compiler sees them as comments, ignores them and produces code (correctness is up to the compiler writer :-). > > regards > Abdallah Rayhan > -- John Segers email: jsegers(a)lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954

1 0

APC-1685 Using CPL with H.323
by Terry L Anderson 15 Oct '99

15 Oct '99

I have uploaded the following document to Incoming: APC-1685 Using CPL with H.323. -- We make IP speak with an Ascending voice ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 Lucent Technologies / InterNetworking Systems Voice Over IP Access Networks / Applications Group Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

Re: LocalControl Descriptor Parameters
by Nancy-M Greene 15 Oct '99

15 Oct '99

First, quoting from a msg from Christian Huitema - Subject:Re: General Media Descriptor - SDP, sent Sept 17/99, 9am: ----------- > A reasonable assumption is that [we] the > current MGCP parameters will be defined in the combination of at least two > packages, one generic (Usage of echo cancellation, Usage of silence > suppression or voice activity detection, Usage of signal level adaptation > and noise level reduction, or "gain control") and one specific to RTP > (Encoding Method, Packetization period, Bandwidth, Type of Service, Usage > of reservation service, Usage of RTP security). > > There is however one subparameter of MGCP's LocalConnectionOptions that > does not fit squarely into the "package" approach. The "Type of network" > is used to specify whether the new connection should be built over IP, > Frame relay, ATM, etc. This is quite useful in multi-protocol gateways, > specially if we decide that termination names have no structure and no > implied meaning. If a gateway receives a command such as: Transaction=x{ > ctx=$ { add=${...}}}, how can it decide whether to create an RTP > connection, rather than using AAL2? > > I suggest that a "type of network" attribute be added as a generic > subparameter in the LocalControl definition. > > -- Christian Huitema ---------- Here is what I propose go into the generic and rtp packages (i.e. added to draft-ietf-megaco-basicpkg-00.txt, and to APC-1666). Question: I have put Preferred Encoding and Decoding Methods as part of the rtp package - do they go there, or should they be in the generic package? 3.x Generic Package Package Id: g 3.x.1 Properties The following properties are to be used in the LocalControlDescriptor of the StreamDescriptor. The LocalControlDescriptor contains parameters used by the MGC to direct the handling of the stream by the MG. The scope of this information is local to the MG-MGC association. 3.x.1.1 Echo Cancellation PropertyId: ec Description By default, the telephony gateways always perform echo cancellation. However, it is necessary, for some calls, to turn off these operations. Values The echo cancellation parameter can have two values: - "on" (when the echo cancellation is requested) and - "off" (when it is turned off.) The default is "on". 3.x.1.2 Silence suppression PropertyId: ss Description The media gateway may perform silence suppression, or voice activity detection, and avoid sending packets during periods of silence. However, it is necessary, for example for modem calls, to turn off this detection. Values The silence suppression parameter can have two values, "on" (when the voice activity detection is requested) and "off" (when it is turned off.) The default is "off." 3.x.1.3 Gain Control PropertyId: gain Description Gain control, or usage of of signal level adaptation and noise level reduction is used to adapt the level of the signal. However, it is necessary, for example for modem calls, to turn off this function. Values The gain control parameter may either be specified as "automatic", or as an explicit number of decibels of gain. The default is to not perform gain control, which is equivalent to specifying a gain of 0 decibels. 3.x.1.4 Network Type PropertyId:network Description: The MGC may instruct the MG to prepare the connection on a specified type of network. Values: The type of network is encoded as in the "connection-field" parameter of the SDP standard. Possible values are IN (Internet), ATM and LOCAL. The parameter is optional; if absent, the network is determined by the MG. [Tom - you are proposing that this be a list of packages I think. Is that what we want, or do we want strings such as RTP/IP4, or RTP, or AAL2,....] 3.15 RTP Package ID: rtp This package is used to support packet based multimedia data transfer by means of the Real-time Transport Protocol (RTP). 3.15.1 Properties The following properties are to be used in the LocalControlDescriptor of the StreamDescriptor. The LocalControlDescriptor contains parameters used by the MGC to direct the handling of the stream by the MG. The scope of this information is local to the MG-MGC association. 3.15.1.1 Preferred Encoding Method PropertyId: em Description Allows the MGC to specify the encoding method to be used by the MG. Values The encoding will be compatible with the SDP and RTP profiles. The encoding method shall be specified by using one or several valid encoding names, as defined in the RTP AV Profile or registered with the IANA. The MGC may state exactly one value, which the MG will then use for the connection. The MGC may provide a loose specification, such as a list of allowed encoding methods, and if this is the case, they are put in order of preference, most preferred first. The MGC may simply provide a bandwidth indication, leaving the choice of encoding/decoding method and packetization period to the MG. 3.15.1.2 Preferred Decoding Method PropertyId: dm Description Values The decoding will be compatible with the SDP and RTP profiles: The decoding method shall be specified by using one or several valid decoding/encoding names, as defined in the RTP AV Profile or registered with the IANA. The MGC may state exactly one value, which the MG will then use for the connection, The MGC may provide a loose specification, such as a list of allowed decoding methods, and if this is the case, they are put in order of preference, most preferred first. The MGC may simply provide a bandwidth indication, leaving the choice of encoding/decoding method and packetization period to the MG. 3.15.1.3 Preferred packetization period PropertyId: ptime Description Allows the MGC to specify the decoding method to be used by the MG. Values The packetization period is encoded as either the length of time in milliseconds represented by the media in a packet, as specified in the "ptime" parameter of SDP, or as a range value, specifying both the minimum and maximum acceptable packetization periods. The MGC may state exactly one value, which the MG will then use for the connection. The MGC may provide a loose specification, such as a range of packetization periods, and if this is the case, they are put in order of preference, most preferred first. The MGC may simply provide a bandwidth indication, leaving the choice of encoding/decoding method and packetization period to the MG. 3.15.1.4 Bandwidth PropertyId: ba Description The bandwidth specification shall not contradict the specification of encoding methods and packetization period. If an encoding method is specified, then the gateway is authorized to use it, even if it results in the usage of a larger bandwidth than specified. Values The bandwidth is encoded as either a single value or a range, expressed as an integer number of kilobit per seconds. The MGC may state exactly one value, which the MG will then use for the connection. The MGC may simply provide a bandwidth indication, leaving the choice of encoding/decoding method and packetization period to the MG. 3.15.1.5 Type of service PropertyId: tos Description The Type of Service specifies the class of service that will be used for the connection. Values When the connection is transmitted over an IP network, the parameters encodes the 8-bit type of service value parameter of the IP header. When the Type of Service is not specified, the gateway shall use a default or configured value. 3.15.11.6 Reservation Service PropertyId: resv Description The gateways can be instructed to perform a reservation, for example using RSVP, on a given connection. When reservation has been asked on a connection, the gateway will: * start emitting RSVP "PATH" messages if the connection is in "send- only", "send-receive", "conference", "network loop back" or "net- work continuity test" mode (if a remote connection descriptor has been received,) * start emitting RSVP "RESV" messages as soon as it receives "PATH" messages if the connection is in "receive-only", "send-receive", "conference", "network loop back" or "network continuity test" mode. The RSVP filters will be deduced from the characteristics of the connection. The RSVP resource profiles will be deduced from the connection's bandwidth and packetization period. Values When a reservation is needed, the MGC will specify the reservation profile that should be used, which is either "controlled load" or "guaranteed service." The absence of reservation can be indicated by asking for the "best effort" service, which is the default value of this parameter. 3.15.1.7 RTP security PropertyId: encr Description The MGC can request the MG to enable encryption of the audio Packets. Values It does so by providing a key specification, as specified in RFC 2327. By default, encryption is not used. 3.15.1.8 Maximum Jitter Buffer PropertiyId: jit Description This property puts a maximum size on the jitter buffer. Values This property is specified in milliseconds. --------- Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Chip Sharp[SMTP:chsharp@CISCO.COM] > Sent: Friday, October 15, 1999 8:53 AM > To: megaco(a)standards.nortelnetworks.com > Subject: LocalControl Descriptor Parameters > > Maybe I'm missing something obvious, but > In the ABNF and the spec it says that the parameters for the > LocalControlDescriptor are > propertyParm = pkgdName propertyValue > > This implies that the parameters for the LocalControlDescriptor are > defined > in packages. However, in the only package I've seen submitted to SG16 and > discussed (APC-1666), I don't see any parameters defined for > LocalControlDescriptor. For example, where is the package that defines > parameters such as Codec=G.711, echocontrol=ON, gain=2dB, etc.? > > Thanks, > Chip > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- > > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

H.248: Binary Encoding
by Tom-PT Taylor 15 Oct '99

15 Oct '99

Next week in Redbank promises to be very heavy. One of the more difficult issues will be the status of the binary encoding sections. To make sure we don't waste time on non-issues, I would like to see if we can agree on some principles in advance of the discussion. First point: all our detailed work so far has been on the ABNF expression of the protocol. I would therefore hope that we can agree that the ABNF is the definitive statement of the protocol content for H.248v1. This could change in future versions. Corollary 1: This means that any additions or changes we agree to in Redbank should be expressed in terms of changes to the ABNF first, before propagating them to any other form of specification. Second point: Any other form of specification must demonstrate its conformance to the content of the ABNF, but this is not a requirement for it to conform to the exact expression of that content. In other words, if APC-1711, for instance, demonstrates that the original ASN.1 specifies every field in its right place and with its right type, the fact that Pete's tool adds extra tags and brackets is irrelevant. Third point, more controversial: The purpose of an alternative form of protocol specification should be carefully considered. The particular form of specification should meet that purpose. Concretely speaking, what I have in mind is that Pete's ASN.1 modifications could be a valuable tool to confirm conformance of an ASN.1 specification to the ABNF content, but they also introduce a source of potential error in actual creation of binary code. In my personal opinion, it would be better for H.248 to contain either vanilla ASN.1 or a clause by clause mapping of the ABNF into a hand-coded TLV representation within H.248. Final point: If work on the chosen binary-friendly representation seems to be too rushed, I would strongly urge that we determine the related annex(es) separately from the main document. That way we could come into the February meeting with a high degree of confidence in the overall product. Determining the binary-friendly specification at the February meeting would have the same practical effect as deciding it, since there would be no way to change it before decision in the fall WTSA meeting. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

1 0