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

Paul E. Jones paulej at PACKETIZER.COM
Sun Oct 22 13:07:26 EDT 2000


Michael,

Looking into this further, I believe the Annex G text actually clarifies this (text includes text from the IG):

  G.8.2.6    Service Confirmation
  A border element in receipt of a ServiceRequest message responds with a ServiceConfirmation message to indicate that it agrees to establish a service relationship. 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.

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.

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.

We have two ways to resolve this:
  1.. Remove the serviceID field
  2.. Add more text to clarify the usage of the serviceID field
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.

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.

Paul

  ----- Original Message ----- 
  From: Michael_Fortinsky at vocaltec.com 
  To: Paul E. Jones 
  Cc: h323implementors at pulver.com ; h323implementors at imtc.org ; ITU-SG16 at mailbag.cps.intel.com 
  Sent: Sunday, October 22, 2000 5:53 AM
  Subject: Re: [H225 Annex G] When to create a new service ID



  Paul, 

  Maybe I don't understand your point - I am not sure what you mean when you 
  say "a new ServiceRequest". (I think this is the heart of the matter - what 
  determines what is a NEW ServiceRequest?) 

  New service ID's are allocated and returned in the ServiceConfirmation message, 
  not in the ServiceRequest message. 
  Therefore, it is up to the border element that receives the ServiceRequest message 
  to decide whether to allocate a new service ID or not. 
  The question still remains - how are "keepAlive" ServiceRequests to be treated? 

  Another way of looking at the issue is as follows (maybe this is clearer): 

  If a BE sends a ServiceRequest message that does NOT contain 
  a serviceID field, a new service ID is returned in the ServiceConfirmation 
  message and a new service relationship is defined. 

  If a BE sends a ServiceRequest message that DOES contains a serviceID field, 
  the BE that received the ServiceRequest must determine whether to 
  return the same serviceID or a new one (ie, is there going to be a new 
  service relationship or not) 

  - if the service parameters in the ServiceRequest are the same as those in the existing 
    service relationship, this ServiceRequest message is a refresh of the existing 
    service relationship and the ServiceConfirmation is returned with the 
    same service ID as was in the ServiceRequest 

  - if the service parameters are different, then: 
     - if the BE want to accept the new parameters, it sends a ServiceConfirmation 
       that contains a NEW serviceID - this also indicates that the previous 
       service relationship has ended 

    - if the BE does not want to accept the new parameters, it sends a ServiceRejection 
      (that contains the serviceID from the ServiceRequest message) 
      indicating that the new terms are rejected - the old service relationship is still 
      in effect according to the old service parameters (as per section 1.8.2.7/H.225 Annex G) 

  Comments? 

  Mike 


       "Paul E. Jones" <paulej at packetizer.com> 
        10/22/00 04:02 AM 

               
                To:        <Michael_Fortinsky at VOCALTEC.COM>, <ITU-SG16 at mailbag.cps.intel.com>, <h323implementors at imtc.org>, <h323implementors at pulver.com> 
                cc:         
                Subject:        Re: [H225 Annex G] When to create a new service ID 




  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/20001022/20c7cc4c/attachment-0001.htm>


More information about the sg16-avd mailing list