October 1999 - sg16-avd - lists.packetizer.com

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