Signaling Transport (Fwd: I-D ACTION:draft-ietf-sigtran-sctp-01.txt)

Chip Sharp chsharp at CISCO.COM
Tue Oct 19 09:14:00 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