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 -----
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@vocaltec.com Tel: 972 9 9707768
Fax: 972 9 9561867