H.248: Binary Encoding
Pete Cordell
pete at TECH-KNOW-WARE.COM
Mon Oct 18 17:46:06 EDT 1999
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 at tech-know-ware.com
=============================================
-----Original Message-----
From: Chip Sharp <chsharp at cisco.com>
To: Pete Cordell <pete at TECH-KNOW-WARE.COM>; ITU-SG16 at mailbag.cps.intel.com
<ITU-SG16 at 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 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