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

Re: LocalControl Descriptor Parameters
by Nancy-M Greene 15 Oct '99

15 Oct '99

First, quoting from a msg from Christian Huitema - Subject:Re: General Media Descriptor - SDP, sent Sept 17/99, 9am: ----------- > A reasonable assumption is that [we] the > current MGCP parameters will be defined in the combination of at least two > packages, one generic (Usage of echo cancellation, Usage of silence > suppression or voice activity detection, Usage of signal level adaptation > and noise level reduction, or "gain control") and one specific to RTP > (Encoding Method, Packetization period, Bandwidth, Type of Service, Usage > of reservation service, Usage of RTP security). > > There is however one subparameter of MGCP's LocalConnectionOptions that > does not fit squarely into the "package" approach. The "Type of network" > is used to specify whether the new connection should be built over IP, > Frame relay, ATM, etc. This is quite useful in multi-protocol gateways, > specially if we decide that termination names have no structure and no > implied meaning. If a gateway receives a command such as: Transaction=x{ > ctx=$ { add=${...}}}, how can it decide whether to create an RTP > connection, rather than using AAL2? > > I suggest that a "type of network" attribute be added as a generic > subparameter in the LocalControl definition. > > -- Christian Huitema ---------- Here is what I propose go into the generic and rtp packages (i.e. added to draft-ietf-megaco-basicpkg-00.txt, and to APC-1666). Question: I have put Preferred Encoding and Decoding Methods as part of the rtp package - do they go there, or should they be in the generic package? 3.x Generic Package Package Id: g 3.x.1 Properties The following properties are to be used in the LocalControlDescriptor of the StreamDescriptor. The LocalControlDescriptor contains parameters used by the MGC to direct the handling of the stream by the MG. The scope of this information is local to the MG-MGC association. 3.x.1.1 Echo Cancellation PropertyId: ec Description By default, the telephony gateways always perform echo cancellation. However, it is necessary, for some calls, to turn off these operations. Values The echo cancellation parameter can have two values: - "on" (when the echo cancellation is requested) and - "off" (when it is turned off.) The default is "on". 3.x.1.2 Silence suppression PropertyId: ss Description The media gateway may perform silence suppression, or voice activity detection, and avoid sending packets during periods of silence. However, it is necessary, for example for modem calls, to turn off this detection. Values The silence suppression parameter can have two values, "on" (when the voice activity detection is requested) and "off" (when it is turned off.) The default is "off." 3.x.1.3 Gain Control PropertyId: gain Description Gain control, or usage of of signal level adaptation and noise level reduction is used to adapt the level of the signal. However, it is necessary, for example for modem calls, to turn off this function. Values The gain control parameter may either be specified as "automatic", or as an explicit number of decibels of gain. The default is to not perform gain control, which is equivalent to specifying a gain of 0 decibels. 3.x.1.4 Network Type PropertyId:network Description: The MGC may instruct the MG to prepare the connection on a specified type of network. Values: The type of network is encoded as in the "connection-field" parameter of the SDP standard. Possible values are IN (Internet), ATM and LOCAL. The parameter is optional; if absent, the network is determined by the MG. [Tom - you are proposing that this be a list of packages I think. Is that what we want, or do we want strings such as RTP/IP4, or RTP, or AAL2,....] 3.15 RTP Package ID: rtp This package is used to support packet based multimedia data transfer by means of the Real-time Transport Protocol (RTP). 3.15.1 Properties The following properties are to be used in the LocalControlDescriptor of the StreamDescriptor. The LocalControlDescriptor contains parameters used by the MGC to direct the handling of the stream by the MG. The scope of this information is local to the MG-MGC association. 3.15.1.1 Preferred Encoding Method PropertyId: em Description Allows the MGC to specify the encoding method to be used by the MG. Values The encoding will be compatible with the SDP and RTP profiles. The encoding method shall be specified by using one or several valid encoding names, as defined in the RTP AV Profile or registered with the IANA. The MGC may state exactly one value, which the MG will then use for the connection. The MGC may provide a loose specification, such as a list of allowed encoding methods, and if this is the case, they are put in order of preference, most preferred first. The MGC may simply provide a bandwidth indication, leaving the choice of encoding/decoding method and packetization period to the MG. 3.15.1.2 Preferred Decoding Method PropertyId: dm Description Values The decoding will be compatible with the SDP and RTP profiles: The decoding method shall be specified by using one or several valid decoding/encoding names, as defined in the RTP AV Profile or registered with the IANA. The MGC may state exactly one value, which the MG will then use for the connection, The MGC may provide a loose specification, such as a list of allowed decoding methods, and if this is the case, they are put in order of preference, most preferred first. The MGC may simply provide a bandwidth indication, leaving the choice of encoding/decoding method and packetization period to the MG. 3.15.1.3 Preferred packetization period PropertyId: ptime Description Allows the MGC to specify the decoding method to be used by the MG. Values The packetization period is encoded as either the length of time in milliseconds represented by the media in a packet, as specified in the "ptime" parameter of SDP, or as a range value, specifying both the minimum and maximum acceptable packetization periods. The MGC may state exactly one value, which the MG will then use for the connection. The MGC may provide a loose specification, such as a range of packetization periods, and if this is the case, they are put in order of preference, most preferred first. The MGC may simply provide a bandwidth indication, leaving the choice of encoding/decoding method and packetization period to the MG. 3.15.1.4 Bandwidth PropertyId: ba Description The bandwidth specification shall not contradict the specification of encoding methods and packetization period. If an encoding method is specified, then the gateway is authorized to use it, even if it results in the usage of a larger bandwidth than specified. Values The bandwidth is encoded as either a single value or a range, expressed as an integer number of kilobit per seconds. The MGC may state exactly one value, which the MG will then use for the connection. The MGC may simply provide a bandwidth indication, leaving the choice of encoding/decoding method and packetization period to the MG. 3.15.1.5 Type of service PropertyId: tos Description The Type of Service specifies the class of service that will be used for the connection. Values When the connection is transmitted over an IP network, the parameters encodes the 8-bit type of service value parameter of the IP header. When the Type of Service is not specified, the gateway shall use a default or configured value. 3.15.11.6 Reservation Service PropertyId: resv Description The gateways can be instructed to perform a reservation, for example using RSVP, on a given connection. When reservation has been asked on a connection, the gateway will: * start emitting RSVP "PATH" messages if the connection is in "send- only", "send-receive", "conference", "network loop back" or "net- work continuity test" mode (if a remote connection descriptor has been received,) * start emitting RSVP "RESV" messages as soon as it receives "PATH" messages if the connection is in "receive-only", "send-receive", "conference", "network loop back" or "network continuity test" mode. The RSVP filters will be deduced from the characteristics of the connection. The RSVP resource profiles will be deduced from the connection's bandwidth and packetization period. Values When a reservation is needed, the MGC will specify the reservation profile that should be used, which is either "controlled load" or "guaranteed service." The absence of reservation can be indicated by asking for the "best effort" service, which is the default value of this parameter. 3.15.1.7 RTP security PropertyId: encr Description The MGC can request the MG to enable encryption of the audio Packets. Values It does so by providing a key specification, as specified in RFC 2327. By default, encryption is not used. 3.15.1.8 Maximum Jitter Buffer PropertiyId: jit Description This property puts a maximum size on the jitter buffer. Values This property is specified in milliseconds. --------- Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Chip Sharp[SMTP:chsharp@CISCO.COM] > Sent: Friday, October 15, 1999 8:53 AM > To: megaco(a)standards.nortelnetworks.com > Subject: LocalControl Descriptor Parameters > > Maybe I'm missing something obvious, but > In the ABNF and the spec it says that the parameters for the > LocalControlDescriptor are > propertyParm = pkgdName propertyValue > > This implies that the parameters for the LocalControlDescriptor are > defined > in packages. However, in the only package I've seen submitted to SG16 and > discussed (APC-1666), I don't see any parameters defined for > LocalControlDescriptor. For example, where is the package that defines > parameters such as Codec=G.711, echocontrol=ON, gain=2dB, etc.? > > Thanks, > Chip > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- > > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

H.248: Binary Encoding
by Tom-PT Taylor 15 Oct '99

15 Oct '99

Next week in Redbank promises to be very heavy. One of the more difficult issues will be the status of the binary encoding sections. To make sure we don't waste time on non-issues, I would like to see if we can agree on some principles in advance of the discussion. First point: all our detailed work so far has been on the ABNF expression of the protocol. I would therefore hope that we can agree that the ABNF is the definitive statement of the protocol content for H.248v1. This could change in future versions. Corollary 1: This means that any additions or changes we agree to in Redbank should be expressed in terms of changes to the ABNF first, before propagating them to any other form of specification. Second point: Any other form of specification must demonstrate its conformance to the content of the ABNF, but this is not a requirement for it to conform to the exact expression of that content. In other words, if APC-1711, for instance, demonstrates that the original ASN.1 specifies every field in its right place and with its right type, the fact that Pete's tool adds extra tags and brackets is irrelevant. Third point, more controversial: The purpose of an alternative form of protocol specification should be carefully considered. The particular form of specification should meet that purpose. Concretely speaking, what I have in mind is that Pete's ASN.1 modifications could be a valuable tool to confirm conformance of an ASN.1 specification to the ABNF content, but they also introduce a source of potential error in actual creation of binary code. In my personal opinion, it would be better for H.248 to contain either vanilla ASN.1 or a clause by clause mapping of the ABNF into a hand-coded TLV representation within H.248. Final point: If work on the chosen binary-friendly representation seems to be too rushed, I would strongly urge that we determine the related annex(es) separately from the main document. That way we could come into the February meeting with a high degree of confidence in the overall product. Determining the binary-friendly specification at the February meeting would have the same practical effect as deciding it, since there would be no way to change it before decision in the fall WTSA meeting. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

1 0

For the Red Bank Meeting a late contribution (TD)
by Sebestyen Istvan ICN WN ES SP 4 15 Oct '99

15 Oct '99

<<Td-0x>> Dear all, a last minute late contribution to Red Bank. Regards, Istvan Sebestyen -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M CS27, Hofmannstr. 51 D-81359 Munich Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail: istvan.sebestyen(a)icn.siemens.de Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 ---------------------------------------------------------------------------- ----------------

1 0

FW: APC-1711, 1712 review
by Nancy-M Greene 15 Oct '99

15 Oct '99

We are getting discussion of the Red Bank contributions on the megaco list. I am crossposting these discussions to the ITU-T SG16 list. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Rayhan, Abdallah [CAR:5N00:EXCH] > Sent: Thursday, October 14, 1999 11:01 AM > To: megaco(a)standards.nortelnetworks.com > Subject: APC-1711, 1712 review > > > 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. > > 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 ) / "*" ) > > ABNF248: > pkgdName = [ (PackageName | "*") SLASH ] (ItemID | "*" ) > PackageName = NAME > ItemID = NAME > > 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. > > - Extensions do not appear any where in ABNF1711 while they are a major > feature of ABNF248. > > -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. > > - 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 ? > > ABNF248: > SecurityParmIndex = 8(HEXDIG) > SequenceNum = 8(HEXDIG) > AuthData = 32*64(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 dont 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. > > 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. > > 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 ? > > 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 > >

1 0

List of documents
by Sakae OKUBO 15 Oct '99

15 Oct '99

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

1 0

TD - 06 Document
by PVSAK Viswanadham 15 Oct '99

15 Oct '99

Hi, I am sending TD-06 tittled "H.341 Entity-Relationship Diagram" as attachment to this mail as my firewall does not allow me to upload it to the ftp site. With Regards, Viswanadham Hughes Software System, India (See attached file: TD-06.zip)

1 0

Delegates staying at Courtyard Lincroft
by Sakae OKUBO 15 Oct '99

15 Oct '99

Dear Red Bank meeting participants, In response to my query, the following two persons have kindly offered rides for my colleague (Mr. Ryo Takahashi, NTT) staying at Courtyard Lincroft: Rex Coldren Lucent Technologies coldrenr(a)agcs.com -or- rcoldren(a)lucent.com Paul K. Reddy Intel paul.k.reddy(a)intel.com If you stay at Courtyard Lincroft without a car, please contact them for car pool. 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 ***********************************************************

1 0

Re: Request for at TD number
by Sakae OKUBO 14 Oct '99

14 Oct '99

Dear Mr. Sharp, Please use TD-10. SOURCE Cisco Systems, Inc. TITLE Example Call Flows for H.248 support of T1 Robbed Bit Signaling PURPOSE Information 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 ***********************************************************

1 0

Uploading TD-08, TD-09
by Sakae OKUBO 14 Oct '99

14 Oct '99

Dear Q12-14/16 experts, The following two TDs have been uploaded at /Incoming for later moving to /9910_Red: TD-08 Source: S Okubo Title: TV Anytime Forum Press Release TD-09 Source: Siemens Title: Proposal for an enhancement of H.248 protocol for the support of Data connections 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 ***********************************************************

1 0

APC-1653A uploaded
by Tony Crossman 14 Oct '99

14 Oct '99

APC-1653A has now been uploaded to ftp://standard.pictel.com/avc-site/incoming This contribution supercedes APC-1653 uploaded earlier this week. Tony Crossman ********************************************* Antony Crossman PictureTel Corporation 100 Minuteman Road, Andover, MA 01810, USA Tel. +1 (978) 292 4557 Fax. +1 (978) 292 3228 email. tonyc(a)pictel.com *********************************************

1 0