- sg16-avd - lists.packetizer.com

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, … [View More] 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. >-------------------------------------------------- > [View Less]

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 … [View More]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 >> ============================================= >> > [View Less]

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: … [View More]

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 … [View More]

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 … [View More]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 > ============================================= > [View Less]

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 … [View More]

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 … [View More] 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. [View Less]

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: … [View More] 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 > [View Less]

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, … [View More]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 [View Less]

1 0