<br><font size=2 face="sans-serif">Paul,</font>
<br>
<br><font size=2 face="sans-serif">Maybe I don't understand your point - I am not sure what you mean when you</font>
<br><font size=2 face="sans-serif">say "a new ServiceRequest". (I think this is the heart of the matter - what</font>
<br><font size=2 face="sans-serif">determines what is a NEW ServiceRequest?)</font>
<br>
<br><font size=2 face="sans-serif">New service ID's are allocated and returned in the ServiceConfirmation message, </font>
<br><font size=2 face="sans-serif">not in the ServiceRequest message.</font>
<br><font size=2 face="sans-serif">Therefore, it is up to the border element that receives the ServiceRequest message </font>
<br><font size=2 face="sans-serif">to decide whether to allocate a new service ID or not.</font>
<br><font size=2 face="sans-serif">The question still remains - how are "keepAlive" ServiceRequests to be treated?</font>
<br>
<br><font size=2 face="sans-serif">Another way of looking at the issue is as follows (maybe this is clearer):</font>
<br>
<br><font size=2 face="sans-serif">If a BE sends a ServiceRequest message that does NOT contain</font>
<br><font size=2 face="sans-serif">a serviceID field, a new service ID is returned in the ServiceConfirmation</font>
<br><font size=2 face="sans-serif">message and a new service relationship is defined.</font>
<br>
<br><font size=2 face="sans-serif">If a BE sends a ServiceRequest message that DOES contains a serviceID field,</font>
<br><font size=2 face="sans-serif">the BE that received the ServiceRequest must determine whether to </font>
<br><font size=2 face="sans-serif">return the same serviceID or a new one (ie, is there going to be a new</font>
<br><font size=2 face="sans-serif">service relationship or not)</font>
<br>
<br><font size=2 face="sans-serif">- if the service parameters in the ServiceRequest are the same as those in the existing</font>
<br><font size=2 face="sans-serif"> service relationship, this ServiceRequest message is a refresh of the existing</font>
<br><font size=2 face="sans-serif"> service relationship and the ServiceConfirmation is returned with the </font>
<br><font size=2 face="sans-serif"> same service ID as was in the ServiceRequest</font>
<br>
<br><font size=2 face="sans-serif">- if the service parameters are different, then:</font>
<br><font size=2 face="sans-serif"> - if the BE want to accept the new parameters, it sends a ServiceConfirmation</font>
<br><font size=2 face="sans-serif"> that contains a NEW serviceID - this also indicates that the previous </font>
<br><font size=2 face="sans-serif"> service relationship has ended</font>
<br>
<br><font size=2 face="sans-serif"> - if the BE does not want to accept the new parameters, it sends a ServiceRejection</font>
<br><font size=2 face="sans-serif"> (that contains the serviceID from the ServiceRequest message)</font>
<br><font size=2 face="sans-serif"> indicating that the new terms are rejected - the old service relationship is still</font>
<br><font size=2 face="sans-serif"> in effect according to the old service parameters (as per section 1.8.2.7/H.225 Annex G)</font>
<br>
<br><font size=2 face="sans-serif">Comments?</font>
<br><font size=2 face="sans-serif"><br>
Mike</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>"Paul E. Jones" <paulej@packetizer.com></b></font>
<p><font size=1 face="sans-serif">10/22/00 04:02 AM</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To: <Michael_Fortinsky@VOCALTEC.COM>, <ITU-SG16@mailbag.cps.intel.com>, <h323implementors@imtc.org>, <h323implementors@pulver.com></font>
<br><font size=1 face="sans-serif"> cc: </font>
<br><font size=1 face="sans-serif"> Subject: Re: [H225 Annex G] When to create a new service ID</font></table>
<br>
<br>
<br>
<br><font size=3 face="sans-serif">Michael,</font>
<br><font size=3 face="sans-serif"> </font>
<br><font size=3 face="sans-serif">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 size=3 face="sans-serif"> </font>
<br><font size=3 face="sans-serif">I believe that's in alignment with your interpretation.</font>
<br><font size=3 face="sans-serif"> </font>
<br><font size=3 face="sans-serif">Paul</font>
<br><font size=3 face="sans-serif">----- Original Message ----- </font>
<br><font size=3 face="sans-serif"><b>From:</b> </font><a href=mailto:Michael_Fortinsky@VOCALTEC.COM><font size=3 color=blue face="sans-serif"><u>Michael_Fortinsky@VOCALTEC.COM</u></font></a><font size=3 face="sans-serif"> </font>
<br><font size=3 face="sans-serif"><b>To:</b> </font><a href="mailto:ITU-SG16@mailbag.cps.intel.com"><font size=3 color=blue face="sans-serif"><u>ITU-SG16@mailbag.cps.intel.com</u></font></a><font size=3 face="sans-serif"> ; </font><a href=mailto:h323implementors@imtc.org><font size=3 color=blue face="sans-serif"><u>h323implementors@imtc.org</u></font></a><font size=3 face="sans-serif"> ; </font><a href=mailto:h323implementors@pulver.com><font size=3 color=blue face="sans-serif"><u>h323implementors@pulver.com</u></font></a><font size=3 face="sans-serif"> </font>
<br><font size=3 face="sans-serif"><b>Sent:</b> Wednesday, October 18, 2000 5:40 AM</font>
<br><font size=3 face="sans-serif"><b>Subject:</b> [H225 Annex G] When to create a new service ID</font>
<br>
<br>
<br><font size=2 face="sans-serif">I would like to hear people's interpretation of when a new service ID should be created </font>
<br><font size=2 face="sans-serif">in H.225.0 Annex G. (A service ID is used to identify a service relationship between</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">two border elements).</font><font size=3 face="sans-serif"> </font>
<br>
<br><font size=2 face="sans-serif">There are three cases to consider:</font><font size=3 face="sans-serif"> </font>
<br>
<br><font size=2 face="sans-serif">Case #1:</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">- a BE (border element) receives a ServiceRequest message from a BE with which it does </font>
<br><font size=2 face="sans-serif"> not yet have a service relationship</font><font size=3 face="sans-serif"> </font>
<br>
<br><font size=2 face="sans-serif">Case #2:</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">- a BE receives a ServiceRequest message from a BE with which it already does </font>
<br><font size=2 face="sans-serif"> have a service relationship, but the terms of the service relationship are to be changed </font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> (eg, different security parameters)</font><font size=3 face="sans-serif"> </font>
<br>
<br><font size=2 face="sans-serif">Case #3:</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">- a BE receives a ServiceRequest message from a BE with which it already does</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif"> have a service relationship (ie, this ServiceRequest is refreshing the service relationship), </font>
<br><font size=2 face="sans-serif"> and the terms of the service relationship are identical to the previous terms </font>
<br><font size=2 face="sans-serif"> (eg, same security parameters)</font><font size=3 face="sans-serif"> </font>
<br>
<br><font size=2 face="sans-serif">My impression is that the following should happen in each case:</font><font size=3 face="sans-serif"> </font>
<br>
<br><font size=2 face="sans-serif">Case #1 - create a new serviceID in the ServiceConfirmation</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">Case #2 - create a new serviceID because we are changing the parameters of the </font>
<br><font size=2 face="sans-serif"> service relationship (it's becoming a new service relationship)</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">Case #3 - do NOT create a new serviceID - the existing relationship is being refreshed, </font>
<br><font size=2 face="sans-serif"> so we should continue to use the same serviceID</font><font size=3 face="sans-serif"> </font>
<br>
<br>
<br><font size=2 face="sans-serif">However, the wording of H.225.0 Annex G does not seem to say this. </font>
<br><font size=2 face="sans-serif">It seems that in ALL cases, a new serviceID should be created.</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">To me, this seems to be incorrect, and I'm not sure that the original</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">intent took into account case #3.</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">I think that in case #3, we should not be creating a new service ID.</font><font size=3 face="sans-serif"> </font>
<br>
<br><font size=2 face="sans-serif">The following sections from H.225.0 Annex G are relevant:</font><font size=3 face="sans-serif"> </font>
<br>
<br><font size=2 face="sans-serif">[from section 1.8.2]</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">service ID - This identifer identifies a particular service relationship session between</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">two border elements. Whenever a border element receives a ServiceRequest message, </font>
<br><font size=2 face="sans-serif">it allocates a globally unique service ID and returns it to the sender of the</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">ServiceRequest message in the ServiceConfirm message.</font><font size=3 face="sans-serif"> </font>
<br>
<br><font size=2 face="sans-serif">[from section 1.8.2.5] </font>
<br><font size=2 face="sans-serif">A border element may send a ServiceRequest message to a border element with which </font>
<br><font size=2 face="sans-serif">it has an existing relationship, with the intent that the terms of the original relationship </font>
<br><font size=2 face="sans-serif">be terminated and replaced with the new terms. Service relationships may have limited time to live. </font>
<br><font size=2 face="sans-serif">A border element may refresh the relationship by sending a new Service Request.</font><font size=3 face="sans-serif"> </font>
<br>
<br><font size=2 face="sans-serif">[from section 1.8.2.6]</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">Every new service relationship is identified by a service identifier. Whenever a border element</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">receives a new ServiceRequest message, it allocates a unique service ID and returns it to the </font>
<br><font size=2 face="sans-serif">sender of the service request message in the "service confirm" message. If the border element already</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">has a service relationship with the border element that sent the ServiceRequest message, </font>
<br><font size=2 face="sans-serif">sending ServiceConfirmation indicates that the terms of the original relationship are terminated </font>
<br><font size=2 face="sans-serif">and replaced with the new terms.</font><font size=3 face="sans-serif"> </font>
<br>
<br><font size=2 face="sans-serif">Any comments?</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">If people agree that the wording needs to be changed to unambiguously handle case #3,</font><font size=3 face="sans-serif"> </font>
<br><font size=2 face="sans-serif">now is the time to speak up. The deadline for contributions for the Geneva meeting is fast approaching.</font><font size=3 face="sans-serif"> </font>
<br>
<br>
<br><font size=2 face="sans-serif">Michael Fortinsky</font>
<br><font size=2 face="sans-serif">-----------------------------------------------------------------</font>
<br><font size=2 face="sans-serif">Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd.</font>
<br><font size=2 face="sans-serif">Email: mike@vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867 </font>
<br>
<br>