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

Michael Fortinsky Michael_Fortinsky at VOCALTEC.COM
Sun Oct 22 05:53:55 EDT 2000


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/3a6f3601/attachment-0004.html>


More information about the sg16-avd mailing list