home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 97apr / pint-minutes-97apr.txt < prev    next >
Text File  |  1997-05-22  |  6KB  |  125 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.     Minutes of the PSTN/Internet Interworking (pint) BOF 
  4.                 Meeting on April 9, 1997
  5.  
  6.         Reported by I. Faynberg and H. Lu 
  7.                  (Bell Labs, Lucent Technologies)
  8.  
  9.         faynberg@bell-labs.com 
  10.                 huilan.lu@bell-labs.com
  11.  
  12.     The PSTN/Internet Interworking (pint) BOF meeting took place from
  13. 21:00 to 22:00 on Wednesday, April 9. The meeting was chaired by Igor
  14. Faynberg (Bell Labs/Lucent Technologies) and co-chaired by Hui-Lan Lu
  15. (same organization) who also took minutes.  The meeting was attended by
  16. about 90 people.
  17.  
  18.     The goal of the meeting was to discuss two internet drafts:
  19.  
  20.   1) draft-faynberg-telephone-sw-net-00.txt - describing an Internet/PSTN
  21. connection arrangement through which combined Web and traditional
  22. telephony services can be delivered.
  23.                                          
  24.   2) draft-zigmond-media-url-00.txt - describing an URL scheme for telephony.
  25.  
  26.   The discussion of 1) was led by Murali Krishnaswamy (Bell Labs), whose
  27. presentation summarized the relevant internet draft. The questions that
  28. were asked centered around the following issues:
  29.  
  30.     1) The services supported with the proposed arrangement and what
  31.            types of servers would be connected to the PSTN;
  32.            
  33.        Answer: A combination of traditional internet and telephony
  34.            services. A specific example is Web-based Yellow Pages services,
  35.            for which a Web server would be connected to the PSTN.
  36.             
  37.         2) Why cannot the Switch/Computer Application Interface (SCAI) platform
  38.            be used?
  39.  
  40.        Answer: It can. In fact, it is very similar to IN (the proposed
  41.            means of accessing the network), and the protocol used for
  42.            accessing IN could be used for accessing the SCAI architecture.
  43.            The IN arrangement, however, is more powerful because IN controls
  44.            the whole network, while the SCAI application controls a single
  45.            switch. 
  46.  
  47.     3) Why cannot the client place the call?
  48.  
  49.            Answer: It can, of course. But, unless the client is to pay
  50.            for the call--which is contrary to the assumption about the
  51.            types of services, the IN will have to take care of it (e.g., the
  52.            800 number) sooner or later.  It is much better to take care of
  53.            it sooner--and right in the middle of the network rather than
  54.            at the end point. It also allows the network to optimize its
  55.            resources.
  56.  
  57.     4) How does this proposal relate to packet voice?
  58.  
  59.        Answer: It does not.
  60.  
  61.     5) But should we not work in this group on the interconnections between 
  62.            the IP routers and PSTN in order to deliver packet voice across
  63.            the Internet/PSTN boundaries?
  64.  
  65.        Answer: Perhaps we should. But there is no group yet and no
  66.            draft on the table today, and therefore we cannot discuss this 
  67.            kind of interconnection right now.
  68.  
  69.     6) How can the call be placed to the user if user's line is already
  70.            occupied [by the Internet connection]?
  71.  
  72.        Answer: The proposal is meaningful only with the use of an ISDN 
  73.            connection, or voice&data modem, or a digital subscriber line, 
  74.            or some other arrangement (e.g., two voice lines), which leaves
  75.            place for a voice call.
  76.  
  77.     7) So, what are the protocols to be standardized?
  78.            
  79.            Answer: There are two protocols. [As the proposal says:] The 
  80.            TCP/IP-based protocol between the server and Service Node (or 
  81.            Service Control Point), and the SMNP-based protocol between the
  82.            router and the Service Management System.
  83.          
  84.     At the end of a half-an-hour discussion, a large number of 
  85. participants expressed support for carrying out the
  86. work in the IETF, but there was also a sizable opposition to the proposal. 
  87. It was agreed to continue the discussion will continue via e-mail.  The 
  88. self-subscribing e-mail discussion list was to be created by I. Faynberg.
  89. and announced by the IETF. [At the time of publication of these notes, the 
  90. list has been created: pint@lists.research.bell-labs.com.]
  91.  
  92.   The discussion of 2) was led by Dan Zigmond (Wink Technologies). Dan
  93. has introduced his proposal for the URL format for telephony. The following
  94. questions were asked:
  95.  
  96.     1) Is the addressing scheme relative or absolute?
  97.  
  98.        Answer: According to the design it could be either. [A suggestion
  99.            from the audience was that since the proposed addressing 
  100.            follows the design of the "mail-to" addressing, it should
  101.            support be absolute.]
  102.  
  103.     2) Where will this type of URL be used?
  104.  
  105.        Answer: Click-to-dial, automatic billing, for example.
  106.  
  107.     3) It should be useful to specify--within the proposed scheme--the
  108.            attributes for the post-dialing delay, PIN, time to call, and
  109.            the type of the phone (e.g., cellular).
  110.  
  111.        Answer: Yes, that could be done.
  112.  
  113.     4) Why not simply use the phone number as is? Why URL?
  114.  
  115.        Answer: To be able to process things in a preset way (i.e.,
  116.            have the attributes as discussed in 3).
  117.  
  118. The meeting expressed strong support for carrying out the work. It was felt
  119. that the proposed work item was too small to warrant a separate working group.
  120. The discussion leading to a standard will continue via e-mail.  The 
  121. self-subscribing e-mail discussion list will be created by D. Zigmond 
  122. (please send requests to dan.zigmond@wink.com) and announced by the IETF. 
  123.  
  124.  
  125.