[H225 Annex G] When to create a new service ID

Paul E. Jones paulej at PACKETIZER.COM
Sat Oct 21 22:02:03 EDT 2000


Michael,

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.

I believe that's in alignment with your interpretation.

Paul
  ----- Original Message ----- 
  From: Michael_Fortinsky at VOCALTEC.COM 
  To: ITU-SG16 at mailbag.cps.intel.com ; h323implementors at imtc.org ; h323implementors at pulver.com 
  Sent: Wednesday, October 18, 2000 5:40 AM
  Subject: [H225 Annex G] When to create a new service ID



  I would like to hear people's interpretation of when a new service ID should be created 
  in H.225.0 Annex G. (A service ID is used to identify a service relationship between 
  two border elements). 

  There are three cases to consider: 

  Case #1: 
  - a BE (border element) receives a ServiceRequest message from a BE with which it does 
    not yet have a service relationship 

  Case #2: 
  - a BE receives a ServiceRequest message from a BE with which it already does 
    have a service relationship,  but the terms of the service relationship are to be changed   
    (eg, different security parameters) 

  Case #3: 
  - a BE receives a ServiceRequest message from a BE with which it already does 
    have a service relationship (ie, this ServiceRequest is refreshing the service relationship), 
    and the terms of the service relationship are identical to the previous terms 
    (eg, same security parameters) 

  My impression is that the following should happen in each case: 

  Case #1 - create a new serviceID in the ServiceConfirmation 
  Case #2 - create a new serviceID because we are changing the parameters of the 
                      service relationship (it's becoming a new service relationship) 
  Case #3 -  do NOT create a new serviceID -  the existing relationship is being refreshed, 
                       so we should continue to use the same serviceID 


  However, the wording of H.225.0 Annex G does not seem to say this. 
  It seems that in ALL cases, a new serviceID should be created. 
  To me, this seems to be incorrect, and I'm not sure that the original 
  intent took into account case #3. 
  I think that in case #3, we should not be creating a new service ID. 

  The following sections from H.225.0 Annex G are relevant: 

  [from section 1.8.2] 
  service ID - This identifer identifies a particular service relationship session between 
  two border elements. Whenever a border element receives a ServiceRequest message, 
  it allocates a  globally unique service ID and returns it to the sender of the 
  ServiceRequest message in the ServiceConfirm message. 

  [from section 1.8.2.5] 
  A border element may send a ServiceRequest message to a border element with which 
  it has an existing relationship, with the intent that the terms of the original relationship 
  be terminated and replaced with the new terms. Service relationships may have limited time to live. 
  A border element may refresh the relationship by sending a new Service Request. 

  [from section 1.8.2.6] 
  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. 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. 

  Any comments? 
  If people agree that the wording needs to be changed to unambiguously handle case #3, 
  now is the time to speak up. The deadline for contributions for the Geneva meeting is fast approaching. 


  Michael Fortinsky
  -----------------------------------------------------------------
  Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd.
  Email: mike at vocaltec.com      Tel: 972 9 9707768      Fax: 972 9 9561867 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20001021/507d2822/attachment-0001.htm>


More information about the sg16-avd mailing list