TD-10 available (H.248 & T1 RBS)

Chip Sharp chsharp at CISCO.COM
Mon Oct 18 12:31:40 EDT 1999


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



More information about the sg16-avd mailing list