<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4207.2601" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial>Michael,</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Looking into this further, I believe the Annex G text 
actually clarifies this (text includes text from the IG):</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV><FONT face=Arial color=#0000ff><SPAN 
  style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><STRONG>G.8.2.6    
  Service Confirmation</STRONG></SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff><SPAN 
  style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">A 
  border element in receipt of a ServiceRequest message responds with a 
  ServiceConfirmation message to indicate that it agrees to establish a service 
  relationship. <U><FONT color=#ff0000>Every new service relationship is 
  identified by a service identifier. Whenever a border element receives a new 
  ServiceRequest message, it allocates a unique service ID and returns it to the 
  sender of the service request message in the "service confirm" 
  message.</FONT></U> If the border element already has a service relationship 
  with the border element that sent the ServiceRequest message, sending 
  ServiceConfirmation indicates that the terms of the original relationship are 
  terminated and replaced with the new terms.</SPAN></FONT></DIV></BLOCKQUOTE>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>So, it would seem that if a new ServiceRequest is 
received, the serviceID would remain the same.  It does not say that the 
service relationship itself is terminated, but the "terms of the original" 
(which I interpret as the security attributes or other things).  I suppose 
it could be that a new ServiceID could be introduced, though-- particularly when 
one side believes that the service relationship has expired.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>I believe one of the issues is that, prior to this text 
introduced into the IG, it was assumed that one and only one service 
relationship existed between two BEs.  This new text (underlined and in 
red) suggests otherwise.  Perhaps this is the real problematic point: we 
have introduced the ServiceID field unnecessarily.  We have changed Annex G 
such that multiple service relationships may exist in parallel.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>We have two ways to resolve this:</FONT></DIV>
<OL>
  <LI><FONT face=Arial>Remove the serviceID field</FONT></LI>
  <LI><FONT face=Arial>Add more text to clarify the usage of the serviceID 
  field</FONT></LI></OL>
<DIV><FONT face=Arial>I believe option (1) is actually the better course of 
action.  We have added this new field-- we can either deprecate it or just 
remove it entirely.  By choosing (1), we eliminate the problem 
entirely.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>If there are good reasons for having multiple service 
relationships (and there may be), I believe a number of sections need to be 
modified in order to make it clear that multiple relationships may exist as 
suggested in (2).  As for the keep alive, I believe that would be handled 
by the statement in the IG that says all subsequent messages would contain the 
serviceID field.  So, we can move forward with (2), I can see where 
a few sections of text discussing service relationships needs 
corrections.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Paul</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=Michael_Fortinsky@vocaltec.com 
  href="mailto:Michael_Fortinsky@vocaltec.com">Michael_Fortinsky@vocaltec.com</A> 
  </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=paulej@packetizer.com 
  href="mailto:paulej@packetizer.com">Paul E. Jones</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=h323implementors@pulver.com 
  href="mailto:h323implementors@pulver.com">h323implementors@pulver.com</A> ; <A 
  title=h323implementors@imtc.org 
  href="mailto:h323implementors@imtc.org">h323implementors@imtc.org</A> ; <A 
  title=ITU-SG16@mailbag.cps.intel.com 
  href="mailto:ITU-SG16@mailbag.cps.intel.com">ITU-SG16@mailbag.cps.intel.com</A> 
  </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Sunday, October 22, 2000 5:53 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [H225 Annex G] When to 
  create a new service ID</DIV>
  <DIV><BR></DIV><BR><FONT face=sans-serif size=2>Paul,</FONT> <BR><BR><FONT 
  face=sans-serif size=2>Maybe I don't understand your point - I am not sure 
  what you mean when you</FONT> <BR><FONT face=sans-serif size=2>say "a new 
  ServiceRequest". (I think this is the heart of the matter - what</FONT> 
  <BR><FONT face=sans-serif size=2>determines what is a NEW 
  ServiceRequest?)</FONT> <BR><BR><FONT face=sans-serif size=2>New service ID's 
  are allocated and returned in the ServiceConfirmation message, 
  </FONT><BR><FONT face=sans-serif size=2>not in the ServiceRequest 
  message.</FONT> <BR><FONT face=sans-serif size=2>Therefore, it is up to the 
  border element that receives the ServiceRequest message </FONT><BR><FONT 
  face=sans-serif size=2>to decide whether to allocate a new service ID or 
  not.</FONT> <BR><FONT face=sans-serif size=2>The question still remains - how 
  are "keepAlive" ServiceRequests to be treated?</FONT> <BR><BR><FONT 
  face=sans-serif size=2>Another way of looking at the issue is as follows 
  (maybe this is clearer):</FONT> <BR><BR><FONT face=sans-serif size=2>If a BE 
  sends a ServiceRequest message that does NOT contain</FONT> <BR><FONT 
  face=sans-serif size=2>a serviceID field, a new service ID is returned in the 
  ServiceConfirmation</FONT> <BR><FONT face=sans-serif size=2>message and a new 
  service relationship is defined.</FONT> <BR><BR><FONT face=sans-serif 
  size=2>If a BE sends a ServiceRequest message that DOES contains a serviceID 
  field,</FONT> <BR><FONT face=sans-serif size=2>the BE that received the 
  ServiceRequest must determine whether to </FONT><BR><FONT face=sans-serif 
  size=2>return the same serviceID or a new one (ie, is there going to be a 
  new</FONT> <BR><FONT face=sans-serif size=2>service relationship or 
  not)</FONT> <BR><BR><FONT face=sans-serif size=2>- if the service parameters 
  in the ServiceRequest are the same as those in the existing</FONT> <BR><FONT 
  face=sans-serif size=2>  service relationship, this ServiceRequest 
  message is a refresh of the existing</FONT> <BR><FONT face=sans-serif 
  size=2>  service relationship and the ServiceConfirmation is returned 
  with the </FONT><BR><FONT face=sans-serif size=2>  same service ID as was 
  in the ServiceRequest</FONT> <BR><BR><FONT face=sans-serif size=2>- if the 
  service parameters are different, then:</FONT> <BR><FONT face=sans-serif 
  size=2>   - if the BE want to accept the new parameters, it sends a 
  ServiceConfirmation</FONT> <BR><FONT face=sans-serif size=2>    
   that contains a NEW serviceID - this also indicates that the previous 
  </FONT><BR><FONT face=sans-serif size=2>     service 
  relationship has ended</FONT> <BR><BR><FONT face=sans-serif size=2>  - if 
  the BE does not want to accept the new parameters, it sends a 
  ServiceRejection</FONT> <BR><FONT face=sans-serif size=2>    (that 
  contains the serviceID from the ServiceRequest message)</FONT> <BR><FONT 
  face=sans-serif size=2>    indicating that the new terms are 
  rejected - the old service relationship is still</FONT> <BR><FONT 
  face=sans-serif size=2>    in effect according to the old service 
  parameters (as per section 1.8.2.7/H.225 Annex G)</FONT> <BR><BR><FONT 
  face=sans-serif size=2>Comments?</FONT> <BR><FONT face=sans-serif 
  size=2><BR>Mike</FONT> <BR><BR><BR>
  <TABLE width="100%">
    <TBODY>
    <TR vAlign=top>
      <TD>
      <TD><FONT face=sans-serif size=1><B>"Paul E. Jones" 
        <paulej@packetizer.com></B></FONT> 
        <P><FONT face=sans-serif size=1>10/22/00 04:02 AM</FONT> <BR></P>
      <TD><FONT face=Arial size=1>        </FONT><BR><FONT 
        face=sans-serif size=1>        To:     
           <Michael_Fortinsky@VOCALTEC.COM>, 
        <ITU-SG16@mailbag.cps.intel.com>, 
        <h323implementors@imtc.org>, 
        <h323implementors@pulver.com></FONT> <BR><FONT face=sans-serif 
        size=1>        cc:       
         </FONT> <BR><FONT face=sans-serif size=1>      
          Subject:        Re: [H225 Annex G] When to 
        create a new service ID</FONT></TR></TBODY></TABLE><BR><BR><BR><BR><FONT 
  face=sans-serif size=3>Michael,</FONT> <BR><FONT face=sans-serif 
  size=3> </FONT> <BR><FONT face=sans-serif size=3>My opinion is that, 
  given that there is a ServiceRequest  and a ServiceRelease and that one 
  can initiate a new service relationship before  terminating a previous 
  service relationship, a new service ID shall be  introduced with a 
  ServiceRequest message and a BE should not send a new  ServiceRequest 
  with the same ID without first releasing the previous 
   relationship.</FONT> <BR><FONT face=sans-serif size=3> </FONT> 
  <BR><FONT face=sans-serif size=3>I believe that's in alignment with your 
   interpretation.</FONT> <BR><FONT face=sans-serif size=3> </FONT> 
  <BR><FONT face=sans-serif size=3>Paul</FONT> <BR><FONT face=sans-serif 
  size=3>----- Original Message ----- </FONT><BR><FONT face=sans-serif 
  size=3><B>From:</B>  </FONT><A 
  href="mailto:Michael_Fortinsky@VOCALTEC.COM"><FONT face=sans-serif color=blue 
  size=3><U>Michael_Fortinsky@VOCALTEC.COM</U></FONT></A><FONT face=sans-serif 
  size=3>  </FONT> <BR><FONT face=sans-serif size=3><B>To:</B> </FONT><A 
  href="mailto:ITU-SG16@mailbag.cps.intel.com"><FONT face=sans-serif color=blue 
  size=3><U>ITU-SG16@mailbag.cps.intel.com</U></FONT></A><FONT face=sans-serif 
  size=3>  ; </FONT><A href="mailto:h323implementors@imtc.org"><FONT 
  face=sans-serif color=blue 
  size=3><U>h323implementors@imtc.org</U></FONT></A><FONT face=sans-serif 
  size=3> ; </FONT><A href="mailto:h323implementors@pulver.com"><FONT 
  face=sans-serif color=blue 
  size=3><U>h323implementors@pulver.com</U></FONT></A><FONT face=sans-serif 
  size=3>  </FONT> <BR><FONT face=sans-serif size=3><B>Sent:</B> Wednesday, 
  October 18, 2000 5:40  AM</FONT> <BR><FONT face=sans-serif 
  size=3><B>Subject:</B> [H225 Annex G] When to create a  new service 
  ID</FONT> <BR><BR><BR><FONT face=sans-serif size=2>I would like to hear 
  people's interpretation of when a  new service ID should be created 
  </FONT><BR><FONT face=sans-serif size=2>in  H.225.0 Annex G. (A service 
  ID is used to identify a service relationship  between</FONT><FONT 
  face=sans-serif size=3> </FONT><BR><FONT face=sans-serif size=2>two border 
  elements).</FONT><FONT face=sans-serif size=3>  </FONT> <BR><BR><FONT 
  face=sans-serif size=2>There are three cases to consider:</FONT><FONT 
  face=sans-serif size=3>  </FONT> <BR><BR><FONT face=sans-serif 
  size=2>Case #1:</FONT><FONT face=sans-serif size=3> </FONT><BR><FONT 
  face=sans-serif size=2>- a BE (border element) receives a ServiceRequest 
  message from a BE  with which it does </FONT><BR><FONT face=sans-serif 
  size=2>  not yet have  a service relationship</FONT><FONT 
  face=sans-serif size=3> </FONT><BR><BR><FONT face=sans-serif size=2>Case 
   #2:</FONT><FONT face=sans-serif size=3> </FONT><BR><FONT face=sans-serif 
  size=2>- a BE receives a ServiceRequest  message from a BE with which it 
  already does </FONT><BR><FONT face=sans-serif size=2>  have a service 
  relationship,  but the terms of the service  relationship are to be 
  changed  </FONT><FONT face=sans-serif size=3> </FONT><BR><FONT 
  face=sans-serif size=2>  (eg, different security parameters)</FONT><FONT 
  face=sans-serif size=3> </FONT><BR><BR><FONT face=sans-serif size=2>Case 
  #3:</FONT><FONT face=sans-serif size=3> </FONT><BR><FONT face=sans-serif 
  size=2>- a BE  receives a ServiceRequest message from a BE with which it 
  already does</FONT><FONT face=sans-serif size=3>  </FONT> <BR><FONT 
  face=sans-serif size=2>  have a service relationship (ie, this 
   ServiceRequest is refreshing the service relationship), </FONT><BR><FONT 
  face=sans-serif size=2>  and the terms of the service relationship are 
   identical to the previous terms </FONT><BR><FONT face=sans-serif 
  size=2>   (eg, same security parameters)</FONT><FONT face=sans-serif 
  size=3> </FONT><BR><BR><FONT face=sans-serif size=2>My  impression is 
  that the following should happen in each case:</FONT><FONT face=sans-serif 
  size=3>  </FONT> <BR><BR><FONT face=sans-serif size=2>Case #1 - create a 
  new serviceID in the  ServiceConfirmation</FONT><FONT face=sans-serif 
  size=3> </FONT><BR><FONT face=sans-serif size=2>Case #2 - create a  new 
  serviceID because we are changing the parameters of the </FONT><BR><FONT 
  face=sans-serif size=2>                
       service relationship (it's becoming a new service 
   relationship)</FONT><FONT face=sans-serif size=3> </FONT><BR><FONT 
  face=sans-serif size=2>Case #3 -  do NOT  create a new serviceID - 
   the existing relationship is being refreshed,  </FONT> <BR><FONT 
  face=sans-serif size=2>               
         so we should continue to use the same 
   serviceID</FONT><FONT face=sans-serif size=3> </FONT><BR><BR><BR><FONT 
  face=sans-serif size=2>However, the wording  of H.225.0 Annex G does not 
  seem to say this. </FONT><BR><FONT face=sans-serif size=2>It seems that in ALL 
  cases, a new serviceID should be created.</FONT><FONT face=sans-serif size=3> 
   </FONT> <BR><FONT face=sans-serif size=2>To me, this seems to be 
  incorrect, and I'm  not sure that the original</FONT><FONT 
  face=sans-serif size=3> </FONT><BR><FONT face=sans-serif size=2>intent took 
   into account case #3.</FONT><FONT face=sans-serif size=3> 
  </FONT><BR><FONT face=sans-serif size=2>I think that in  case #3, we 
  should not be creating a new service ID.</FONT><FONT face=sans-serif size=3> 
  </FONT><BR><BR><FONT face=sans-serif size=2>The following sections from 
  H.225.0 Annex G are  relevant:</FONT><FONT face=sans-serif size=3> 
  </FONT><BR><BR><FONT face=sans-serif size=2>[from section 
   1.8.2]</FONT><FONT face=sans-serif size=3> </FONT><BR><FONT 
  face=sans-serif size=2>service ID - This identifer  identifies a 
  particular service relationship session between</FONT><FONT face=sans-serif 
  size=3> </FONT><BR><FONT face=sans-serif size=2>two border elements. Whenever 
  a border element receives  a ServiceRequest message, </FONT><BR><FONT 
  face=sans-serif size=2>it allocates  a  globally unique service ID 
  and returns it to the sender of the</FONT><FONT face=sans-serif size=3> 
   </FONT> <BR><FONT face=sans-serif size=2>ServiceRequest message in the 
  ServiceConfirm  message.</FONT><FONT face=sans-serif size=3> 
  </FONT><BR><BR><FONT face=sans-serif size=2>[from section 1.8.2.5] 
   </FONT> <BR><FONT face=sans-serif size=2>A border element may send a 
   ServiceRequest message to a border element with which </FONT><BR><FONT 
  face=sans-serif size=2>it has an existing relationship, with the intent that 
   the terms of the original relationship </FONT><BR><FONT face=sans-serif 
  size=2>be terminated and replaced with the new terms. Service relationships 
   may have limited time to live. </FONT><BR><FONT face=sans-serif size=2>A 
   border element may refresh the relationship by sending a new Service 
   Request.</FONT><FONT face=sans-serif size=3> </FONT><BR><BR><FONT 
  face=sans-serif size=2>[from section  1.8.2.6]</FONT><FONT 
  face=sans-serif size=3> </FONT><BR><FONT face=sans-serif size=2>Every new 
  service  relationship is identified by a service identifier. 
   Whenever a border  element</FONT><FONT face=sans-serif size=3> 
  </FONT><BR><FONT face=sans-serif size=2>receives a new ServiceRequest 
   message, it allocates a unique service ID and returns it to the 
   </FONT> <BR><FONT face=sans-serif size=2>sender of the service request 
  message  in the "service confirm" message. If the border element 
  already</FONT><FONT face=sans-serif size=3>  </FONT> <BR><FONT 
  face=sans-serif size=2>has a service relationship with the border 
   element that sent the ServiceRequest message, </FONT><BR><FONT 
  face=sans-serif size=2>sending ServiceConfirmation indicates that the terms of 
  the original  relationship are terminated </FONT><BR><FONT 
  face=sans-serif size=2>and  replaced with the new terms.</FONT><FONT 
  face=sans-serif size=3> </FONT><BR><BR><FONT face=sans-serif size=2>Any 
   comments?</FONT><FONT face=sans-serif size=3> </FONT><BR><FONT 
  face=sans-serif size=2>If people agree that the  wording needs to be 
  changed to unambiguously handle case #3,</FONT><FONT face=sans-serif size=3> 
  </FONT><BR><FONT face=sans-serif size=2>now is the time to speak up. The 
  deadline for  contributions for the Geneva meeting is fast 
  approaching.</FONT><FONT face=sans-serif size=3> </FONT><BR><BR><BR><FONT 
  face=sans-serif size=2>Michael  Fortinsky</FONT> <BR><FONT 
  face=sans-serif 
  size=2>-----------------------------------------------------------------</FONT> 
  <BR><FONT face=sans-serif size=2>Senior  Program Manager, IP Telephony 
  Group, VocalTec Communications Ltd.</FONT> <BR><FONT face=sans-serif 
  size=2>Email:  mike@vocaltec.com      Tel: 972 9 9707768 
        Fax: 972 9 9561867 
</FONT><BR><BR></BLOCKQUOTE></BODY></HTML>