July 2002 - sg16-avd - lists.packetizer.com

Re: Multiple parameters on 'a' line: Please do help me understand
by James_Renkel＠3com.com 31 Jul '02

31 Jul '02

Flemming (and other modem experts), Sorry for the delay in responding to this. Been real busy. On 07/12/2002, at 10:21:09 A.M., you wrote, in part: > > > > It's really unambiguous (Assuming ya got all the commas right! :-) ), > > > and > > pretty compact and concise. > > > > All true, but as you note, you'd better not get those commans wrong. It's > fairly error prone and not very easy to debug. Since the SDP is generated and parsed by computers, not humans, getting the commas right is no better or worse than, e.g., getting the spelling of attribute names right. IMHO, not a problem either way, nor is it all that hard to debug either. > > > > On the issue of SIP/SDP transaction size. yah, we're probably OK for now. > > But the way and rate things are being added I'm just afraid we're gonna > > be in trouble soon. > > What kind of trouble ? SIP allows you to use TCP (or SCTP for that matter), so > if UDP fragmentation is your concern, you already have a solution. Also note, > that SIP allows you to use compression to reduce the size of messages, and > clearly, text is fairly compressible. I have several concerns with using either TCP or SCTP rather than UDP here, or with doing anything that might directly or indirectly require the use of TCP or SCTP: 1. As you correctly state, TCP and SCTP are allowed by SIP, while UDP is required. But the result of this is that some endpoints and proxies only implement UDP, and not TCP or SCTP. If TCP or SCTP were required for sessions including MoIP (or the only real alternatives available because of, e.g., transaction sizes), then those endpoints and proxies would have to: - implement TCP or SCTP in order to make their MoIP implementations most useful; or - not implement MoIP. I would prefer to not have to force implementers to make that choice. We can do that by making sure that MoIP works well with UDP. 2. Even if TCP or SCTP were (almost?) required, which one do ya use? Some implementers may choose one, others the other. Again, interopera- bility problems. IMHO, better to stay with one (UDP) that everyone can and does use. 3. For proxies that support thousands or tens of thousands of endpoints simultaneously, it is impractical for them to: - have a TCP connection open to each of them simultaneously, because of resource consumption; and - NOT have a TCP connection open to each of them simultaneously, because of the latency in opening a TCP connection. SCTP has the same problems. Again, the best solution is UDP. 4. In multiport gateways, reusing a single TCP connection for multiple simultaneous sessions has several problems: - TCP requires sequential delivery: if a segment with signaling in it for one session needs to be retransmitted, segments behind it, with signaling for other sessions, are delayed; hence, many sessions can be delayed because of a retransmission in another session's signaling; - TCP rate control is not appropriate for connections that carry signaling for multiple simultaneous sessions and can lead to severe performance problems. SCTP was developed in response to these problems, but is not yet widely supported and deployed. Again, IMHO, UDP is the best solution. I will agree that text in general, SDP in particular, is very compressible and that SIP has good support for message compression. But again, this is an optional capability. If every endpoint and proxy supported it I wouldn't have a problem with relying on it. And while, unlike the use of TCP and SCTP, I strongly support and encourage the use of SIP message compression, I don't think we should be relying on it (Until it's support is mandatory, which I also strongly support and encourage, and is widely deployed! :-) ) > > The SDP isn't so much a problem as the SIP: > > If the problem is not in SDP, then it shouldn't be solved there. As noted > above, there are already solutions to the SIP problem. I didn't say there wasn't *any* problem with the SDP, or that small SDP size could completely solve the problem. But if everybody depends on everybody *else* to solve a shared problem, the problem never gets solved. In fact, the problem may not get solved unless *everybody* *does* contribute to the solution. To the extent that MoIP SDP contributes to the problem, it has to contribute to the solution. As with ecology: think globally, act locally. As noted above, I disagree that the things you noted above are acceptable solutions, except maybe for SIP message compression. Finally, going back to the top of your message: > Given the cons of this > scheme, there would have to be an exceptionally strong motivation for doing it > (which I haven't seen). To my mind, the issues that I've stated above provide more than enough motivation for us to do everything we reasonably can to keep the MoIP SDP size as small as possible. Comments expected and welcome. Jim

1 0

Re: Multiple parameters on 'a' line: Please do help me understand
by James_Renkel＠3com.com 31 Jul '02

31 Jul '02

Mario and other modem experts, There's a subtle point that needs to be made here, and that point is that there is a difference between SPRT being: - used in other specific applications (e.g., FoIP) on a case by case basis; and - available for general use by any application. We (3Com / CommWorks) have no problem with SPRT being used in a specific application such as FoIP, if the fax experts to decide to do so. In the case of FoIP, we see the use of SPRT as valuable and support / encourage its use there. We do have concerns with SPRT being made available for general use by any application, but the packet network transport protocol experts (i.e, the IETF) may decide to do so anyhow, if this were proposed to them. The core of the issue here is that we are modem experts and we have decided to use SPRT for our application, i.e., MoIP. 3Com / Commworks fully supports that. But now we as modem experts, not fax experts or, more importantly, not packet network transport protocol experts, must be careful to not overstep our boundaries: while not precluding the fax experts and the packet network transport protocol experts from using SPRT for their specific or general purposes if they choose to do so, we cannot make their decisions for them or do things in such a way that their opportunity to make their decisions is pre-empted. 3Com / CommWorks strongly opposes anything that would lead to this. Jim Mario Garakani <mgarakan(a)cisco.com> on 07/30/2002 02:26:45 PM Please respond to Mario Garakani <mgarakan(a)cisco.com> Sent by: Mario Garakani <mgarakan(a)cisco.com> To: tr301(a)tiacomm.org cc: tr301(a)tiacomm.org Subject: Re: Multiple parameters on 'a' line: Please do help me understand Mike, We have had a couple of conversations in past TIA and ITU MoIP meetings, where Jim (3com) indicated his opinion that SPRT would be more easily adopted by IETF if it was known to be limited in its application. I agree with this assessment. However, Cisco's has indicated in all past occasions that we "should not" limit SPRT to V.MoIP. There may be other very specific areas where SPRT could be quite useful, such as FoIP or bearer data (hdlc termination). --- Mario Michael_Nicholas(a)3com.com wrote: > Rajesh, > Yes, we see the similarities between FoIP and MoIP, > but in our minds, FoIP is not the proper analogy for MoIP. > Silence Suppression may be a better analogy of extant protocols. > We see MoIP more as a Codec type, not a Media Type. > If Fax is detected, MoIP can switch to FoIP as it exists if MoIP is a Codec > type just as other Codec types such as G.711 or G.723 currently do. This > is not an issue. > > Rajesh, You are now proposing that SPRT will be used non-MoIP? In > previous meetings the issue was brought up that allowing SPRT to be used > for non-MoIP applications would unnecessarily delay MoIP consent due to > much longer and more rigorous IETF examination. Cisco said then that SPRT > would not be used for non-MoIP so that was a non-issue. Now you are making > it an issue again. > > ---------------------- Forwarded by Michael Nicholas/MW/US/3Com on > 07/26/2002 03:57 PM --------------------------- > > "Rajesh Kumar" <rkumar(a)cisco.com> on 07/26/2002 03:31:37 PM > > Please respond to "Rajesh Kumar" <rkumar(a)cisco.com> > > Sent by: "Rajesh Kumar" <rkumar(a)cisco.com> > > To: tr301(a)tiacomm.org > cc: <bfoster(a)cisco.com>, James Renkel/MW/US/3Com, <tr301(a)tiacomm.org>, > <tsg16q11(a)itu.int> > Subject: RE: Multiple parameters on 'a' line: Please do help me understand > > Modem experts, > > I suggest we use an ITU FoIP precedent to resolve this MoIP issue. Attached > is the latest, approved version of ITU T.38. Go to Annex D which formulates > part of the SDP for T.38 as (copied verbatim): > > m=image 49170 udptl t38 > > Mapping this into the RFC 2327 template for the 'm' line (copied verbatim): > > m=<media> <port> <transport> <fmt list> > > we may conclude that, for FoIP, the transport protocol is 'UDPTL' and the > media format is "T.38". > > Since FoIP and MoIP must work seamlessly for the same endpoints, we can > postulate that "SPRT" (more accurately, UDPSPRT) is the transport protocol > and vxxx (based on ITU V.xxx) is the media format. We can create the > following SDP equivalent to the T.38 case: > > m=application 49345 udpsprt 100 > a=sprtmap:100 vxxx/8000 > > Since SPRT can be used in non-MoIP contexts, it behooves us to separate > SPRT > attributes (protocol attributes) from vxxx attributes (media format > attributes). > > Does this seem to be a satisfactory analogy between the FoIP and MoIP > layers? I would think that this would be clear as crystal if we invested > the > effort to examine extant IETF and ITU specifications. > > Rajesh > > | -----Original Message----- > | From: Michael_Nicholas(a)3com.com [mailto:Michael_Nicholas@3com.com] > | Sent: Friday, July 26, 2002 12:44 PM > | To: fandreas(a)cisco.com > | Cc: rkumar(a)cisco.com; bfoster(a)cisco.com; James_Renkel(a)3com.com; > | tr301(a)tiacomm.org; tsg16q11(a)itu.int > | Subject: Re: Multiple parameters on 'a' line: Please do help me > | understand > | > | > | > | Flemming, > | I believe the two questions are dependent on each other > | (SDP representation vs whether MoIP is a Codec or Media type), so > | Please provide us with said opinion and advice on SDP representation. > | Thanks in advance, > | Michael > | > | > | I'm not on the e-mail reflectors and hence haven't followed all the > | discussion, > | so I'd rather not attempt an answer that is out of context. However, I > | understand there is some controversy over the suggested SDP > | representation > | for > | these things, and I'd be happy to provide an outside opinion and > | advice on > | that. > | > | -- Flemming > | > | Michael_Nicholas(a)3com.com wrote: > | > | > Flemming, > | > Thank you for your previous comments. > | > Your last note hints at the basis of our current discussion. > | > Exactly what is V.moip? > | > Is it a Codec type? Is it a Media type? Is it an Application? > | > I'm not sure exactly how well you have been following V.moip > | development, > | > but I think we'd welcome an outside opinion on this. > | > - Mike > | > > | > >> I think this question about the exact formatting of > | parameters is less > | > >> important than some of the other differences between the proposals > | such > | > as > | > >> Codec declaration, the need or lack of need for capability sets, > and > | the > | > >> number and numbering of UDP ports. > | > >> > | > > > | > >I agree with that. Incidentally, I also agree that codecs should be > | > declared > | > >and there shouldn't be any unnecessary port restrictions. > | > > > | > >-- Flemming > |

1 0

Re: ITU-T Q2/16 Rapporteur's Meeting Announcement
by OKUBO Sakae 27 Jul '02

27 Jul '02

Dear Mr. Jones and all, At 00:23 -0400 02/07/26, Paul E. Jones wrote: >[...] > --------------------------------------------------------------------- > Subject: Notice of ITU-T Q2/16 Rapporteur Meeting in Raleigh, NC, USA > Date: 25 July 2002 > --------------------------------------------------------------------- >[...] For this meeting, a new directory 0208_Ral has been created and the meeting notice has been placed there: http://standard.pictel.com/ftp/avc-site/0208_Ral/Notice_Raleigh_0208.txt Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ****************************************************************** YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagwa-ken Fax: +81 468 47 5413 239-0847 Japan Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. Tel: +81 3 3204 8194 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************

1 0

RESEND: ITU-T Q2/16 Rapporteur's Meeting Announcement
by Paul E. Jones 27 Jul '02

27 Jul '02

Folks, Apparently, this message did not reach everybody on the mailing list, so I am sending it once again. Hopefully, it will get through this time. Best Regards, Paul ==================================================================== To Experts of ITU-T Q2/SG16 Experts of ITU-T Q3/SG16 Experts of ITU-T Q11/SG16 Experts of TR30.1 Cc Mr. P-A. Probst, Chairman of SG16 <probst-pa(a)bluewin.ch> Mr. G. Wreikat, Vice-Chairman of SG16 <wreikat(a)hotmail.com> Mr. F. Tosco, Chairman of WP2/16 <Federico.Tosco(a)tilab.com> Mr. S. Campos-Neto, ITU TSB <simao.campos(a)itu.int> Mr. T. Anderson, expected Rapporteur Q3/16 <tla(a)lucent.com> Mr. S. Okubo, Rapporteur Q4/16 <okubo(a)giti.waseda.ac.jp> Mr. L. Brown, Rapporteur Q11/16 <lesbrown(a)sympatico.ca> De P Jones, Rapporteur for Q.2/16 <paulej(a)packetizer.com> --------------------------------------------------------------------- Subject: Notice of ITU-T Q2/16 Rapporteur Meeting in Raleigh, NC, USA Date: 25 July 2002 --------------------------------------------------------------------- Dear Experts of Questions 2/16, Q3/11, Q11/16, and TIA TR30.1, An ITU-T Q2/SG16 experts meeting will be held in Raleigh, NC, USA, at the offices of Cisco Systems, Inc. in order to progress the work of modem over IP (MoIP). Unlike other Rapporteur's meetings, this will only be a two day meeting that is focused strictly on the topic of MoIP. I would kindly like to ask that if you have any documents that you want to discuss, but which are not related to MoIP, that you make those available at the upcoming SG16 meeting to be held in October 2002. As the topic of modem over IP is of interest to experts from Q3/16, Q11/16, and TIA30.1, I have opened this meeting to those experts as well. 1. Date ^^^^^^^ 19 (Monday) August - 20 (Tuesday) August 2002 Meeting will start at 9:00 AM each day, closing around 18:00 each day. 2. Venue ^^^^^^^^ Cisco Systems, Inc. Valley Building (Building 7) 7025 Kit Creek Rd Research Triangle Park, NC 27709 Tel: +1 919 472 2000 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Progress work on Annex P/H.323 2) Progress work on proposed additions to H.245 to support MoIP, including the "Multiple Payload Stream" concept 3) Progress work on H.460.6 (Extended Fast Connect) 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 12 August 2002 /// /// Distribution of the document: by 23:59 UTC, 14 August 2002 /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify Sakae Okubo <okubo(a)giti.waseda.ac.jp>, document manager of this meeting, as soon as possible, by 23:59 UTC, Wednesday 12 August 2002 at the latest. Document number AVD-nnnn will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "AVD" comes from Audio, Video and Data. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document AVD-{nnnn}| | Study Group 16 {Version m if relevant}| | Q2/16 Rapporteur Meeting {Date}| | Raleigh, 19-20 August 2002 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All contributors are requested to distribute documents as early as possible: at least 5 calendar days in advance of the meeting (23:59 UTC, 14 Augsut 2002 or before). Please post them at either of the following: - PictureTel ftp site (please advise Mr. Okubo of your posting) Site: standard.pictel.com/avc-site Login name: anonymous Directory: Incoming - Intel e-mail reflector e-mail address: itu-sg16(a)echo.jf.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /0208_Ral directory of the ftp site once Mr. Okubo has an opportunity to put them into place. 5) The document distribution at the meeting will be electronic. Participants must bring along their laptop, Ethernet card, and Ethernet cable. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ The meeting will be held on Cisco System's Research Triangle Park (RTP) campus. The nearest airport is the Raleigh/Durham International Airport. The airport code is "RDU". Driving directions from the airport to Cisco Systems: o Depart the airport on Airport Boulevard towards I-40 o At the I-40 intersection, turn right (West) on I-40 o Travel west to the Davis Drive (Exit 280) o At the top of the exit ramp is a traffic signal o At that signal, turn left (South) onto Davis Drive o Proceed 3.5 miles on Davis Drive to Kit Creek Road intersection o Turn right onto Kit Creek Road o Turn right at the third entrance on the right for Cisco buildings 7, 8, and 9. (The first two entrances on the right are not part of the Cisco campus.) Approximate total distance from the airport is 8 miles, with a driving time of approximately 15 minutes during non-rush hour traffic. There are rental cars and taxis available at the airport. Some hotels also offer a shuttle service between the hotel and the airport. When arriving at the Valley Building (Building 7) each morning, please inform the receptionist that you are there for the ITU meeting and you will be issued a visitor badge. We will meet in the lobby at 9AM before proceeding to the meeting room. 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send e-mail to Paul E. Jones <paulej(a)packetizer.com>, providing the family name, given name, company name, and e-mail address of person(s) attending. 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ There is no particular hotel reserved for attendees at this meeting. However, there are number from which you may choose: Hampton Inn 1010 Airport Blvd Morrisville, NC 27560 (919) 462-1620 Holiday Inn-Express 1014 Airport Blvd. Morrisville, NC 27560 919) 653-2260 LaQuinta Inn-RDU 1001 Hospitality Ct, off Airport Blvd Morrisville, NC 27560 (919) 461-1771 Holiday Inn-RTP 4810 Old Page Road Research Triangle Park, NC 27709 (919) 941-6000 Radisson Governors Inn PO Box 12168 I-40 at Davis Dr, Exit 280 Research Triangle Park, NC 27709 (919) 549-8631 800-333-3333 (Toll Free) Sheraton Imperial Hotel 4700 Emperor Boulevard, off Page Road Research Triangle Park, NC 27709 (919) 941-5050 Wyndham Garden Hotel 4620 South Miami Blvd. Research Triangle Park, NC 27709 (919) 941-6066 Marriott at RTP 4700 Guardian Drive Research Triangle Park, NC 27709 (919) 941-6200 Doubletree Guest Suites 2515 Meridian Parkway Durham, NC 27703 (919) 361-4660 Embassy Suites Cary 201 Harrison Oaks Cary, NC 27513 (919) 677-1840 I look forward to seeing with you in Raleigh. Sincerely yours, Paul Jones ----------

1 0

ITU-T Q2/16 Rapporteur's Meeting Announcement
by Paul E. Jones 26 Jul '02

26 Jul '02

To Experts of ITU-T Q2/SG16 Experts of ITU-T Q3/SG16 Experts of ITU-T Q11/SG16 Experts of TR30.1 Cc Mr. P-A. Probst, Chairman of SG16 <probst-pa(a)bluewin.ch> Mr. G. Wreikat, Vice-Chairman of SG16 <wreikat(a)hotmail.com> Mr. F. Tosco, Chairman of WP2/16 <Federico.Tosco(a)tilab.com> Mr. S. Campos-Neto, ITU TSB <simao.campos(a)itu.int> Mr. T. Anderson, expected Rapporteur Q3/16 <tla(a)lucent.com> Mr. S. Okubo, Rapporteur Q4/16 <okubo(a)giti.waseda.ac.jp> Mr. L. Brown, Rapporteur Q11/16 <lesbrown(a)sympatico.ca> De P Jones, Rapporteur for Q.2/16 <paulej(a)packetizer.com> --------------------------------------------------------------------- Subject: Notice of ITU-T Q2/16 Rapporteur Meeting in Raleigh, NC, USA Date: 25 July 2002 --------------------------------------------------------------------- Dear Experts of Questions 2/16, Q3/11, Q11/16, and TIA TR30.1, An ITU-T Q2/SG16 experts meeting will be held in Raleigh, NC, USA, at the offices of Cisco Systems, Inc. in order to progress the work of modem over IP (MoIP). Unlike other Rapporteur's meetings, this will only be a two day meeting that is focused strictly on the topic of MoIP. I would kindly like to ask that if you have any documents that you want to discuss, but which are not related to MoIP, that you make those available at the upcoming SG16 meeting to be held in October 2002. As the topic of modem over IP is of interest to experts from Q3/16, Q11/16, and TIA30.1, I have opened this meeting to those experts as well. 1. Date ^^^^^^^ 19 (Monday) August - 20 (Tuesday) August 2002 Meeting will start at 9:00 AM each day, closing around 18:00 each day. 2. Venue ^^^^^^^^ Cisco Systems, Inc. Valley Building (Building 7) 7025 Kit Creek Rd Research Triangle Park, NC 27709 Tel: +1 919 472 2000 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Progress work on Annex P/H.323 2) Progress work on proposed additions to H.245 to support MoIP, including the "Multiple Payload Stream" concept 3) Progress work on H.460.6 (Extended Fast Connect) 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 12 August 2002 /// /// Distribution of the document: by 23:59 UTC, 14 August 2002 /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify Sakae Okubo <okubo(a)giti.waseda.ac.jp>, document manager of this meeting, as soon as possible, by 23:59 UTC, Wednesday 12 August 2002 at the latest. Document number AVD-nnnn will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "AVD" comes from Audio, Video and Data. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document AVD-{nnnn}| | Study Group 16 {Version m if relevant}| | Q2/16 Rapporteur Meeting {Date}| | Raleigh, 19-20 August 2002 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All contributors are requested to distribute documents as early as possible: at least 5 calendar days in advance of the meeting (23:59 UTC, 14 Augsut 2002 or before). Please post them at either of the following: - PictureTel ftp site (please advise Mr. Okubo of your posting) Site: standard.pictel.com/avc-site Login name: anonymous Directory: Incoming - Intel e-mail reflector e-mail address: itu-sg16(a)echo.jf.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /0208_Ral directory of the ftp site once Mr. Okubo has an opportunity to put them into place. 5) The document distribution at the meeting will be electronic. Participants must bring along their laptop, Ethernet card, and Ethernet cable. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ The meeting will be held on Cisco System's Research Triangle Park (RTP) campus. The nearest airport is the Raleigh/Durham International Airport. The airport code is "RDU". Driving directions from the airport to Cisco Systems: o Depart the airport on Airport Boulevard towards I-40 o At the I-40 intersection, turn right (West) on I-40 o Travel west to the Davis Drive (Exit 280) o At the top of the exit ramp is a traffic signal o At that signal, turn left (South) onto Davis Drive o Proceed 3.5 miles on Davis Drive to Kit Creek Road intersection o Turn right onto Kit Creek Road o Turn right at the third entrance on the right for Cisco buildings 7, 8, and 9. (The first two entrances on the right are not part of the Cisco campus.) Approximate total distance from the airport is 8 miles, with a driving time of approximately 15 minutes during non-rush hour traffic. There are rental cars and taxis available at the airport. Some hotels also offer a shuttle service between the hotel and the airport. When arriving at the Valley Building (Building 7) each morning, please inform the receptionist that you are there for the ITU meeting and you will be issued a visitor badge. We will meet in the lobby at 9AM before proceeding to the meeting room. 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send e-mail to Paul E. Jones <paulej(a)packetizer.com>, providing the family name, given name, company name, and e-mail address of person(s) attending. 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ There is no particular hotel reserved for attendees at this meeting. However, there are number from which you may choose: Hampton Inn 1010 Airport Blvd Morrisville, NC 27560 (919) 462-1620 Holiday Inn-Express 1014 Airport Blvd. Morrisville, NC 27560 919) 653-2260 LaQuinta Inn-RDU 1001 Hospitality Ct, off Airport Blvd Morrisville, NC 27560 (919) 461-1771 Holiday Inn-RTP 4810 Old Page Road Research Triangle Park, NC 27709 (919) 941-6000 Radisson Governors Inn PO Box 12168 I-40 at Davis Dr, Exit 280 Research Triangle Park, NC 27709 (919) 549-8631 800-333-3333 (Toll Free) Sheraton Imperial Hotel 4700 Emperor Boulevard, off Page Road Research Triangle Park, NC 27709 (919) 941-5050 Wyndham Garden Hotel 4620 South Miami Blvd. Research Triangle Park, NC 27709 (919) 941-6066 Marriott at RTP 4700 Guardian Drive Research Triangle Park, NC 27709 (919) 941-6200 Doubletree Guest Suites 2515 Meridian Parkway Durham, NC 27703 (919) 361-4660 Embassy Suites Cary 201 Harrison Oaks Cary, NC 27513 (919) 677-1840 I look forward to seeing with you in Raleigh. Sincerely yours, Paul Jones ----------

1 0

sourceInfo in LRQ
by Francois Audet 26 Jul '02

26 Jul '02

Is the sourceInfo in LRQ intended to indicate the identity of the Gatekeeper sending the LRQ, or the identify of the remote calling user which causes its gatekeeper to send the LRQ because it can't resolve the address? If the response is the gatekeeper (as I think), it seems to me that the gatekeeper receiving the LRQ will only be able to respond positively to it if it has sufficient context information in the LRQ (for example, if the LRQ contains a national number, it doesn't have enough context information). Any comments? ---- François AUDET, Nortel Networks Tel: +1 408 495 3756 <http://mpkwww.us.nortel.com/~audet/index.html>

2 1

Re: editor's copy of H.248.1
by OKUBO Sakae 23 Jul '02

23 Jul '02

Dear Mr. Anderson, At 15:00 -0400 02/07/23, Terry L Anderson wrote: >I cannot find a copy of pl-036r1, the editor's copy of H.248 Corregendum 1 >(that later became H.248.1) on the 0202_Gen site. I have uploaded a copy >to Incoming as > pl-036r1_h248_1.zip >Could you please arrange to have it moved to the 0202_Gen directory? It has been moved as requested. The index file 0202_Gen.html will be updated accordingly (currently I cannot access the server via ftp, though http is ok). Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ****************************************************************** YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 468 47 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagwa-ken Fax: +81 468 47 5413 239-0847 Japan Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. Tel: +81 3 3204 8194 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************

1 0

remove
by M. Sorbas 13 Jul '02

13 Jul '02

1 0

FW: Update notification from the ITU Web site for simao.campos@it u.int
by Campos, Simao 10 Jul '02

10 Jul '02

Dear colleagues, Two circulars that affect the SG16 work have been published: the schedule of meetings for next year and the anouncement of a workshop in December on Satellite in IP and Multimedia. Please see below. Best regards, Simao -----Original Message----- From: ITU Web Notification system [mailto:websupport@itu.int] Sent: 10 July 2002 03:04 To: simao.campos(a)itu.int Subject: Update notification from the ITU Web site for simao.campos(a)itu.int UPDATE NOTIFICATION for simao.campos(a)itu.int The following files have been updated since 2002-07-09 System : itudoc Group : itu-t updated : 2002-07-09 14:48:59 title : [117] Schedule of ITU-T meetings for 2003 url : http://www.itu.int/itudoc/itu-t/circ/01-04_1/117.html ------------------------------------------------------------- System : itudoc Group : itu-t updated : 2002-07-09 14:29:05 title : [110] Workshop on Satellites in IP and Multimedia, Geneva, 9 - 11 December 2002 url : http://www.itu.int/itudoc/itu-t/circ/01-04_1/110.html ------------------------------------------------------------- Note : you are receiving this e-mail because you have subscribed to the ITU notification system for new documents. If you want to change or cancel your notification e-mails , please proceed as follows : 1) log on from http://www.itu.int/tiesutils/asp/login.asp 2) from the Account Option, select Update Notification 3) select/unselect areas for which you want to be notified for new updates For further help, please contact TIES Helpdesk Service at helpdesk(a)itu.int or go to http://www.itu.int/TIES/ for documentation. Thank you

1 0

Re: IM and T.140
by Eli Orr 03 Jul '02

03 Jul '02

SIP/SIMPLE is most likely to be the most popular. MS selected it and it re-uses of existing infrastructure (proxies etc.). There are standards and there are standards de facto. Where JABBER fits in? >From practical indistry point of view H.323 UNI solution (e.g. based GEF.3 well defined) will enable H.323 Terminal developers to I/F with SIMPLE based solution. >From user point of view (He decides the future of this): Great multimedia and conferencing solutions (H.323) powered available IM/presence services. -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Wednesday, June 26, 2002 12:22 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: IM and T.140 "Instant messaging" in general is a really crowded field of endeavour. The IETF had nine different protocol proposals in fromt of it. After a heroic effort these reduced to three. Now JABBER is attempting to expand the field again. The IETF has defined a framework for presence and instant messaging to make it easier for all of them to interwork. I suppose at some point we should look at how T.140 might be brought into line with this framework. -----Original Message----- From: Paul Long [mailto:plong@IPDIALOG.COM] Sent: Friday, June 21, 2002 3:29 PM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: IM and T.140 What's the difference between "instant messaging" in general and T.140? IOW, what can you do with one that you can't do with the other? Paul Long ipDialog, Inc.

1 0