- sg16-avd - lists.packetizer.com

Potential Addressing Issue
by Tom Taylor 18 Dec '97

18 Dec '97

I was going over my notes for the IETF MMUSIC session last week, and came across an item which may be an issue for H.323. Thanks to the presence of Network Address Translation (NAT) in the net, an endpoint doesn't necessarily know its true network address. (NAT boxes translate between local addresses and public ones invisibly to the hosts concerned.) Thus the address an H.323 endpoint sends out during registration with the Gatekeeper may be bogus.

1 0

Re: Fast Start issues
by Tom Taylor 18 Dec '97

18 Dec '97

I have what may be a simple-minded question relating to the availability of media before CONNECT. In a situation where the called party is on the GSTN, the terminating switch may return announcements or tones under some circumstances. In an all-GSTN situation the caller would hear these without getting billed. As a typical example, an announcement might inform the subscriber that "The number you have reached is not in service". Can we achieve this result with Fast Start, without triggering billing? >-----Original Message----- >From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] >Sent: Thursday, December 18, 1997 8:45 AM >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Fast Start issues > >Scott, > >Thanks for your lengthy reply... > >What I was hoping to indicate was that for certain call scenarios you >want media established before CONNECT, but for other scenarios this is >not possible. > >A situation where you have to send CONNECT before the media is >negotiated is when multiple phones are rang and the first one is >answered. There are probably others. > >The point is that some flexibility is required on this point. > >I agree with your comments about mandating that fast start should allow >for H.245 to be started at any time. I didn't contest the wording as it >seemed to me that whatever wording was in the standard, if it suited a >vendor they could quite easily ignore any request to do fast start. >This would total destroy any attempt to deliver some services and is >hence a problem for us. > >I'm also interested that you state that you are looking for light-weight >systems that do not use H.245. Firstly this is in conflict with the >wording at the moment. Secondly, it is only an illusion of a simpler >implementation, as much of H.245 is being copied into H.225 (work out >how much of H.245 is included into H.225 just by referencing >Capability). > >As to how CONNECT works in the switched network, it seems that the >called endpoint sends CONNECT before the bearer path is in place. The >final switch will connect the bearer when it receives CONNECT. The >CONNECT is then forwarded. The point is that the CONNECT is sent before >the bearer is connected through, but the bearer is connect through by >the time CONNECT is received. This is difficult to emulate in our >environment. You can't just delay the CONNECT in the gatekeeper until >the media is established because the user is concerned with the time >from 'picking up the handset' to when they can speak and are not >concerned with how this relates to the timing of the CONNECT message. >Some one said the switched network delay in this instance is less than >100ms. > >Regards, > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > > >>---------- >>From: Scott Petrack[SMTP:Scott_Petrack@VOCALTEC.COM] >>Sent: 18 December 1997 01:52 >>To: ITU-SG16(a)MAILBAG.INTEL.COM >>Subject: Fast Start issues >> >>Friends, and especially Pete, >> >>It really does seem to me that it is possible to get everyone happy. I >>would like to try and convince you (Pete) that: >> a. you can get EXACTLY what you need, in the fastest, most correct >>way >>possible, right now, and >> b. Intel's FastStart is really an important and useful thing as is >>for >>H.323. >> >>It is possible that a single sentence needs to be added to the >>FastStart >>text (see below in the paragraph starting "The thing that you >>require..."). >>But mainly I believe that there is a small misunderstanding going on, >>which >>is main the source of the problem. >> >>Pete, to get this extra "intelligence" you want, I believe that in most >>cases you must use gatekeeper routed signalling. The called gatekeeper, >>acting as a proxy for the called user, must send the H.245 port in the >>CallProceeding message, H.245 negotiation must be used, and the CONNECT >>message must come at the end, after all location/media negotiations are >>over and media is available. >> >>I say "in most cases" because there are some cases where you will >>probably >>choose to do some intelligence in the LRQ phase, before the CallSetup >>is >>sent. In these cases it might be possible to know that the CallSetup >>message is really being sent to the correct Terminal, and so you can >>then >>use FastStart to that Terminal. There are also other cases where you >>may >>choose to do FastStart with to the user's gatekeeper, have the >>gatekeeper >>play out a prompt saying something like "we are looking for your user >>now", >>have the gatekeeper do H.245 negotiation with the caller on behalf of >>the >>callee, and in the end establish a new media channel to the final >>negotiated endpoint, breaking the original media channel negotiated >>with >>the gatekeeper in the FastStart. All this can be done now by using a >>combination of FastStart and "classic" H.323 signalling. >> >>The "misunderstanding" I was alluding to earlier is this: you are >>correct >>that most endpoints until now unfortunately did CONNECT before media >>negotiation. This is a very unfortunate breaking of Q.931 semantics >>which >>could have been avoided, and we should try hard to return to the normal >>situation where CONNECT is sent only at the end of the entire call >>establishment procedure. My problem is with the 2nd requirement you >>gave in >>an earlier posting: >> >>>we want to delay establishing media until after >>>CONNECT so that the gatekeeper can do some intelligent stuff. >> >>I definitely DON'T want to delay establishing media until after >>CONNECT. >>And I claim that this is NOT needed for the gatekeeper to do some >>intelligent stuff. >> >>The thing that you require, that is not quite there in the current >>FastStart proposal, is that "even if a connection is made using >>FastStart, >>it shall be possible for either endpoint to start H.245 negotiation at >>any >>point in the conversation". I would be willing to go with this in the >>spirit of compromise. (although personally I feel that such "shalls" >>are >>about as strong as "An H.uman endpoint shall not eat pork." Lot's of >>people >>who claim "Bible compliance" do not follow this shall, and somehow the >>world continues to interoperate...) >> >>We at VocalTec, as part of our CMA work, support many of the scenarios >>you >>talk about, and we do it quite quickly (we think as quickly as >>logically >>possible in fact). Some of them require H.245, some require gatekeeper >>routed signalling, some can be done with FastStart alone. >> >>I want to go on record saying that we DEFINITELY want to encourage >>finishing the H.245 negotiation before CONNECT if it happens. This >>function >>is in H.323 now, and it is *the thing* that allows us to do the >>scenarios >>that Pete seems to want. We believe that this is how complex services >>will >>have to work in H.323. This allows H.245 and H.225 to go completely >>independently and in parallel, and the poor CONNECT message can just be >>the >>final word saying "you're on the air". Logically, if you need H.245 for >>your call, this is the fastest possible way to get it. >> >>You may be thinking, quite correctly "If Scott thinks that the next >>generation of terminals is going to do H.245 before CONNECT then why in >>the >>world does he need FastStart?" This is a good question, but it has a >>very >>good answer (I'll bet you thought I would have one....) >> >>We perceive an absolute market requirement for the shortest, simplest, >>fastest, lightweightest, stupidest kind of Internet Telephones, and >>that a >>system that cannot support such devices will be very vunerable to >>attack >>from competing systems that can. It is very important to be able to >>build >>"dumb telephone systems" as well as "intelligent ones". FastStart is a >>great step forward for dumbness ;-). (sorry Jim). >> >>At the risk of repeating myself, even in the some of the scenarios Pete >>mentions it is useful to use FastStart. It allows a gatekeeper to >>answer >>immediately (i.e. "as fast as possible") and reassure the caller that >>although the system may take a few seconds to find the user and >>negotiate, >>this is being done. This is the way to port standard call center stuff >>to >>IP seamlessly. The "call center gatekeeper" answers in one round trip >>with >>FastStart, sends a CONNECT, and then the ACD-function starts up the >>real >>H.245 as part of its thing while blasting out music on hold. >> >>The gatekeeper can do intelligent stuff by bringing up H.245 BEFORE the >>CONNECT message. We believe that we in the H.323 community should do >>everything possible to return the CONNECT message to its true Q.931 >>meaning >>of "you have end to end bearer NOW." The little fight over billing we >>had >>at SunRiver is only one of the issues. It is very confusing for people >>and >>systems to have CONNECT all of a sudden mean something else. Granted, >>there >>is nothing that we can do now about v1 systems, but we believe very >>deeply >>that every effort should be made to delay CONNECT until all >>media/location >>decisions are over, there is bearer, and talking/seeing can occur. This >>is >>what the CONNECT message is about. The fact is that it is possible to >>do >>H.245 upon CallSetup, and the system can take as long as it needs to do >>"intelligence" before the CONNECT message. Remember that these >>intelligent >>things take some time, at least a few round trips, and in our >>experience if >>you start doing them you have plenty of time to negotiate media via >>H.245. >> >>I hope that it is clearer now why I have a problem with any scheme to >>"delay establishing media until after the CONNECT message." This is a >>bad >>habit that we need to end. I hope too that it is clearer why I like the >>FastStart. We need good old dumb "black telephone service." If you >>have >>been listening to the IETF noise over this issue, you will know that >>this >>attack on H.323 is being taken seriously by many customers. Fast Start >>answers that attack and adds a real new feature to H.323. >> >>Sincerely, >> >>Scott Petrack >>

1 0

Re: Fast Start issues
by Pete Cordell 18 Dec '97

18 Dec '97

Scott, Thanks for your lengthy reply... What I was hoping to indicate was that for certain call scenarios you want media established before CONNECT, but for other scenarios this is not possible. A situation where you have to send CONNECT before the media is negotiated is when multiple phones are rang and the first one is answered. There are probably others. The point is that some flexibility is required on this point. I agree with your comments about mandating that fast start should allow for H.245 to be started at any time. I didn't contest the wording as it seemed to me that whatever wording was in the standard, if it suited a vendor they could quite easily ignore any request to do fast start. This would total destroy any attempt to deliver some services and is hence a problem for us. I'm also interested that you state that you are looking for light-weight systems that do not use H.245. Firstly this is in conflict with the wording at the moment. Secondly, it is only an illusion of a simpler implementation, as much of H.245 is being copied into H.225 (work out how much of H.245 is included into H.225 just by referencing Capability). As to how CONNECT works in the switched network, it seems that the called endpoint sends CONNECT before the bearer path is in place. The final switch will connect the bearer when it receives CONNECT. The CONNECT is then forwarded. The point is that the CONNECT is sent before the bearer is connected through, but the bearer is connect through by the time CONNECT is received. This is difficult to emulate in our environment. You can't just delay the CONNECT in the gatekeeper until the media is established because the user is concerned with the time from 'picking up the handset' to when they can speak and are not concerned with how this relates to the timing of the CONNECT message. Some one said the switched network delay in this instance is less than 100ms. Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Scott Petrack[SMTP:Scott_Petrack@VOCALTEC.COM] >Sent: 18 December 1997 01:52 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Fast Start issues > >Friends, and especially Pete, > >It really does seem to me that it is possible to get everyone happy. I >would like to try and convince you (Pete) that: > a. you can get EXACTLY what you need, in the fastest, most correct >way >possible, right now, and > b. Intel's FastStart is really an important and useful thing as is >for >H.323. > >It is possible that a single sentence needs to be added to the >FastStart >text (see below in the paragraph starting "The thing that you >require..."). >But mainly I believe that there is a small misunderstanding going on, >which >is main the source of the problem. > >Pete, to get this extra "intelligence" you want, I believe that in most >cases you must use gatekeeper routed signalling. The called gatekeeper, >acting as a proxy for the called user, must send the H.245 port in the >CallProceeding message, H.245 negotiation must be used, and the CONNECT >message must come at the end, after all location/media negotiations are >over and media is available. > >I say "in most cases" because there are some cases where you will >probably >choose to do some intelligence in the LRQ phase, before the CallSetup >is >sent. In these cases it might be possible to know that the CallSetup >message is really being sent to the correct Terminal, and so you can >then >use FastStart to that Terminal. There are also other cases where you >may >choose to do FastStart with to the user's gatekeeper, have the >gatekeeper >play out a prompt saying something like "we are looking for your user >now", >have the gatekeeper do H.245 negotiation with the caller on behalf of >the >callee, and in the end establish a new media channel to the final >negotiated endpoint, breaking the original media channel negotiated >with >the gatekeeper in the FastStart. All this can be done now by using a >combination of FastStart and "classic" H.323 signalling. > >The "misunderstanding" I was alluding to earlier is this: you are >correct >that most endpoints until now unfortunately did CONNECT before media >negotiation. This is a very unfortunate breaking of Q.931 semantics >which >could have been avoided, and we should try hard to return to the normal >situation where CONNECT is sent only at the end of the entire call >establishment procedure. My problem is with the 2nd requirement you >gave in >an earlier posting: > >>we want to delay establishing media until after >>CONNECT so that the gatekeeper can do some intelligent stuff. > >I definitely DON'T want to delay establishing media until after >CONNECT. >And I claim that this is NOT needed for the gatekeeper to do some >intelligent stuff. > >The thing that you require, that is not quite there in the current >FastStart proposal, is that "even if a connection is made using >FastStart, >it shall be possible for either endpoint to start H.245 negotiation at >any >point in the conversation". I would be willing to go with this in the >spirit of compromise. (although personally I feel that such "shalls" >are >about as strong as "An H.uman endpoint shall not eat pork." Lot's of >people >who claim "Bible compliance" do not follow this shall, and somehow the >world continues to interoperate...) > >We at VocalTec, as part of our CMA work, support many of the scenarios >you >talk about, and we do it quite quickly (we think as quickly as >logically >possible in fact). Some of them require H.245, some require gatekeeper >routed signalling, some can be done with FastStart alone. > >I want to go on record saying that we DEFINITELY want to encourage >finishing the H.245 negotiation before CONNECT if it happens. This >function >is in H.323 now, and it is *the thing* that allows us to do the >scenarios >that Pete seems to want. We believe that this is how complex services >will >have to work in H.323. This allows H.245 and H.225 to go completely >independently and in parallel, and the poor CONNECT message can just be >the >final word saying "you're on the air". Logically, if you need H.245 for >your call, this is the fastest possible way to get it. > >You may be thinking, quite correctly "If Scott thinks that the next >generation of terminals is going to do H.245 before CONNECT then why in >the >world does he need FastStart?" This is a good question, but it has a >very >good answer (I'll bet you thought I would have one....) > >We perceive an absolute market requirement for the shortest, simplest, >fastest, lightweightest, stupidest kind of Internet Telephones, and >that a >system that cannot support such devices will be very vunerable to >attack >from competing systems that can. It is very important to be able to >build >"dumb telephone systems" as well as "intelligent ones". FastStart is a >great step forward for dumbness ;-). (sorry Jim). > >At the risk of repeating myself, even in the some of the scenarios Pete >mentions it is useful to use FastStart. It allows a gatekeeper to >answer >immediately (i.e. "as fast as possible") and reassure the caller that >although the system may take a few seconds to find the user and >negotiate, >this is being done. This is the way to port standard call center stuff >to >IP seamlessly. The "call center gatekeeper" answers in one round trip >with >FastStart, sends a CONNECT, and then the ACD-function starts up the >real >H.245 as part of its thing while blasting out music on hold. > >The gatekeeper can do intelligent stuff by bringing up H.245 BEFORE the >CONNECT message. We believe that we in the H.323 community should do >everything possible to return the CONNECT message to its true Q.931 >meaning >of "you have end to end bearer NOW." The little fight over billing we >had >at SunRiver is only one of the issues. It is very confusing for people >and >systems to have CONNECT all of a sudden mean something else. Granted, >there >is nothing that we can do now about v1 systems, but we believe very >deeply >that every effort should be made to delay CONNECT until all >media/location >decisions are over, there is bearer, and talking/seeing can occur. This >is >what the CONNECT message is about. The fact is that it is possible to >do >H.245 upon CallSetup, and the system can take as long as it needs to do >"intelligence" before the CONNECT message. Remember that these >intelligent >things take some time, at least a few round trips, and in our >experience if >you start doing them you have plenty of time to negotiate media via >H.245. > >I hope that it is clearer now why I have a problem with any scheme to >"delay establishing media until after the CONNECT message." This is a >bad >habit that we need to end. I hope too that it is clearer why I like the >FastStart. We need good old dumb "black telephone service." If you >have >been listening to the IETF noise over this issue, you will know that >this >attack on H.323 is being taken seriously by many customers. Fast Start >answers that attack and adds a real new feature to H.323. > >Sincerely, > >Scott Petrack >

1 0

Revised H.310 version2
by Kiyoshi SAKAI 18 Dec '97

18 Dec '97

Dear SG16 colleagues, Toward the coming SG16 meeting, I have uploaded the draft revision ducument of H.310 to the "Incoming" directory of GCL's ftp site. The file name is "H310v2-4.doc" and it has been created by MS-Word97 (US version) then converted to the ver.6.0/95 compatible format. Main changes against existing version 1 are as follows: 1. Changes proposed in APC-1259(Contribution to the Sunriver meeting) - Corrections described in the H.310 Implementers Guide are imported. - An informative description in the H.310 Implementers Guide about H.310 CorrelationID is imported as AppendixIII. 2. Changes made after APC-1259 - Proposed corrections in COM 16-55 and APC-1300(Contribution to the Sunriver meeting) regarding the H.320/H.321 interoperation mode stack of RAST-5 terminals are adopted. - Proposed additions in APC-1299(Contribution to the Sunriver meeting) regarding the procedures for intercommunication between H.310 RAST-1 and RAST-5 terminals are included. - According to the liaison from SG11/WP1(Sep.1997) , descriptions for the use of resourceId within the B-HLI in the absence of Q.2941 are totally deleted. There are still some open issues exist. Comments and contributions are solicited. If you have any problems to reproduce the document, please let me know. Best regards, K. Sakai ********************************************************************** Kiyoshi Sakai Media Processing Laboratory Multimedia Systems Labs. FUJITSU LABORATORIES LTD. Tel. : +81 44 754 2679 Fax. : +81 44 754 2347 E-mail : sakai(a)flab.fujitsu.co.jp **********************************************************************

1 0

Fast Start issues
by Scott Petrack 17 Dec '97

17 Dec '97

Friends, and especially Pete, It really does seem to me that it is possible to get everyone happy. I would like to try and convince you (Pete) that: a. you can get EXACTLY what you need, in the fastest, most correct way possible, right now, and b. Intel's FastStart is really an important and useful thing as is for H.323. It is possible that a single sentence needs to be added to the FastStart text (see below in the paragraph starting "The thing that you require..."). But mainly I believe that there is a small misunderstanding going on, which is main the source of the problem. Pete, to get this extra "intelligence" you want, I believe that in most cases you must use gatekeeper routed signalling. The called gatekeeper, acting as a proxy for the called user, must send the H.245 port in the CallProceeding message, H.245 negotiation must be used, and the CONNECT message must come at the end, after all location/media negotiations are over and media is available. I say "in most cases" because there are some cases where you will probably choose to do some intelligence in the LRQ phase, before the CallSetup is sent. In these cases it might be possible to know that the CallSetup message is really being sent to the correct Terminal, and so you can then use FastStart to that Terminal. There are also other cases where you may choose to do FastStart with to the user's gatekeeper, have the gatekeeper play out a prompt saying something like "we are looking for your user now", have the gatekeeper do H.245 negotiation with the caller on behalf of the callee, and in the end establish a new media channel to the final negotiated endpoint, breaking the original media channel negotiated with the gatekeeper in the FastStart. All this can be done now by using a combination of FastStart and "classic" H.323 signalling. The "misunderstanding" I was alluding to earlier is this: you are correct that most endpoints until now unfortunately did CONNECT before media negotiation. This is a very unfortunate breaking of Q.931 semantics which could have been avoided, and we should try hard to return to the normal situation where CONNECT is sent only at the end of the entire call establishment procedure. My problem is with the 2nd requirement you gave in an earlier posting: >we want to delay establishing media until after >CONNECT so that the gatekeeper can do some intelligent stuff. I definitely DON'T want to delay establishing media until after CONNECT. And I claim that this is NOT needed for the gatekeeper to do some intelligent stuff. The thing that you require, that is not quite there in the current FastStart proposal, is that "even if a connection is made using FastStart, it shall be possible for either endpoint to start H.245 negotiation at any point in the conversation". I would be willing to go with this in the spirit of compromise. (although personally I feel that such "shalls" are about as strong as "An H.uman endpoint shall not eat pork." Lot's of people who claim "Bible compliance" do not follow this shall, and somehow the world continues to interoperate...) We at VocalTec, as part of our CMA work, support many of the scenarios you talk about, and we do it quite quickly (we think as quickly as logically possible in fact). Some of them require H.245, some require gatekeeper routed signalling, some can be done with FastStart alone. I want to go on record saying that we DEFINITELY want to encourage finishing the H.245 negotiation before CONNECT if it happens. This function is in H.323 now, and it is *the thing* that allows us to do the scenarios that Pete seems to want. We believe that this is how complex services will have to work in H.323. This allows H.245 and H.225 to go completely independently and in parallel, and the poor CONNECT message can just be the final word saying "you're on the air". Logically, if you need H.245 for your call, this is the fastest possible way to get it. You may be thinking, quite correctly "If Scott thinks that the next generation of terminals is going to do H.245 before CONNECT then why in the world does he need FastStart?" This is a good question, but it has a very good answer (I'll bet you thought I would have one....) We perceive an absolute market requirement for the shortest, simplest, fastest, lightweightest, stupidest kind of Internet Telephones, and that a system that cannot support such devices will be very vunerable to attack from competing systems that can. It is very important to be able to build "dumb telephone systems" as well as "intelligent ones". FastStart is a great step forward for dumbness ;-). (sorry Jim). At the risk of repeating myself, even in the some of the scenarios Pete mentions it is useful to use FastStart. It allows a gatekeeper to answer immediately (i.e. "as fast as possible") and reassure the caller that although the system may take a few seconds to find the user and negotiate, this is being done. This is the way to port standard call center stuff to IP seamlessly. The "call center gatekeeper" answers in one round trip with FastStart, sends a CONNECT, and then the ACD-function starts up the real H.245 as part of its thing while blasting out music on hold. The gatekeeper can do intelligent stuff by bringing up H.245 BEFORE the CONNECT message. We believe that we in the H.323 community should do everything possible to return the CONNECT message to its true Q.931 meaning of "you have end to end bearer NOW." The little fight over billing we had at SunRiver is only one of the issues. It is very confusing for people and systems to have CONNECT all of a sudden mean something else. Granted, there is nothing that we can do now about v1 systems, but we believe very deeply that every effort should be made to delay CONNECT until all media/location decisions are over, there is bearer, and talking/seeing can occur. This is what the CONNECT message is about. The fact is that it is possible to do H.245 upon CallSetup, and the system can take as long as it needs to do "intelligence" before the CONNECT message. Remember that these intelligent things take some time, at least a few round trips, and in our experience if you start doing them you have plenty of time to negotiate media via H.245. I hope that it is clearer now why I have a problem with any scheme to "delay establishing media until after the CONNECT message." This is a bad habit that we need to end. I hope too that it is clearer why I like the FastStart. We need good old dumb "black telephone service." If you have been listening to the IETF noise over this issue, you will know that this attack on H.323 is being taken seriously by many customers. Fast Start answers that attack and adds a real new feature to H.323. Sincerely, Scott Petrack

1 0

FW: Submission of Internet draft
by Pete Cordell 17 Dec '97

17 Dec '97

Dear All, I have finally got around to submitting the URL stuff as an Internet-draft. This contains no changes to what was previously put in. When it gets accepted I will forward it to the URL-REG list to see if they have any comments. Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Pete Cordell >Sent: 17 December 1997 19:00 >To: 'internet-drafts(a)ietf.org' >Subject: Submission of internet draft > >Please may I submit the following Internet draft. I have called it: > >draft-sg16-conv-url-00.txt > >Please let me know if there is a problem with this name. > >Many thanks, > >Pete Cordell > >============== >INTERNET-DRAFT Cordell >draft-sg16-conv-url-00.txt BT > Editor > Dec 16, 1997 > Expires: 21 June 1998 > > Conversational Multimedia URLs > >Status of this memo > > This document is an Internet-Draft. Internet-Drafts are working > documents of the Internet Engineering Task Force (IETF), its > areas, and its working groups. Note that other groups may also > distribute working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other > documents at any time. It is inappropriate to use Internet- > Drafts as reference material or to cite them other than as > ``work in progress.'' > > To learn the current status of any Internet-Draft, please check > the ``1id-abstracts.txt'' listing contained in the Internet- > Drafts Shadow Directories on ftp.is.co.za (Africa), > nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), > ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). > >{Editor's comments are in braces} > >Abstract > >The evolving technologies for real-time conversation over the Internet >require URLs to provide user contact information. As there are many >protocols (including some that are not Internet based) that can be used > >for inter-user conversation, this document describes a two stage >transaction process for obtaining a URL that can be used to initiate >conversation. The first stage involves retrieving a list of protocol >specific URLs in a MIME encoded file. The MIME type enables an >appropriate application to be launched which will analyse the presented > >URLs and select the most appropriate one. The second stage involves >interpreting the protocol specific URL and initiating the conversation. >The protocol specific URLs are encoded in a URL form so that they can >be >embedded directly into HTML pages. This allows the first stage to be >omitted. The document describes the format of the MIME encoded list of > >URLs, and the format of a number of protocol specific URLs. > > >Contents > >ABSTRACT 1 >CONTENTS 1 >REVISIONS SINCE LAST VERSION 1 >1. INTRODUCTION 1 >2. THE MIME FILE 2 >3. PROTOCOL SPECIFIC URLS 3 >3.1. COMMON URL ELEMENTS 3 >3.2. H.323 URL 3 >3.3. H.324 URL 5 >3.4. H.320 URL 5 >3.5. POTS URL 5 >3.6. T.120 URL 5 >4. E-MAIL LIST 6 >5. SECURITY CONSIDERATIONS 6 >6. ACKNOWLEDGEMENTS 6 >7. REFERENCES 6 >APPENDIX 1 - COMPLETE ABNF 6 >AUTHOR'S ADDRESS 7 > > >Revisions Since Last Version > >* Removed call-id as a parameter > > >1. Introduction > >Internet technology allows for real-time conversation to take place. >It >also provides a convenient method of obtaining user location >information >in the form of URLs. (Note: As used here, the term user can refer to >a >person, a machine, or any other entity a person or machine may care to >have a conversation with.) These can describe Internet conversational >protocols, and non-Internet based conversational mechanisms such as >POTS. As there are a number of conversational protocols that can be >used to contact a user, this document describes a two stage process for > >initiating conversation, with the first stage being optional. The >first >stage retrieves a list of protocol specific URLs in a MIME encoded >file. >This list is analysed and the most appropriate URL is selected. The >second stage involves interpreting the protocol specific URL. The >protocol specific URLs are in a form that can be directly embedded into > >HTML pages so that the first stage can be omitted. > >The scheme presented here is designed to leverage as much as possible >of >existing infrastructure. As other technologies become common place >(such as CMA [1] and vCard [2]) the mechanisms presented here may >lapse. > >The remainder of this document describes the format of the MIME file, >and the format of a number of protocol specific URLs. > > >2. The MIME file > >The first stage in the contact process is to obtain a list of possible >contact mechanisms. To enable a single link to be placed in an HTML >page, an indirection method is used wherein a link to a MIME encoded >file is made. The MIME type of the file is: > > APPLICATION/TALKTO > >and the default extension is: > > .tlk > >The MIME file should be retrieved using HTTP. Files that contain time >dependent protocol specific URLs should ensure that the files are >marked >as non-cacheable. > >The MIME encoded file consists of ASCII text and lists a number of >protocol specific URLs that can be used to contact a remote user. The >section below describes a number of protocol specific URLs, but this >should not be considered an exhaustive list. > >Each protocol specific URL is presented on a separate line with no >leading white space. The preferred line break convention is the one >used for HTTP (CRLF), but applications must be tolerant to other line >break conventions so that files can be readily edited on diverse hosts. > >Each protocol specific URL may be followed by some white space and a >comment. The comment should be in a form that can be presented to a >user as part of a manual selection process. By default the comments >are >ignored. For example: > ><protocol_specific_url> ;My home number ><protocol_specific_url> ;My bosses number > >Lines which begin with white-space should be considered as comments and > >ignored. >The order of the URLs should be such that the most preferred URL is >presented first, and the least preferred is presented last. When >interpreting the file, if a URL is unsupported, or is not understood, >it >should be skipped. Endpoints are encouraged to take into account the >preference order indicated by the file when selecting a URL, but this >is >not required. Parsing of the file may continue if a contact attempt >fails. > >Note that the file does not contain any other information such as the >times when specific URLs are valid. This enables a simple file format >that does not have to cope with arbitrary search sequences and the >complications of time-zones. Therefore, strictly, the file is only >valid at the time it is downloaded and the HTTP cache control >attributes >should be used to control its validity as required. > >As with any file downloaded by HTTP, it can be a static file on a >server >or dynamically generated by an executable. The data for the latter may > >be uploaded by schemes such as the VoIP's CMA protocol[1]. > >Validation of who is allowed to obtain various types of location >information can be done using WWW-Authentication and cookies. This >document provides no additions to these HTTP mechanisms. > >Example URLs for downloading the MIME file are: > > http://talkto.mycom.com/me.tlk > http://talkto.mycom.com/cma.exe?me > >{For consideration: >The above scheme is simple, but not extensible. It may be prudent to >define a basic extension scheme to cope with any future problems. The >follwing scheme is suggested for consideration. >If the line starts with a "+", then this line contains a parameter that > >is optional to interpret, i.e. parsing of the file can continue even if > >the parameter is not understood. >If the line starts with "*", then the line contains a parameter that >must be understood. The rest of the file should only be interpreted if > >the parameter is understood, but earlier lines can be interpreted even >if the paramter is not understood. This definition allows simple >parser >features and complex parser features to co-exist in the same file. >e.g. >a file might contain: > >h323:pete@h323.bt.com >*time=17:00-8:30 >h323:home@h323.bt.com > >where time is a paramter to be defined in the future. Parsers that >don't understand the time parameter could use the first URL, but not >the >second}. > > >3. Protocol Specific URLs > >Protocol specific URLs describe contact information for a specific >protocol. This section describes a number of these URLs, but this >should not be considered an exhaustive list. Other suitable URLs >include the IETF's SIP, VoIP's CMA, and Microsoft's CALLTO schemes. >Although the main intention of these URLs is to describe conversational > >protocols, URLs such as CHAT and MAILTO may be appropriate as a last >resort. Under certain circumstances RTSP URLs may also be useful. >This section starts with a description of some common elements. These >are then used in the protocol specific URLs. > > >3.1. Common URL elements > >This sub-section describes common elements from which the protocol >specific URLs are constructed. A number of the elements use >definitions >from [3]. > > network = packet-network | switched-network > packet-network = "ip" | "tls" | "udp" | "aal5" > ; ip = IP connection without TLS > ; tls = IP connection made over TLS > ; udp = IP connection made over UDP - > ; this channel may be made reliable > ; using additional means > ; aal5 = ATM AAL5 call > switched-network = "pots" | "isdn" | "aal1" > ; pots = GSTN or ISDN speech/audio call > ; isdn = ISDN data call > ; aal1 = ATM AAL1 call > address = ip-address | phone-address > > ip-address = hostport ; hostport defined in [3] > > phone-address = global-phone-number *[ "&" global-phone-number ] > ; global-phone-number defined in [4]. > ; H.323 endpoints do not support the > ; wait for tone pause character > > param-list = param | param param-list > param = ";" h323-param > >Telephone numbers in phone-address should always be presented in a full > >international form, including the "+" sign. It is the responsibility >of >endpoints and/or gatekeepers to convert these to location specific >numbers. > > >3.2. H.323 URL > >{Note: the format of this URL has been structured to have a basic form >of h323:pete@h323.bt.com. This is because users are familiar with this > >format, and it is intuitive what it means. However, this does present >problems when e-mail ids which include an @ are included in the URL. >One solution is to include the e-mail @ in its escaped form, i.e. %40. > >Another option is to specify that parsers should be tolerant of >duplicate @ signs. Yet another option is to use an alternative >character to represent the @ in the basic URL form, i.e. >h323:pete/bt.com. This appears less intuitive, and there may be many >erroneous URLs generated as the number of /s at the beginning become >very significant, such as in h323:/pete.bt.com which should resolve to >an IP address only. } > >There are two H.323 related URLs. The first form initiates a call >directly based on the information in the URL. The second initiates a >call based on information that is obtained by first issuing an H.323 >LRQ. > >For the first form, the scheme is: > > h323url = "h323" ":" [ "/" [ network ] "/" ] h323-address > [h323-param-list] > >and the second form is: > > lrqurl = "lrq" "://" ip-address [h323-param-list] > >where: > > h323-address = user-part | address | user-part address > user-part = user [ ":" type ] "@" > user = 1*alphanum ; alphanum defined in [3] > type = "e164" | "h323id" | "email" > >The 'network' part of the URL need only be present if the network is >not >of type IP (i.e. ip is the default network). > >If an ip-address is used in the 'address' field, the 'user' and 'type' >fields specify the information to be placed in the destinationInfo part > >of ARQ and destinationAddress part of SETUP. The 'type' field >specifies >the type of AliasAddress. If the user field starts with a digit, "*" >or >"#" the default type is "e164", otherwise it is "h323id". > >If a 'phone-number' is used in the address field any 'user' and 'type' >parts are placed in the remoteExtensionAddress part of SETUP, and the >phone number is placed in the destinationInfo part of ARQ and >destinationAddress part of SETUP. It is the responsibility of the >receiving H.323 over ISDN gateway to transfer the >remoteExtensionAddress >to the destinationInfo part of ARQ and destinationAddress part of SETUP > >prior to making the onward call. > >To place an aliasAddress containing an @ sign in the 'user' field, the >escaped form of the @ sign must be used, i.e. %40. > >If the 'address' field is of type ip-address this is placed in the >destCallSignalAddress fields of both ARQ and SETUP. > >The H.323 URL may have a number of parameters associated with it. If >an >endpoint does not know how to handle a parameter then it shall ignore >the entire URL. At the time of writing the valid parameters are: > > h323-param = cid-param | token-param | l2-param > cid-param = "cid" "=" UUID ; UUID is specified in [5] > token-param = "token" "=" "0x" 1* hex > l2-param = "l2" "=" ( "PPP" | "MPPP" | "SLIP" ) > ; Layer 2 format > >The cid parameter encodes a UUID that should be placed in the >conference >ID field of the ARQ and SETUP messages. This field may appear a >maximum >of 1 time in the URL. > >If a conference Identifier is specified, then the conferenceGoal should > >be "join" in the outgoing SETUP message, otherwise it should be >"create". > >The token field represents a hexadecimal representation of an octet >sequnce. 0, 1 or more token parameters may be included in a URL. > >The 'l2' parameter allows for different packetisation schemes to be >used >over switched network connections. If applicable, the default is PPP. > >Note that an H.323 URL with a network type of ISDN indicates that H.323 > >is carried over the ISDN using a layer 2 protocol such as PPP >(specified >by the 'l2' parameter). It does not mean that the H.323 system should >locate an H.320 gateway and use this to communicate over the ISDN. The > >H.320 URL should be used to indicate this. > >Example H.323 URLs are as follows: > >h323:pete@h323.bt.com > AliasAddress = pete, AliasAddress type = h323id, > destCallSignalAddress = h323.bt.com. > >h323://pete@h323.bt.com > Same as above > >h323:646436@h323.bt.com > AliasAddress = 646436, AliasAddress type = e164, > destCallSignalAddress = h323.bt.com. > >h323:pete@ -- This form requires a gatekeeper to determine a > destCallSignalAddress > AliasAddress = pete, AliasAddress type = h323id, > destCallSignalAddress = GK supplied. > >h323:pete.bt.com > destCallSignalAddress = pete.bt.com > > >h323:/tls/pete%40bt.com:email@bt.com;token=0x5435;token=0xcdfe;cid=f81d4 >fbf-7dec-11d0-a765-00a0c91e6bf6 > This call should be setup over a secure TLS channel. > AliasAddress = pete(a)bt.com, AliasAddress type = email-ID, > destCallSignalAddress = bt.com, Two tokens are supplied. > A conference ID is also specified. > >h323:/pots/+1-515-234-5645 > H.323 over PPP over GSTN. destCallSignalAddress = an address of an > H.323 over POTS gateway. This may be gatekeeper provided. > +1-515-234-5645 is placed in destinationInfo part of ARQ and > destinationAddress part of SETUP. > >lrq:pete@h323.bt.com > Causes an LRQ to be performed first. > > >3.3. H.324 URL > >The format of the H.324 URL is: > >h324url = "h324" ":" [ "/" [ switched-network ] "/" ] phone-address > >The default switched-network type is "pots". H.324i is denoted by >having a switch-network type of "isdn". >An example URL is: > > h324:+1-515-234-5678 > >or: > > h324:/isdn/+1-515-234-5679&+1-515-234-5680 > > >3.4. H.320 URL > >The format of the H.320 URL is: > > h320url = "h320" ":" phone-address > >The network type is always "isdn". An example is: > > h320:/isdn/+1-515-234-5679&+1-515-234-5680 > > >3.5. POTS URL > >The telephone number scheme for a basic voice call is defined in [4]. > > >3.6. T.120 URL > >The format of the T.120 URL is: > > t120url = "t120" ":" [ "/" [ network ] "/" ] address [t120-param-list] > >The following parameters are valid: ??????? > > >4. E-mail list > >As many groups are interested in conversational URLs including SG16, >VoIP, MMUSIC, PINT, TIPHON, URL-REG etc), a separate e-mail list has >been set up. You can subscribe to the list by including the word >"subscribe" in the message body text of an e-mail sent to the address: > > h323-url-request(a)vocaltec.com > >E-mail can be sent to the list at the following address: > > h323-url(a)vocaltec.com > > >5. Security Considerations > >Umm... > > >6. Acknowledgements > >7. References > >[1] "Service Interoperability Implementation Agreement," IMTC VoIP >Forum >[2] vCard >[3] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource > Locators (URL)," RFC1738, December 1994. {Editor's note: A new > version of RFC1738 is being produced so this reference will have > to be changed.} >[4] A. Vaha-Sipila, "URLs for Telephony," > draft-antti-telephony-url-03.txt, 21 Nov 1997 >[5] "Call Signalling Protocols and media Stream Packetization for > Packet Based Multimedia Communications Systems," > ITU-T Recommendation H.225 Version 2, January 1998 > > >Appendix 1 - Complete ABNF > >all-urls = h323url | lrqurl | h324url | h320url | t120url > >h323url = "h323" ":" [ "/" [ network ] "/" ] h323-address [ >h323-param-list ] >lrqurl = "lrq" "://" ip-address [ h323-param-list ] >h324url = "h324" ":" [ "/" [ switched-network ] "/" ] phone-address >h320url = "h320" ":" phone-address >t120url = "t120" ":" [ "/" [ network ] "/" ] address [ t120-param-list >] > >network = packet-network | switched-network >packet-network = "ip" | "tls" | "udp" | "aal5" >switched-network = "pots" | "isdn" | "aal1" > >h323-address = user-part | address | user-part address >user-part = user [ ":" type ] "@" >user = 1*alphanum ; alphanum defined in [3] >type = "e164" | "h323id" | "email" > >address = ip-address | phone-address > >ip-address = hostport ; hostport defined in [3] > >phone-address = global-phone-number *[ "&" global-phone-number ] > ; global-phone-number defined in [4]. > ; H.323 endpoints do not support the > ; wait for tone pause character > >h323-param-list = ";" h323-param | ";" h323-param h323-param-list > >h323-param = cid-param | token-param | l2-param >cid-param = "cid" "=" UUID ; UUID is specified in [5] >token-param = "token" "=" "0x" 1* hex >l2-param = "l2" "=" ( "PPP" | "MPPP" | "SLIP" ) > ; Layer 2 format > >t120-param-list = ";" t120-param | ";" t120-param t120-param-list >t120-param = {???????} > > >Author's Address > >Pete Cordell >BT Labs >MLB 4/15 >Martlesham Heath >Ipswich >IP5 3RE >UK >e-mail: pete.cordell(a)bt-sys.bt.co.uk > > >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > >

1 0

Schedule for 14-25 Sep 1998 meeting of Study Group 16
by Toby Nixon 16 Dec '97

16 Dec '97

At the IMTC VOIP Forum meeting last Friday, Jeff Pulver announced that he has planned next fall's VON conference for the week of September 14-18 in Washington DC. Apparently, he didn't know that there is a Study Group 16 meeting planned for the same time slot. He's really in a bind, though, because of conflicts with other conferences and trade shows, holidays, etc., and is very concerned that key SG16 participants won't be able to attend VON with the current schedule. What is the SG16 WP2 workload likely to be at that fall '98 meeting? Is it conceivable that we could schedule WP1 and WP3 meetings mostly in the first week, and meetings of WP2 and its questions mostly in the second week, so as to allow for participating in VON? -- Toby ___________________________________________________________ Toby Nixon, Program Manager - NetMeeting http://www.microsoft.com/netmeeting Microsoft Corporation, Applications and Internet Client Group, Redmond WA USA +1 (425) 936-2792 Fax: +1 (425) 936-7329 mailto:tnixon@microsoft.com

2 1

Re: Schedule for 14-25 Sep 1998 meeting of Study Group 16
by Toby Nixon 16 Dec '97

16 Dec '97

Istvan Sebestyen [SMTP:istvan.sebestyen@mch.pn.siemens.de] wrote: > In my personal opinion WP2 will - as always be - very busy, and > occupied with much work. In addition you have to deduct the opening > and closing Plenaries of the WPs and of SG16 (the later one about > 1,5-2 days). So, in practice the question is if you can queeze WP2 > work in 2,5-3 days (Monday-Wednesday 2nd week), > without giving time for preparation of reports, > documents, last minutes edits etc. for the closing plenaries. > > In my opinion this will be very difficult. and Gary Thom [gthom(a)DELTA-INFO.COM] wrote: > I expect that at the Sept 98 SG16 meeting, we will have several > documents to Determine. These may be: H.MediaMIB, > H.246 Annexes for H.324/H.320 and H.324/H.323, H.235V2, > H.245V4, T.130/H.AVC. Maybe also H.323V3, H.225.0V3. Well, I was afraid of that when I was speaking with Jeff on Friday. I'll let him know, and he'll have to decide whether to try to reschedule VON or do it without key SG16 participants. -- Toby ___________________________________________________________ Toby Nixon, Program Manager - NetMeeting http://www.microsoft.com/netmeeting Microsoft Corporation, Applications and Internet Client Group, Redmond WA USA +1 (425) 936-2792 Fax: +1 (425) 936-7329 mailto:tnixon@microsoft.com

1 0

Re: Schedule for 14-25 Sep 1998 meeting of Study Group 16
by Istvan Sebestyen 16 Dec '97

16 Dec '97

At 14:58 15.12.1997 -0800, Toby Nixon wrote: >At the IMTC VOIP Forum meeting last Friday, Jeff Pulver announced that he >has planned next fall's VON conference for the week of September 14-18 in >Washington DC. Apparently, he didn't know that there is a Study Group 16 >meeting planned for the same time slot. He's really in a bind, though, >because of conflicts with other conferences and trade shows, holidays, etc., >and is very concerned that key SG16 participants won't be able to attend VON >with the current schedule. > >What is the SG16 WP2 workload likely to be at that fall '98 meeting? Is it >conceivable that we could schedule WP1 and WP3 meetings mostly in the first >week, and meetings of WP2 and its questions mostly in the second week, so as >to allow for participating in VON? > > -- Toby >___________________________________________________________ >Toby Nixon, Program Manager - NetMeeting >http://www.microsoft.com/netmeeting >Microsoft Corporation, Applications and Internet Client Group, Redmond WA >USA >+1 (425) 936-2792 Fax: +1 (425) 936-7329 mailto:tnixon@microsoft.com > > Toby, to your question... In my personal opinion WP2 will - as always be - very busy, and occupied with much work. In addition you have to deduct the opening ang closing Plenaries of the WPs and of SG16 (the later one about 1,5-2 days). So, in practice the question is if you can queeze WP2 work in 2,5-3 days (Monday-Wednesday 2nd week), without giving time for preparation of reports, documents, last minutes edits etc. for the closing plenaries. In my opinion this will be very difficult. Regards, Istvan ------------------------------------------------------------------ Istvan Sebestyen Siemens AG PN GS 94 Mch H/1760/255 Tel: +49-89-722 47230 Hofmannstr. 51 Fax: +49-89-722 47713 D-81359 Munich, GERMANY Internet: istvan.sebestyen(a)mch.pn.siemens.de (preferred) istvan.sebestyen(a)pn.siemens.de (Fall back only) X.400: c=de;a=dbp;p=scn;o=siemens;ou1=mch;ou2=PN-msmail; s=Sebestyen;g=Istvan Note: Unfortunately - in practice - e-mails sent to me can get lost or stay unread for a long time due to business trips. So, for very important communication pls. send a "back-up" in fax. ------------------------------------------------------------------

1 0

Re: Pete Cordell's FastStart issues
by Neil Starkey 11 Dec '97

11 Dec '97

Please do put this on the list. This is an issue we (DataBeam) are interested in but have lost out on part of the discussion. Neil At 12:23 PM 12/8/97 -0800, Toby Nixon wrote: >Might I suggest that this discussion be broadened to include the ITU-SG16 >reflector instead of sending a long list of recipients each time? > >> -----Original Message----- >> From: Pete Cordell [SMTP:pete.cordell@bt-sys.bt.co.uk] >> Sent: Monday, December 08, 1997 9:16 AM >> To: 'pete.cordell(a)bt-sys.bt.co.uk'; 'Narjala_Bhasker(a)ccm.jf.intel.com'; >> 'Vineet_Kumar(a)ccm.jf.intel.com'; 'amir(a)radvision.rad.co.il'; >> 'gthom(a)DELTA-INFO.COM'; 'lindbergh(a)pictel.com'; 'reid(a)pictel.com'; >> 'Scott_Petrack(a)VOCALTEC.COM'; 'okubo(a)gctech.co.jp'; Toby Nixon; Steve >> Liffick; 'karl.klaghofer(a)MCH.PN.SIEMENS.DE'; 'amotz(a)radvision.rad.co.il'; >> 'sebes(a)PNSTA1.ZFE.SIEMENS.DE'; 'dskran(a)ascend.com'; >> 'nstarkey(a)databeam.com'; 'Robert.Callaghan(a)SIEMENSCOM.COM'; >> 'gkajos(a)videoserver.com'; 'ggf(a)lucent.com'; 'jeff(a)pictel.com'; >> 'john.boucher(a)bt-sys.bt.co.uk'; 'gkisor(a)ideal.jf.intel.com'; >> 'reinhard.scholl(a)oen.siemens.de'; 'ofer(a)radvision.rad.co.il'; >> 'nilsson_m_e(a)bt-web.bt.co.uk'; 'helmut.schink(a)oen.siemens.de'; >> 'roni_e(a)accord.co.il'; 'gfargo(a)intecom.com'; 'adfranklin(a)lucent.com'; 'Jim >> Toga' >> Subject: RE: Pete Cordell's FastStart issues >> >> Jim et al., >> >> I'm glad we've got a discussion going on this. This seems to be a >> really big issue that can have a major impact on the future of H.323. I >> know we're all really busy, but come January we will be stuck with what >> ever we decide, so I'm hoping that other people can jump in here to >> thrash out the issues as much as possible. The more input, the better >> the solution is likely to be. >> >> I've put comments in below. From the comments presented though I don't >> think we are on the same wavelength yet, so most of the comments are >> related to the problem space rather than any solutions. >> >> Pete >> ================================= >> Pete Cordell >> BT Labs >> E-Mail: pete.cordell(a)bt-sys.bt.co.uk >> Tel: +44 1473 646436 >> Fax: +44 1473 645499 >> ================================= >> >> >> >---------- >> >From: Jim Toga[SMTP:jtoga@ideal.jf.intel.com] >> >Sent: 07 December 1997 19:18 >> >To: pete.cordell(a)bt-sys.bt.co.uk; Narjala_Bhasker(a)ccm.jf.intel.com; >> >Vineet_Kumar(a)ccm.jf.intel.com; amir(a)radvision.rad.co.il; >> >gthom(a)DELTA-INFO.COM; lindbergh(a)pictel.com; reid(a)pictel.com; >> >Scott_Petrack(a)VOCALTEC.COM; okubo(a)gctech.co.jp; tnixon(a)MICROSOFT.COM; >> >stevel(a)MICROSOFT.COM; karl.klaghofer(a)MCH.PN.SIEMENS.DE; >> >amotz(a)radvision.rad.co.il; sebes(a)PNSTA1.ZFE.SIEMENS.DE; >> >dskran(a)ascend.com; nstarkey(a)databeam.com; >> >Robert.Callaghan(a)SIEMENSCOM.COM; gkajos(a)videoserver.com; >> >ggf(a)lucent.com; jeff(a)pictel.com; john.boucher(a)bt-sys.bt.co.uk; >> >gkisor(a)ideal.jf.intel.com; reinhard.scholl(a)oen.siemens.de; >> >ofer(a)radvision.rad.co.il; nilsson_m_e(a)bt-web.bt.co.uk; >> >helmut.schink(a)oen.siemens.de; roni_e(a)accord.co.il; gfargo(a)intecom.com; >> >adfranklin(a)lucent.com >> >Cc: jtoga(a)ideal.jf.intel.com >> >Subject: Re:Pete Cordell's FastStart issues >> > >> >Pete, (and others) >> > >> >Let me try and respond to your issues and hopefully we can resolve this >> >in >> >a relatively concise manner. Before we get started though I would like >> >to >> >make a couple of points clear: >> > >> >Recall that the "fast start" problem as stated previous to the Israel >> >meeting and formalized in the contribution to that meeting, was the >> >following. To provide a minimal round trip time connection sequence, >> >for >> >simple constrained calling scenarios. The requirement was to have >> >minmal >> >engineering impact to current shipping products and complete backward >> >compatability. >> I've looked through my notes and I can see any authoritative, exclusive >> list of what the fast start should be expected to solve. I don't see >> anything that said it should be restricted to "simple constrained >> calling scenarios". >> > >> >I have always been a proponent of Gatekeepers and the functionality, >> >features, and services that they can provide. >> > >> >Everyone (including you), supported the final version of FastStart >> >which >> >came out SunRiver with the additions of bi-directional capabilities. >> >With >> >the presentation of your alternative approach there was never any clear >> >motivation for developing the more complicated version other than you >> >'didn't like' the current form. I'm happy to see you've presented a >> >real >> >issue to which you would like a solution. >> > >> >I would like codify my understanding of your issues and see if we can >> >find >> >a solution to them. I _think _you imply the need for a low overhead >> >'mode >> >switch' which really has nothing to do with FastStart, but let me see >> >if I >> >understand your points. >> To me connection setup (i.e. user-to-user connection) is pretty much all >> that H.323 is about. Once a connection is setup there is little more >> for H.323 to do, other than tear-down. >> > >> > >> >At 03:58 PM 12/5/97 -0000, Pete Cordell wrote: >> >[SNIP] >> >> Each user has an account on the system. They can use >> >>it as a single number by which to contact them by. As you move from >> >office to home to mobile, >> >>you configure it using a web browser with >> >>the number to contact you on. People trying to contact you dial a >> >>single number and the platform forwards the call to the correct >> location. >> >> It also allows people to leave voice messages on the system. >> >>Additionally you can configure it to do things like try the office phone >> >>first, then the mobile and if that doesn't work leave a message. This >> >>sort >> >> of flexibility is not easily addressed by a directory. It >> >>can also receive e-mails and faxes etc. >> >> >> >[SNIP] >> > >> >>This is admittedly not rocket science, and you've probably come across >> >>services like this already. Our job is to move this to the IP world. >> > >> >Why can't you can accomplish this today (in R2) with the multiple alias >> >registrations (that fact that you may use WEB front end is irrelevent)? >> >The >> >Gatekeeper then has his 'rotary switch' of locations to look through to >> >find the current active location. This is much like (if not exactly) >> >VocalTec's CMA architecture. >> Your right, the configuration side of things is not the issue. >> > >> >>Product Impact >> >>============== >> >>To understand the impact of this on the protocol, let's look at the case >> >>of using a search algorithm to look for a user and also returning a call >> >>after interrogating the voice bank. >> >> >> > >> >Tying user-network signalling to network-network signalling in the >> >protocol >> >is bad practice, limiting and cumbersome. >> I agree, network-network signalling is for another day. However this >> issue is very much in the user-network signalling area. The issues >> remain even if only one gatekeeper is involved (which hopefully implies >> that there is no network-network signalling). >> > >> >>Let's assume the system is configured to contact my work number first >> >>and them my mobile number. In this case the final connected endpoint is >> >> >> not known until the CONNECT message is received. Hence the >> >>capabilities of the endpoint you will be talking to are not known for >> >>sure until you get CONNECT. >> > >> >I see this, and agree it is entirely true. It has no effect however on >> >the >> >the capabilities of the _calling_ party. They _are_ known, and there >> >is no >> >reason why the possibile capabilities should change. >> Correct >> > >> >>This is not a problem with the basic call setup sequence as the H.245 is >> >> >>not established until after CONNECT. >> > >> >This is not quite true. There has been the ability (since 3/96) to >> >start >> >H.245 at any point after the SETUP message is received. This required >> >two >> >things, which by the way would be required in all of these scenarios. >> > >> >The caller and callee has to be able to deal with H.245 and possibly >> >media, >> >'early'. >> >The caller has to place the H.245 port in the Setup message. >> >(Alternatively the callee can place the H.245 port in the Call >> >Proceeding/Alerting message) >> True, but hopefully you'll agree with me that in this case the >> gatekeeper could delete any H.245 addresses from messages other than >> CONNECT and it would get the desired behaviour. This seems to be a >> pretty NULL operation as nobody seems to be sending H.245 addresses in >> messages other than connect anyway. >> > >> >>However, with fast connect we want to start capability negotiation as >> >>soon as possible, and are not able to wait until CONNECT. >> > >> >The Determined version of FastStart DOES do a full capability exchange >> >before the CONNECT. (althought it does not provide for an iterative >> >_negototiation_, as this defeats the Fast portion of FastStart). >> I have problems with saying the FastStart shall be 1 round trip or bust. >> The intent seems to have been that a minimum of round trips should be >> used compatible with negotiation, security etc. If a particular case >> requires an extra round trip, then that is the minimum number of round >> trips that case can be set up in. That doesn't break fastStart. I >> would say it's good because it has meant that we don't fall back to the >> 6 1/2 round trips that we typically need. >> > >> >>This also has the benefits that we can listen to announcements prior to >> >the CONNECT >message (such as "The >> > >number you have dialled has > changed, but we are re-routing you >> >anyway"). >> > >> >This is EXACTLY what FastStart provides as soon as the Setup is >> >recieved, >> >the recipient may start playing media back to the caller. The caller >> >may >> >be constrained from sending media to the callee until the Connect is >> >received - just as it works in the circuit world. >> I was trying to capture the issues here, not saying that the current >> fast start doesn't meet any of them. Basically we have conflicting >> requirements here 1) we want to establish media prior to CONNECT to >> allow announcements, 2) we want to delay establishing media until after >> CONNECT so that the gatekeeper can do some intelligent stuff. This is >> what makes this topic so interesting!!!! >> > >> >>However, if the system gives up ringing my work number and then tries >> >>the mobile number, it has to present a new set of capabilities to the >> >calling endpoint. >> > >> >That is true, and this can occur by simply sending another Call >> >Proceeding >> >message (or Alerting) with the new caps. There is no need however for >> >the >> >_caller_ change or otherwise resend its caps..... In other words the >> >Gatekeeper will still be presenting the same set to the subsequent >> >callees >> >as it polls them. >> You're right that the caller does not have to generate new caps. >> However, sending multiple CALL PROCEEDINGs or ALERTINGs to an endpoint >> breaks H.225, and so would not be backwards compatible. >> > >> > >> >>Now I'm in the mode of interrogating the voice messages that have been >> >>left for me. My endpoint is connected to the sub-system that plays out >> >the recorded >> >>messages and it asks me if I want to return the >> >>call. To do this the system needs to create an outgoing call, and >> >>locally generate a ringing tone. When the remote party answers the two >> >endpoints need >> >>to be connected together. >> > >> >This is either some form of a transfer (from a protocol point of view) >> >or >> >shouldn't it be hidden from the endpoint in terms of signalling? >> In a distributed world there is only so much that you can hide from an >> endpoint. That's why this topic is so important. To roll out customer >> friendly services the endpoints need to support some basic capabilities. >> Hopefully this is worth endpoint vendors doing as useful services mean >> that people can use there endpoints for more things. Thus the >> technology is more likely to catch on, than if you are only likely to >> get reasonable service from a call centre via good old POTS. >> > >> >>You may say that the FACILITY message could be used to do this. >> However, >> >the caller has state stored >> >>in the platform/gatekeeper (such as where they are in the menus etc.) so >> >that when they finish this new >> >>call they can go back to interrogating their messages. This would not >> be >> >possible with the >> >>FACILITY approach. >> > >> >It would seem that exposing this bookkeeping/signalling would require a >> >_large_ commitment on the part of all the endpoint manufacturers - >> >wouldn't >> >it be better to provide this in an 'invisible' way? Aside from the >> >complexity/compatibiliy issues it provides for product differentiation. >> I think you're agreeing with me that the FACILITY way is a bad way to >> go. >> > >> >> >> >>WOW that's complicated!!! >> >>========================= >> >>At first sight this appears horrendous, but in actual fact it is quite >> >>simple. All it requires is for the platform/gatekeeper to be able to >> >break connections and re-establish >> >>new connections when it wants to. >> > >> >AAHHH.... so this is what you wanted! This _does_ seem like a >> >'transfer' >> >type of thing, in any case it would appear to be independant of >> >FastStart. >> A setup is almost invariably part of transfer, so I don't see that you >> can call them independent. Anyway, the report from Hertzliya says >> support for supplementary services should be included in fast setup. >> > >> >I have to admit, I'm not sure what you mean by 'connection' though. Is >> >this simply logical media channels, or is it a larger concept? >> I'm really mean establishing some sort of media exchange between users >> such as audio or video. >> > >> >[SNIP] >> > >> >> >> >>So where's the problem >> >>====================== >> >>The problem is that I can not make use of the fast setup scheme with >> >>these services, because it does not support the break and make >> capability. >> > >> >This is _new_ functionality that was never listed as a requirement of >> >FastStart, and I would argue that 'breaking and making connections' >> >goes >> >against the scope of the FastStart usefulness. >> This is where I totally disagree. The list of fast start requirements >> was never exclusive. We announced our requirements for fast start and >> no body objected to them, and some even backed them up. If you had >> objections you should have raised them at the time. >> > >> >>To do these services I need tofall back to H.245. If the >> >>standard setup is not good enough for a basic point-to-point call then >> >>it is not good enough for entities that introduce intelligence which in >> >fact have more stringent timing >> >>requirements because the breaks and makes are more difficult to conceal >> >under things like ringing. >> > >> >The 'standard setup' is no way "not good enough" for basic >> >point-to-point >> >operation. It simply as case that in certain well defined (resources >> >and >> >entities known) that optimizations can and should be made to operate in >> >simple low delay environments. >> > >> >>Assuming that the reason for implementing the gatekeeper routed model is >> >to add these sorts of features, then >> >>really the gatekeeper routed model becomes a second class citizen. This >> >is a problem for us. >> > >> >The Gatekeeper should most definitely NOT be constrained from adding >> >features and providing expanded services. The Gatekeeper routed model >> >was >> >specifically developed to hide this complexities from the endpoints, in >> >fact the endpoint cannot even tell which mode it is running in other >> >than a >> >bit in the ACF. >> > >> >The Gatekeeper is no more or less a "second class citizen" with >> >FastStart >> >as with the 'standard' signaling. In fact I believe that it has even >> >more >> >control, because it may provide an asymmetrical connection on either >> >side >> >of itself >> >forcing either the caller or callee into a particular mode of >> >operation. >> If the standard startup is good enough then we seem to be taking >> elaborate measures to tune the efficiency of the "standard setup". >> Either the standard setup is good enough or it isn't. If it is good >> enough then we don't need fast start. I happen to think that it is not >> good enough. Hence we need a solution that is good enough for the basic >> call model and is also good enough for those of us that want to add >> value. If we don't achieve this, then as far as I can see the >> gatekeeper routed model can only become a second class citizen. >> > >> >> >> >>Where to go next >> >>================ >> >>To do what I need to do, I need a fast method for making and breaking >> >>connections without first establishing the TCP connection, negotiating >> >caps, MSD, OLC, OLC ACK, >> >>and then sending media. We could achieve this by adding a break command >> >to the FACILITY message and >then having the ability to send new >> >fastCaps >> >at any time to make a new connection. This seems a minimal >> >>change from where we are at the moment and such a change would be fine >> by >> >me. >> > >> >Again I'm not clear on what you mean by 'connections', but assuming >> >that >> >you mean something like an audio channel (say 711-->723.1) than I think >> >there are a number of fine options we can pursue. (for example H.245 >> >has >> >established a 're-open' command.) >> > >> >> >> >>However, I know that Glen is interested in always running an MC, so he >> >>would want to add extra features. Others will probably also want >> features >> >that have been carefully crafted >> >>into H.245. As a result we are likely to get feature creep so that more >> >and more H.245 functionality is >> >>put into H.225. >> > >> >I completely agree that it would be a very bad thing to re-invent H.245 >> >within H.225.0. >> > >> >> I also have concerns about having two ways and two APIs (fast and slow) >> >for doing >> >>things. This explains my attempt to re-use as much of H.245 as >> possible. >> > >> >To pick a nit, we're not talking about API's; there is one way within >> >the >> >protocol to establish an H.245 connection. If you need these features, >> >flexibility and control; this is what you should do. That being said >> >there >> >are two forms of Setup/Connect messages for those >> >Endpoints/Gatekeepers/MCUs that would like to utilize them. >> To pick more nits ( :-) ), we at some point have to build what we >> propose. Therefore, we can not conceive of protocols in isolation of >> how we will build them. If one protocol idea is easier to develop than >> another then we should go with that one. So although the ITU is not >> bothered with APIs, we as contributors, should be. >> >> Most stacks that I am aware of separate out the Q.931 part and the H.245 >> part. At the moment the H.245 part knows about caps and the Q.931 part >> does not. To put caps in Q.931 we need to put an API on the Q.931 part >> that accepts caps. Therefore we really do have two APIs, which is an >> issue. >> > >> >> >> >>But let me reassure you I have no requirement to use H.245! I have a >> >>requirement to solve the problem presented above. >> > >> >The problem is to 'break and make' connections with minimal >> >overhead?..... >> Yep >> > >> >> >> >>A little history >> >>================ >> > >> >[SNIP]. >> The issues raised here are hopefully covered off elsewhere. >> > >> >> >> >>To sum up >> >>========= >> >>To differentiate I want to add intelligence to my platform (effectively >> >>a gatekeeper). If I can't use fast setup as part of this people will >> >either use the direct call model, >> >>or use dumb gatekeepers. Basically the gatekeeper routed model will >> loose >> >out. >> > >> >Nothing you have described so far is either helped or hindered by >> >FastStart, this point is completely irrelevent. As I said above, >> >Intel >> >has always believed in the value of Gatekeepers to H.323 systems. I'm >> >surprised that you didn't present a contribution to provide >> >lightweight >> >'connection switching' in a general manner. >> The point really is that it has not helped...... >> > >> >> >> >>Hence I need fast setup to be useful for a gatekeeper adding >> intelligence, >> >which basically means being >> >>able to quickly break and make connections. >> > >> >This is great! If this is what you require, lets come to quick >> >agreement on >> >this and move on. >> > >> >> >> >>I have presented a solution that I believe meets these requirements. >> >>But if there is another way of meeting my requirements then I would be >> >only too happy to adopt it. >> >> >> > >> >Here are my suggestions that I _think_ provide the functionality you >> >desire: >> I think it's important that we try to sort out the problem we are >> solving first. If you feel we are on the same wavelength then we can >> move on to the technical implementation, but I don't think we are quite >> there yet. I hope this has helped. Besides, I would also like more >> time to think about what you have proposed. >> > >> > >> [SNIPPED, but not forgotten] >> > >> >Does this solve your issues? >> >> This is a good start and I'm confident that in a few rounds we can get >> there. Thanks for the time you've put into this Jim. You may not thank >> me now, but I'm sure that in a few years you (or your company) will >> thank me for bringing this all up!!!! (well say 10 years. Or not more >> than 20 years. Well not much more than 20 years....) >> > >> >Best Regards, >> >jimt. >> > >> >> Pete >> > >> >************************************************************************ >> >* >> >*** +1-503-264-8816(voice) +1-503-264-3485(fax) >> >*** >> >*** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. >> >*** >> >*** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** >> >************************************************************************ >> >* >> > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Neil Starkey, EVP/CTO nstarkey(a)databeam.com DataBeam Corporation http://www.databeam.com 230 Lexington Green Circle +1 606 425 3500 voice <<NEW ADDR/PHONE Lexington, KY 40503 +1 606 425 3528 fax <<NEW FAX ... no we didn't move - it's a conspiracy between the phone company and the post office! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1 0