- sg16-avd - lists.packetizer.com

Re: [Mobility] ITU-T SG16 WP2 Q.2/Q.5/Q.G Conference Call meeting s information
by Reddy, Paul K 28 Nov '01

28 Nov '01

Dear ITU-T SG16 WP2 Colleagues and Mobility Experts, Sorry for the delay in sending this email to the reflector and also due the outages of the SG16 reflector last week the last sent email could not be posted on this reflector. Please accept our apologies. As Rapporteur of Question_5/SG16 (Mobility for Multimedia Systems and Services) agreed in Dublin, Ireland Rapporteur's meeting to organize 3 two hours conference call meetings during Nov, Dec and January months before ITU-T SG16 face to face meeting during February, 2002 in Geneva, Switzerland. The goal of following conference call meetings are to make progress on the following recommendations: 1. H.MMS.0: User/Service Mobility Management for H.323 Multimedia Systems. 2. H.MMS.1: Terminal Mobility Management for H.323 Multimedia Systems. 3. H.MMS.2: Inter-working and Interoperability between Mobility Management for Multimedia systems and Cellular PLMNs. 4. H.MMS.3: Presence and Instant Messaging Services for mobile and non-mobile Multimedia systems. 5. H.MMS.4: Inter-working and Interoperability between H.MMS.3 and current Presence and IM systems. For the status of the above recommendations and related documents, please see the enclosed Dublin's Q.5 Rapporteur's meeting report. Also, please go to URL http://standard.pictel.com/ftp/avc-site/0110_Dub <http://standard.pictel.com/ftp/avc-site/0110_Dub> for Q.5/16 documents. Guidelines for contributing and participating in the following Conference calls: 1. Companies and individual experts are welcome to contribute by uploading the contributions to ftp site: ftp://standard.pictel.com/avc-site/Incoming/Q5conf/ By due dates of each conference call meetings Contributions submission due dates: * For November 30, 2001 conference call is midnight (Pacific standard time) of Nov 28, 2001 * For December 18, 2001 conference call is midnight (Pacific standard time) of Dec 14, 2001 * For January 25, 2002 conference call is midnight (Pacific standard time) of Jan 18, 2001 2. Reply to this email to paul.k.reddy(a)intel.com <mailto:paul.k.reddy@intel.com> and get confirmation of your attendance on each of the conference call meetings in order to reserve the bridge port for a guarantee access during the conference call meetings. 3. Agenda for each Conference call meeting: * Introduction * Review contributions in the following order(Note: continue where we left off in one conference call meeting to another) i. H.MMS.1 (Terminal Mobility for H.323 MM systems) and H.22x.x (Mobility Management protocol and procedures) contributions. This recommendation is targeted for approval during Feb, 2002 SG16 meeting in Geneva. ii. H.MMS.0 (User Mobility, Service Mobility for Multimedia systems) contributions. This recommendation is targeted for approval during October, 2002 SG16 meeting in Geneva. iii. H.MMS.3 (Presence and IM services for mobile and non-mobile Multimedia Systems (e.g., H.323 systems)). This recommendation is targeted for approval during October, 2002 SG16 meeting in Geneva. iv. H.MMS.4 (Inter-working and Interoperability between H.MMS.3 and current Presence and IM systems). This recommendation is targeted for approval during Feb, 2003 SG16 meeting in Geneva. v. H.MMS.2 (Inter-working and Interoperability between Mobility Management for MM systems and Cellular PLMNs). This recommendation is targeted for approval during October, 2003 SG16 meeting in Geneva. If you have any questions, please email Q.5/16 Rapporteur (Mr. Paul K. Reddy) at paul.k.reddy(a)intel.com <mailto:paul.k.reddy@intel.com> Conference call Bridge information: Conference call Meeting 1: Start: Nov 30, 2001 07:00 Pacific Standard Time End: Nov 30, 2001 09:00 Pacific Standard Time Duration: 120 minutes Moderator REDDY, PAUL K US Dial-In Number: 1-877-299-1938 International Dial-In Number: 1-617-801-9666 Passcode: 9899887 --------------------------------------------------- Conference Call Meeting 2: Start: Dec 18, 2001 07:00 Pacific Standard Time End: Dec 18, 2001 09:00 Pacific Standard Time User Instructions: Date: Tuesday, December 18, 2001 Lines: 10 Duration: 120 minutes Moderator REDDY, PAUL K US Dial-In Number: 1-877-299-1938 International Dial-In Number: 1-617-801-9666 Passcode: 6449818 ----------------------------------------------------- Conference Call Meeting 3: Start: Jan 25, 2002 07:00 Pacific Time End: Jan 25, 2002 09:00 Pacific Time Moderator REDDY, PAUL K US Dial-In Number: 1-877-299-1938 International Dial-In Number: 1-617-801-9666 Passcode: 3708752 ----------------------------------------------------- regards, Paul Paul K. Reddy Rapporteur of Q.5/16 ITU-T SG16 Working Party 2 Intel Labs, 2111 N.E. 25th Avenue, mailstop: JF3-377 Hillsboro, OR-97124, USA Tel: +1 (503)-264-9896 E-mail: paul.k.reddy(a)intel.com

1 0

Test Ignore
by Allen, Wayne 27 Nov '01

27 Nov '01

Test *^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^ Wayne Allen Network Software Engineer Intel Corporation - Internet and Communications Lab email: wayne.allen(a)intel.com phone: 503-264-8660 *^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^*^

1 0

Have you ever tried Videosinferencing over ADSL?
by Dr. Heinz Weber 27 Nov '01

27 Nov '01

Hi, my Name is Heinz Weber, I'm the telemedicine-coordinator of our University and as well of the German society of surgery. Apart from Video over ISDN we have been working a lot on Video over ATM and Video over IP. Now I was really interested whether there were some groups having tried out "Video over DSL" already. A second Question was where I could get a description of G.703-Standard and whether there are possibilities to transfer G.703-Data over IP Thank you and please subscribe me to your mailing-list

1 0

ITU-SG16 List Back Online
by Meyer, Greg W 26 Nov '01

26 Nov '01

ITU-SG16 Experts: I apologize for any inconvenience with the ITU-SG16 mail list. The mail server was upgraded over the holiday weekend but a glitch (IOW human error) occurred. As of this afternoon (Pacific time zone), the list is again up and running. If you tried to send mail and have not received the confirmation message from LISTSERV by now, you will need to resend the message. Again, please accept my apologies for any inconvenience. Greg Meyer Intel Labs

1 0

ITU-SG16 Mail Server Scheduled Downtime
by Meyer, Greg W 21 Nov '01

21 Nov '01

All ITU-SG16 Users: The ITU-SG16 mail list server will go down on Wednesday, November 21st starting at 12pm Pacific Standard Time. I don't know the length of the downtime but anticipate it to be no more than a few hours. I apologize for any inconvenience. The server team will notify me when the server is back up and I will send out a notification. Please contact me if you have any questions. Best Regards, Greg Meyer Intel Labs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Test - ITU-SG16 working?
by Meyer, Greg W 16 Nov '01

16 Nov '01

This site has been inactive since November 1st. Just checking to see if it works. If you have tried to email to the ITU-SG16 mail list without success, please email me at greg.w.meyer(a)intel.com. Thanks, Greg Meyer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Trial Conclusion for New ITU-SG16 Mail List Procedures
by Meyer, Greg W 01 Nov '01

01 Nov '01

All ITU-SG16 Mail List Subscribers: The October trial for the new procedures has concluded. The new procedures include a "confirmation" message from LISTSERV that must be replied to with an "OK" in the body of the message. The goal was to reduce the number of unauthorized mailings to this list (spam and viruses). After monitoring the mail list, appears we have met this goal. During the trial, there have been no unauthorized messages (not counting a few test messages). Conversely, there was one reported case when LISTSERV did not respond with the confirmation message within 10 minutes. I believe this was due to the Nimda virus on our servers at that time (we've since cleaned all that up). I will continue to monitor this parameter carefully. If you send a message to the list and don't receive the confirmation message from LISTSERV quickly, please let me know. There was also one known usage error when replying to the confirmation message. Just to be sure, type "OK" without the quote marks on the first line of your confirmation reply to LISTSERV with nothing else on that line. I will also look into clarifying the subscription and other auto-response messages to reduce confusion. We will continue to use the new two-step procedure on this mail list. This method has shown that it offers higher security with low user impact and minimal administration. If you have any comments, please forward them to me. Best Regards, Greg Meyer Intel Corporation greg.w.meyer(a)intel.com -----Original Message----- From: Meyer, Greg W [mailto:greg.w.meyer@INTEL.COM] Sent: Tuesday, October 02, 2001 12:07 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: New ITU-SG16 Mail List Procedures Implemented for Trial Period All ITU-SG16 Mail List Users: Please note that the mail list, itu-sg16(a)mailbag.intel.com, has a new two-step proceedure for sending mail to the list. Here's how it works: 1. Compose your message. 2. Send it to ITU-SG16(a)MAILBAG.INTEL.COM 3. You will receive a "confirmation" message from LISTSERV(a)MAILBAG.INTEL.COM 4. Reply to the confirmation message with "OK" (without the quotes) in the body. OK, that's four steps but only two "sends." Each confirmation message contains the instructions on how to reply. This procedure will help reduce spam and other unauthorized mail. For security purposes, NO ONE should have any mail list (esp. the ITU-SG16 mail list) in their email address book. Most viruses use the address book information to propogate so we strongly request that you look through your address book and remove this and all other mail lists. This new procedure will be tried through the month of October. Please let me know (directly) if there's any mail list service that is being prohited or significantly inhibited. I'll be especially intested in long times (>10 minutes) before receiving the confirmation message. Our testing to date shows that listserv responds quickly. I was strongly(!) motivated to make this change after that last spam ("Excellent Colon Cleanser"). Thanks, Greg Meyer Intel Corporation mailto:greg.w.meyer@intel.com +1.503.264.9506 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [imtch323implementors] Conflict resolution for symmetrical OL Cs - which is the preferred mode?
by Lyons, Terry 01 Nov '01

01 Nov '01

Paul, >From B.2.2.2/H.245v7 again: simultaneousCapabilities is a set of AlternativeCapabilitySet. It is used to list the simultaneous capabilities of the terminal. An AlternativeCapabilitySet is a sequence of CapabilityTableEntryNumbers. Only those CapabilityTableEntrys that have been defined shall be present in an AlternativeCapabilitySet, although it is possible to define CapabilityTableEntrys and refer to them in the same TerminalCapabilitySet. If a terminal has a preference for the mode it would like to transmit or receive, and wishes to express this when transmitting its capabilities, it may do so by listing elements in AlternativeCapabilitySets in order of decreasing preference. So I think you mean to refer to the order in AlternativeCapabilitySet. The question remains: how to compare capabilities that are listed in different AlternativeCapabilitySets. These AlternativeCapabilitySets may occur in different elements of simultaneousCapabilities (unlikely) or in different CapabilityDescriptors (more likely). Would you agree that the preference between two capabilities is structured as follows? 1. compare descriptor numbers - lowest is preferred 2. else compare simultaneousCapability element index - lowest is preferred 3. else compare AlternativeCapabilitySet element index - lowest is preferred There is text in B.2.2.2 to support #1 and #3 of the above. Nothing is said about #2. And since other permutations of logic are possible, some clarification would help. - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 -----Original Message----- From: Paul Long [mailto:plong@IPDIALOG.COM] Sent: Thursday, November 01, 2001 3:04 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: [imtch323implementors] Conflict resolution for symmetrical OLCs - which is the preferred mode? Terry, B.2.2.2 refers to capabilityDescriptors, which are numbered according to preference, whereas C.4.1.3 refers to simultaneousCapabilities, which are arranged in order of preference. There is no conflict. Paul Long ipDialog, Inc. -----Original Message----- From: Lyons, Terry [mailto:TLyons@sonusnet.com] Sent: Thursday, November 01, 2001 10:41 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Cc: 'imtch323implementors(a)mail.imtc.org'; Lyons, Terry Subject: [imtch323implementors] Conflict resolution for symmetrical OLCs - which is the preferred mode? Please consider these two extracts from RECOMMENDATION H.245 - VERSION 7 B.2.2.2 Capability Descriptors If a terminal has a preference for the mode it would like to transmit or receive, and wishes to express this when transmitting its capabilities, it may do so by giving CapabilityDescriptors that relate to its preferred mode or modes small values of capabilityDescriptorNumber. C.4.1.3 Conflict resolution When the master and the slave have indicated choices of receive capabilities for a particular media type, the slave should attempt to open a logical channel for the master's most preferred capability for which it has capability, as given by the order the master has expressed its capabilities; and the master should attempt to open a logical channel for its most preferred capability for which the slave has capability, as given by the order it has expressed its capabilities. --------------------------------------- The new wording "the order the master has expressed its capabilities" is insufficiently defined to act on and seems to conflict with the old definition of prefered mode. As explained in section B.2.1, a terminal's total capabilities may be expressed over an extended period of time, not in a single message (Terminals may dynamically add capabilities during a communication session by issuing additional CapabilityDescriptor structures, or remove capabilities by sending revised CapabilityDescriptor structures). And the capability table entries by themselves are incomplete without accompanying descriptors (The terminal's total capabilities are described by a set of CapabilityDescriptor structures). Both capabililty table entries and capability descriptors are already numbered. Is the Order of Expression an additional attribute that needs to be inferred when processing the pieces of a received Terminal Capability Set? It seems that some clarification is needed. Preferrably, C.4.1.3 should refer back to B.2.2.2 for an operational definition. - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [imtch323implementors] Conflict resolution for symmetrical OLCs - which is the preferred mode?
by Paul Long 01 Nov '01

01 Nov '01

Terry, B.2.2.2 refers to capabilityDescriptors, which are numbered according to preference, whereas C.4.1.3 refers to simultaneousCapabilities, which are arranged in order of preference. There is no conflict. Paul Long ipDialog, Inc. -----Original Message----- From: Lyons, Terry [mailto:TLyons@sonusnet.com] Sent: Thursday, November 01, 2001 10:41 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Cc: 'imtch323implementors(a)mail.imtc.org'; Lyons, Terry Subject: [imtch323implementors] Conflict resolution for symmetrical OLCs - which is the preferred mode? Please consider these two extracts from RECOMMENDATION H.245 - VERSION 7 B.2.2.2 Capability Descriptors If a terminal has a preference for the mode it would like to transmit or receive, and wishes to express this when transmitting its capabilities, it may do so by giving CapabilityDescriptors that relate to its preferred mode or modes small values of capabilityDescriptorNumber. C.4.1.3 Conflict resolution When the master and the slave have indicated choices of receive capabilities for a particular media type, the slave should attempt to open a logical channel for the master's most preferred capability for which it has capability, as given by the order the master has expressed its capabilities; and the master should attempt to open a logical channel for its most preferred capability for which the slave has capability, as given by the order it has expressed its capabilities. --------------------------------------- The new wording "the order the master has expressed its capabilities" is insufficiently defined to act on and seems to conflict with the old definition of prefered mode. As explained in section B.2.1, a terminal's total capabilities may be expressed over an extended period of time, not in a single message (Terminals may dynamically add capabilities during a communication session by issuing additional CapabilityDescriptor structures, or remove capabilities by sending revised CapabilityDescriptor structures). And the capability table entries by themselves are incomplete without accompanying descriptors (The terminal's total capabilities are described by a set of CapabilityDescriptor structures). Both capabililty table entries and capability descriptors are already numbered. Is the Order of Expression an additional attribute that needs to be inferred when processing the pieces of a received Terminal Capability Set? It seems that some clarification is needed. Preferrably, C.4.1.3 should refer back to B.2.2.2 for an operational definition. - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Conflict resolution for symmetrical OLCs - which is the preferred mode?
by Lyons, Terry 01 Nov '01

01 Nov '01

Please consider these two extracts from RECOMMENDATION H.245 - VERSION 7 B.2.2.2 Capability Descriptors If a terminal has a preference for the mode it would like to transmit or receive, and wishes to express this when transmitting its capabilities, it may do so by giving CapabilityDescriptors that relate to its preferred mode or modes small values of capabilityDescriptorNumber. C.4.1.3 Conflict resolution When the master and the slave have indicated choices of receive capabilities for a particular media type, the slave should attempt to open a logical channel for the master's most preferred capability for which it has capability, as given by the order the master has expressed its capabilities; and the master should attempt to open a logical channel for its most preferred capability for which the slave has capability, as given by the order it has expressed its capabilities. --------------------------------------- The new wording "the order the master has expressed its capabilities" is insufficiently defined to act on and seems to conflict with the old definition of prefered mode. As explained in section B.2.1, a terminal's total capabilities may be expressed over an extended period of time, not in a single message (Terminals may dynamically add capabilities during a communication session by issuing additional CapabilityDescriptor structures, or remove capabilities by sending revised CapabilityDescriptor structures). And the capability table entries by themselves are incomplete without accompanying descriptors (The terminal's total capabilities are described by a set of CapabilityDescriptor structures). Both capabililty table entries and capability descriptors are already numbered. Is the Order of Expression an additional attribute that needs to be inferred when processing the pieces of a received Terminal Capability Set? It seems that some clarification is needed. Preferrably, C.4.1.3 should refer back to B.2.2.2 for an operational definition. - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [Megaco] H.248v2
by Christian Groves 31 Oct '01

31 Oct '01

GDay Tom, My suggestion would be rather to have a phone or video conference/s for the issues. That way all active interested parties can attend. As highlighted by others on the list in this current climate some people are unable to travel to meetings. This would also elimate throwing decisions over the fence and people complaining that they weren't part of the process. I had in mind a moderated conference by yourself as Megaco Chairman and Glen Fruendlich as SG16 Q.3 Rapportuer. This conference should be for active participants rather than those just listening in. That way both groups have input and are part of any decisions even if the decisions don't favour them. Regards, Christian Tom-PT Taylor wrote: > > We started to debate H.248v2 this morning. There will definitely be a > document put out for approval in February. At a minimum it will > contain the merged Implementor's Guide and H.248v1. The debate is > over what else it might contain. > > I will ask for time for a WG meeting. We will probably have some > discussion of our own, and we can also tackle some of the less > tractable issues from the list. > > Tom Taylor > taylor(a)nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > _______________________________________________ Megaco mailing list Megaco(a)ietf.org http://www1.ietf.org/mailman/listinfo/megaco

1 0

TD-05 and TD-19 available
by Euchner Martin ICN M SR 3 26 Oct '01

26 Oct '01

Folks, please find attached two TDs. Sorry for posting document here around but, for some couple of days, I have not been able to upload them to the Incoming FTP directory. So if anyone has access, please do on my behalf. Thank you. TD-05 "Agenda SG16 WP2 Q.G Meeting, Dublin, IR, 29 October- 2 November 2001" TD-19 "Liaison to Q.G/16 from SG9 on J.170 Security Issues" Have a good and safe trip to Dublin and CU there! <<TD-5.zip>> <<TD-19.zip>> With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 47713 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany -----------------------------------------------------------------------

2 1

Re: [Megaco] Contribution AVD-2173 -- Implications Of Context At tribute Descri ptors
by Tom-PT Taylor 26 Oct '01

26 Oct '01

You're undoubtedly right on date -- the great IETF legal intercept debate occurred in the fall, following Megaco discussion of the same topic. I had Red Bank in mind, but this is one thing that didn't happen in Red Bank. Nevertheless, the fact that contributions are going in to the present meeting to fill in gaps kind of makes my point. We really didn't think context properties through, so that up to now they haven't had the same solid foundation as termination properties. I'm arguing we need more time to think through the semantic issues at the least, and to make sure that the protocol aspects are as regular as we can make them. Agreed that you can't drop existing properties on the floor. But we can do something like requiring that the new form be used when later-version implementations are talking to each other. -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Thursday, October 25, 2001 9:08 PM To: Taylor, Tom-PT [CAR:B881:EXCH] Cc: 'megaco(a)ietf.org'; 'itu-sg16(a)mailbag.intel.com' Subject: Re: [Megaco] Contribution AVD-2173 -- Implications Of Context Attribute Descri ptors G'Day Tom, For the record context properties were added in August 1999, to put that in context (pardon the pun) the handling of "context" (ie. linking, unlinking) was still being discussed in May 1999. So I don't think it was a last minute addition. I believe that with the contribution to this meeting (AVD-2120) and the ones to the previous meeting on this topic address the concerns in your bullet points. These use already established methods in H.248 to achieve your points (obviously there are some syntax additions). Can you please give some specific examples of what is not covered? Regarding the deprecation of existing context properties I believe this is pretty much out of the question as these are being used in implementations today. Regards, Christian Tom-PT Taylor wrote: > > My apologies for the late delivery of this contribution. For the moment I'm > locked out of the PictureTel server, so here's the text: > > TITLE: Implications Of Context Attribute Descriptors > > ___________________ > > Summary > > This contribution is written to express concern over the proposed inclusion > of context attribute descriptors in H.248v2. This innovation is seen upon > reflection as a major change in the H.248 protocol architecture, and > threatens the coherence of the protocol. > It is proposed as an alternative that we gain further experience by seeing > if it is possible to avoid the specification of new context properties while > solving the problems of MCU decomposition. When we are satisfied that we > can enunciate clear criteria for adding properties to contexts as opposed to > terminations and further, that we are aware of all of the implications of > context properties for the protocol, we can proceed to update the protocol > accordingly. > > 1. Introduction > > H.248v1 defines three context properties: the Topology Descriptor, the > Emergency flag, and the Priority flag. These additions were desirable, but > were made at a fairly late stage in the development of the protocol. As a > result, the work was done in an ad hoc manner and introduced irregularities > into the operation of the protocol. > > Delayed Contribution 129 (Porto Seguro) proposed the introduction of a > context attributes descriptor to contain new context properties and to allow > addition of such properties in packages. On the one hand, the present > contribution argues that this step, while desirable, does not go far enough > to assimilate context properties into the overall protocol structure. On > the other hand, introduction of the ability to define context properties in > packages at this stage in the development of the protocol may cause > confusion and threaten protocol interoperability at a practical level. > > 2. A Complete Implementation Of Context Properties > > A complete implementation of context properties requires that the protocol > satisfy the following requirements: > * there is a well-defined method for setting property values; > * there is a well-defined method for modifying or clearing property > values; > * there is a well-defined method for auditing values that have been > set on a context; > * it would be highly desirable to have a method for determining what > context properties an MG supports. > > Beyond these protocol matters come questions of semantics. We must decide > whether the permissible properties of a context can depend on what media are > flowing in it, or on the properties of the terminations currently in the > context. Since the active streams are a property of a context, we must > decide whether context properties can be associated with specific streams, > and if so, what syntax is used for the purpose. There are undoubtedly other > issues which may come to light. > > As a possibly controversial final step, it would seem desirable to > assimilate the existing context properties into the new syntactic structures > which would evolve. With appropriate requirements for transitional > interworking, the existing syntax for topology and the emergency and > priority flags should be deprecated and counterparts should be defined > within the context attribute descriptor. > > 3. Potential Confusion > > The final point this contribution makes is that if we do not establish a > clear definition within the protocol specification of which properties > should be context attributes and which should be termination properties, > packages will inevitably be defined which solve the same problem with > differing mechanisms. This will be unhelpful to achieving the > interoperability of different implementations. > > 4. Conclusion and Proposal > > Context attributes should be formalized only after careful study of all of > the issues. In concrete terms, this contribution proposes either that the > generalization of context attributes should be left to H.248v3 or else that > H.248v2 be delayed beyond the proposed February 2002 target. > > Tom Taylor > taylor(a)nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > > > _______________________________________________ > Megaco mailing list > Megaco(a)ietf.org > http://www1.ietf.org/mailman/listinfo/megaco ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

[Megaco] Contribution AVD-2173 -- Implications Of Context Attribute Descri ptors
by Tom-PT Taylor 26 Oct '01

26 Oct '01

My apologies for the late delivery of this contribution. For the moment I'm locked out of the PictureTel server, so here's the text: TITLE: Implications Of Context Attribute Descriptors ___________________ Summary This contribution is written to express concern over the proposed inclusion of context attribute descriptors in H.248v2. This innovation is seen upon reflection as a major change in the H.248 protocol architecture, and threatens the coherence of the protocol. It is proposed as an alternative that we gain further experience by seeing if it is possible to avoid the specification of new context properties while solving the problems of MCU decomposition. When we are satisfied that we can enunciate clear criteria for adding properties to contexts as opposed to terminations and further, that we are aware of all of the implications of context properties for the protocol, we can proceed to update the protocol accordingly. 1. Introduction H.248v1 defines three context properties: the Topology Descriptor, the Emergency flag, and the Priority flag. These additions were desirable, but were made at a fairly late stage in the development of the protocol. As a result, the work was done in an ad hoc manner and introduced irregularities into the operation of the protocol. Delayed Contribution 129 (Porto Seguro) proposed the introduction of a context attributes descriptor to contain new context properties and to allow addition of such properties in packages. On the one hand, the present contribution argues that this step, while desirable, does not go far enough to assimilate context properties into the overall protocol structure. On the other hand, introduction of the ability to define context properties in packages at this stage in the development of the protocol may cause confusion and threaten protocol interoperability at a practical level. 2. A Complete Implementation Of Context Properties A complete implementation of context properties requires that the protocol satisfy the following requirements: · there is a well-defined method for setting property values; · there is a well-defined method for modifying or clearing property values; · there is a well-defined method for auditing values that have been set on a context; · it would be highly desirable to have a method for determining what context properties an MG supports. Beyond these protocol matters come questions of semantics. We must decide whether the permissible properties of a context can depend on what media are flowing in it, or on the properties of the terminations currently in the context. Since the active streams are a property of a context, we must decide whether context properties can be associated with specific streams, and if so, what syntax is used for the purpose. There are undoubtedly other issues which may come to light. As a possibly controversial final step, it would seem desirable to assimilate the existing context properties into the new syntactic structures which would evolve. With appropriate requirements for transitional interworking, the existing syntax for topology and the emergency and priority flags should be deprecated and counterparts should be defined within the context attribute descriptor. 3. Potential Confusion The final point this contribution makes is that if we do not establish a clear definition within the protocol specification of which properties should be context attributes and which should be termination properties, packages will inevitably be defined which solve the same problem with differing mechanisms. This will be unhelpful to achieving the interoperability of different implementations. 4. Conclusion and Proposal Context attributes should be formalized only after careful study of all of the issues. In concrete terms, this contribution proposes either that the generalization of context attributes should be left to H.248v3 or else that H.248v2 be delayed beyond the proposed February 2002 target. Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ Megaco mailing list Megaco(a)ietf.org http://www1.ietf.org/mailman/listinfo/megaco

2 1

Re: AVD-2159, 2161, 2162 & 2163 uploaded
by Reddy, Paul K 24 Oct '01

24 Oct '01

Hi Everybody, I have uploaded the following documents into AVS-Site Incoming directory: AVD-2159.zip : Q5/16: Presence Services requirements (Stage1) from 3GPP SA1 group AVD-2161.zip: Q5/16: Mobile Presence and Instant Messaging TOR (Terms of Reference) AVD-2162.zip: Q5/16: XML based protocol for Mobile Presence and Instant messaging AVD-2163.zip: Q5/16: Inter-working function between existing Presence and IM systems (e.g., AOL, MSN etc.) and Mobile Presence and IM systems based on XML based protocols regards, Paul Rapporteur of Q5/16 Intel Labs

1 0

ADV 2106R2
by Folts, Harold 23 Oct '01

23 Oct '01

Greetings, I have made a few more revisions to this document as a result of comments received and translating it into the IETF Internet-Draft format. I uploaded it to the "incoming" directory. See you in Dublin. Hal <<Harold (Hal) C. Folts (E-mail).vcf>>

2 1

Document AVD-2109 has been uploaded
by Sasha Ruditsky 22 Oct '01

22 Oct '01

Hello all! The first version of H.460.3 "Presence in H.323 Systems" has been just uploaded as AVD-2109.zip to ftp://standard.pictel.com/avc-site/Incoming for your review. Best Regards, Sasha Ruditsky RADVISION Inc. TEL: +1.201.529.4300 x 243 FAX: +1.201.529.3516 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AVD-2128, 2129, 2130 uploaded
by Terry L Anderson 22 Oct '01

22 Oct '01

I have uploaded the following documents for the Dublin meeting AVD-2128 H.248 Implementors Guide AVD-2129 Draft of Proposed H.248 Annex M_KA: KeepAlive Package for H.248 AVD-2130 Draft of Proposed LineTest Package for H.248 -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

Re: Documents AVD-2145 uploaded
by BOUGANT François FTRD/DAC/ISS 22 Oct '01

22 Oct '01

Dear all, The following contribution has been uploaded to the "incoming" directory : - AVD-2145 (source: France Telecom ; title : the User Service Profile in Multimedia Management databases ; purpose : proposal) Best regards François Bougant France Telecom ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AVD-2166 upload
by POSE Laurent FTRD/DAC/ISS 22 Oct '01

22 Oct '01

Hello, The following contribution has been uploaded to /Incoming of the ftp site. AVD-2166 Source: FranceTelecom Title: Inconsistency between implementer's guide and H.225.0 on IE Redirecting number, Best Regards, Laurent Posé. France Telecom.

1 0

AVD-2169, 2170 & 2171 uploaded
by CHAPRON Jean-Emmanuel FTRD/DAC/ISS 22 Oct '01

22 Oct '01

Bonjour, Following AVDs have been uploaled to the Incoming Directory at the picturetel site.: 2169 Q.3 H.248 profile for controlling MG between cable networks and PSTN 2170 Q.3 H.248 profile for Audio Servers on cable networks 2171 Q.3 H.248 Annex M.1: speaking digits according to national requirements Regards, Jean-Emmanuel Chapron ``` (o o) ----------oOO--(_)-OOo-------------- Jean-Emmanuel CHAPRON FRANCE TELECOM R&D DAC/ACE 38-40 rue du général Leclerc 92794 Issy-les-Moulineaux Cedex 9 - France Tel: +33 1 45 29 64 50 -------------------------------------

1 0

[Q.3/16][megaco] AVD-2164 Corrections to H.248 Annex F uploaded
by Gunnar Hellstrom 21 Oct '01

21 Oct '01

I have uploaded AVD-2164 Corrections to H.248 Annex F to the incoming directory of the avc-site for the coming Q.3/16 meeting in Dublin. Source: Editor. Content: Additions to H.248 Implementor guide with corrections for minor errors in H.248 Annex F. The contribution contains the corrected Annex as an attachment. Best regards -------------------------- Gunnar Hellström Tel +46 708 204 288 E-mail gunnar.hellstrom(a)omnitor.se WWW: http://www.omnitor.se _______________________________________________ Megaco mailing list Megaco(a)ietf.org http://www1.ietf.org/mailman/listinfo/megaco

1 0

AVD-2172, Open Issues In H.248 Annex M.1
by Tom-PT Taylor 19 Oct '01

19 Oct '01

AVD-2172, Open Issues In H.248 Annex M.1, has been uploaded to the Incoming directory at the PictureTel site. Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490)

1 0

Documents AVD-2144 and AVD-2154 uploaded
by BOUGANT François FTRD/DAC/ISS 19 Oct '01

19 Oct '01

Dear all, The following contributions have been uploaded to the "incoming" directory : - AVD-2144 (source: editor ; title : plan for H.MMS.0 draft ; purpose : proposal) - AVD-2154 (source: editor ; title : technical contents for H.MMS.0 draft ; purpose : proposal and discussion) Best regards François Bougant France Telecom ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AVD-2156 has been uploaded
by OKUBO Sakae 19 Oct '01

19 Oct '01

Dear SG16 experts, AVD-2156 has been uploaded to /Incoming of the PictureTel ftp site: Source: Waseda University Title: Pairing of the "corresponding" RTP channels Purpose: Proposal Abstract: Clarification of the H.323 specification is proposed for the subject matter based on the e-mail discussion following the submission of AVD-2134. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0