<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4207.2601" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial>Michael,</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Looking into this further, I believe the Annex G text
actually clarifies this (text includes text from the IG):</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV><FONT face=Arial color=#0000ff><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><STRONG>G.8.2.6
Service Confirmation</STRONG></SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff><SPAN
style="FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-bidi-font-size: 10.0pt; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">A
border element in receipt of a ServiceRequest message responds with a
ServiceConfirmation message to indicate that it agrees to establish a service
relationship. <U><FONT color=#ff0000>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.</FONT></U> 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.</SPAN></FONT></DIV></BLOCKQUOTE>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>We have two ways to resolve this:</FONT></DIV>
<OL>
<LI><FONT face=Arial>Remove the serviceID field</FONT></LI>
<LI><FONT face=Arial>Add more text to clarify the usage of the serviceID
field</FONT></LI></OL>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>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.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>Paul</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=Michael_Fortinsky@vocaltec.com
href="mailto:Michael_Fortinsky@vocaltec.com">Michael_Fortinsky@vocaltec.com</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=paulej@packetizer.com
href="mailto:paulej@packetizer.com">Paul E. Jones</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=h323implementors@pulver.com
href="mailto:h323implementors@pulver.com">h323implementors@pulver.com</A> ; <A
title=h323implementors@imtc.org
href="mailto:h323implementors@imtc.org">h323implementors@imtc.org</A> ; <A
title=ITU-SG16@mailbag.cps.intel.com
href="mailto:ITU-SG16@mailbag.cps.intel.com">ITU-SG16@mailbag.cps.intel.com</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Sunday, October 22, 2000 5:53
AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [H225 Annex G] When to
create a new service ID</DIV>
<DIV><BR></DIV><BR><FONT face=sans-serif size=2>Paul,</FONT> <BR><BR><FONT
face=sans-serif size=2>Maybe I don't understand your point - I am not sure
what you mean when you</FONT> <BR><FONT face=sans-serif size=2>say "a new
ServiceRequest". (I think this is the heart of the matter - what</FONT>
<BR><FONT face=sans-serif size=2>determines what is a NEW
ServiceRequest?)</FONT> <BR><BR><FONT face=sans-serif size=2>New service ID's
are allocated and returned in the ServiceConfirmation message,
</FONT><BR><FONT face=sans-serif size=2>not in the ServiceRequest
message.</FONT> <BR><FONT face=sans-serif size=2>Therefore, it is up to the
border element that receives the ServiceRequest message </FONT><BR><FONT
face=sans-serif size=2>to decide whether to allocate a new service ID or
not.</FONT> <BR><FONT face=sans-serif size=2>The question still remains - how
are "keepAlive" ServiceRequests to be treated?</FONT> <BR><BR><FONT
face=sans-serif size=2>Another way of looking at the issue is as follows
(maybe this is clearer):</FONT> <BR><BR><FONT face=sans-serif size=2>If a BE
sends a ServiceRequest message that does NOT contain</FONT> <BR><FONT
face=sans-serif size=2>a serviceID field, a new service ID is returned in the
ServiceConfirmation</FONT> <BR><FONT face=sans-serif size=2>message and a new
service relationship is defined.</FONT> <BR><BR><FONT face=sans-serif
size=2>If a BE sends a ServiceRequest message that DOES contains a serviceID
field,</FONT> <BR><FONT face=sans-serif size=2>the BE that received the
ServiceRequest must determine whether to </FONT><BR><FONT face=sans-serif
size=2>return the same serviceID or a new one (ie, is there going to be a
new</FONT> <BR><FONT face=sans-serif size=2>service relationship or
not)</FONT> <BR><BR><FONT face=sans-serif size=2>- if the service parameters
in the ServiceRequest are the same as those in the existing</FONT> <BR><FONT
face=sans-serif size=2> service relationship, this ServiceRequest
message is a refresh of the existing</FONT> <BR><FONT face=sans-serif
size=2> service relationship and the ServiceConfirmation is returned
with the </FONT><BR><FONT face=sans-serif size=2> same service ID as was
in the ServiceRequest</FONT> <BR><BR><FONT face=sans-serif size=2>- if the
service parameters are different, then:</FONT> <BR><FONT face=sans-serif
size=2> - if the BE want to accept the new parameters, it sends a
ServiceConfirmation</FONT> <BR><FONT face=sans-serif size=2>
that contains a NEW serviceID - this also indicates that the previous
</FONT><BR><FONT face=sans-serif size=2> service
relationship has ended</FONT> <BR><BR><FONT face=sans-serif size=2> - if
the BE does not want to accept the new parameters, it sends a
ServiceRejection</FONT> <BR><FONT face=sans-serif size=2> (that
contains the serviceID from the ServiceRequest message)</FONT> <BR><FONT
face=sans-serif size=2> indicating that the new terms are
rejected - the old service relationship is still</FONT> <BR><FONT
face=sans-serif size=2> in effect according to the old service
parameters (as per section 1.8.2.7/H.225 Annex G)</FONT> <BR><BR><FONT
face=sans-serif size=2>Comments?</FONT> <BR><FONT face=sans-serif
size=2><BR>Mike</FONT> <BR><BR><BR>
<TABLE width="100%">
<TBODY>
<TR vAlign=top>
<TD>
<TD><FONT face=sans-serif size=1><B>"Paul E. Jones"
<paulej@packetizer.com></B></FONT>
<P><FONT face=sans-serif size=1>10/22/00 04:02 AM</FONT> <BR></P>
<TD><FONT face=Arial size=1> </FONT><BR><FONT
face=sans-serif size=1> To:
<Michael_Fortinsky@VOCALTEC.COM>,
<ITU-SG16@mailbag.cps.intel.com>,
<h323implementors@imtc.org>,
<h323implementors@pulver.com></FONT> <BR><FONT face=sans-serif
size=1> cc:
</FONT> <BR><FONT face=sans-serif size=1>
Subject: Re: [H225 Annex G] When to
create a new service ID</FONT></TR></TBODY></TABLE><BR><BR><BR><BR><FONT
face=sans-serif size=3>Michael,</FONT> <BR><FONT face=sans-serif
size=3> </FONT> <BR><FONT face=sans-serif size=3>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 face=sans-serif size=3> </FONT>
<BR><FONT face=sans-serif size=3>I believe that's in alignment with your
interpretation.</FONT> <BR><FONT face=sans-serif size=3> </FONT>
<BR><FONT face=sans-serif size=3>Paul</FONT> <BR><FONT face=sans-serif
size=3>----- Original Message ----- </FONT><BR><FONT face=sans-serif
size=3><B>From:</B> </FONT><A
href="mailto:Michael_Fortinsky@VOCALTEC.COM"><FONT face=sans-serif color=blue
size=3><U>Michael_Fortinsky@VOCALTEC.COM</U></FONT></A><FONT face=sans-serif
size=3> </FONT> <BR><FONT face=sans-serif size=3><B>To:</B> </FONT><A
href="mailto:ITU-SG16@mailbag.cps.intel.com"><FONT face=sans-serif color=blue
size=3><U>ITU-SG16@mailbag.cps.intel.com</U></FONT></A><FONT face=sans-serif
size=3> ; </FONT><A href="mailto:h323implementors@imtc.org"><FONT
face=sans-serif color=blue
size=3><U>h323implementors@imtc.org</U></FONT></A><FONT face=sans-serif
size=3> ; </FONT><A href="mailto:h323implementors@pulver.com"><FONT
face=sans-serif color=blue
size=3><U>h323implementors@pulver.com</U></FONT></A><FONT face=sans-serif
size=3> </FONT> <BR><FONT face=sans-serif size=3><B>Sent:</B> Wednesday,
October 18, 2000 5:40 AM</FONT> <BR><FONT face=sans-serif
size=3><B>Subject:</B> [H225 Annex G] When to create a new service
ID</FONT> <BR><BR><BR><FONT face=sans-serif size=2>I would like to hear
people's interpretation of when a new service ID should be created
</FONT><BR><FONT face=sans-serif size=2>in H.225.0 Annex G. (A service
ID is used to identify a service relationship between</FONT><FONT
face=sans-serif size=3> </FONT><BR><FONT face=sans-serif size=2>two border
elements).</FONT><FONT face=sans-serif size=3> </FONT> <BR><BR><FONT
face=sans-serif size=2>There are three cases to consider:</FONT><FONT
face=sans-serif size=3> </FONT> <BR><BR><FONT face=sans-serif
size=2>Case #1:</FONT><FONT face=sans-serif size=3> </FONT><BR><FONT
face=sans-serif size=2>- a BE (border element) receives a ServiceRequest
message from a BE with which it does </FONT><BR><FONT face=sans-serif
size=2> not yet have a service relationship</FONT><FONT
face=sans-serif size=3> </FONT><BR><BR><FONT face=sans-serif size=2>Case
#2:</FONT><FONT face=sans-serif size=3> </FONT><BR><FONT face=sans-serif
size=2>- a BE receives a ServiceRequest message from a BE with which it
already does </FONT><BR><FONT face=sans-serif size=2> have a service
relationship, but the terms of the service relationship are to be
changed </FONT><FONT face=sans-serif size=3> </FONT><BR><FONT
face=sans-serif size=2> (eg, different security parameters)</FONT><FONT
face=sans-serif size=3> </FONT><BR><BR><FONT face=sans-serif size=2>Case
#3:</FONT><FONT face=sans-serif size=3> </FONT><BR><FONT face=sans-serif
size=2>- a BE receives a ServiceRequest message from a BE with which it
already does</FONT><FONT face=sans-serif size=3> </FONT> <BR><FONT
face=sans-serif size=2> have a service relationship (ie, this
ServiceRequest is refreshing the service relationship), </FONT><BR><FONT
face=sans-serif size=2> and the terms of the service relationship are
identical to the previous terms </FONT><BR><FONT face=sans-serif
size=2> (eg, same security parameters)</FONT><FONT face=sans-serif
size=3> </FONT><BR><BR><FONT face=sans-serif size=2>My impression is
that the following should happen in each case:</FONT><FONT face=sans-serif
size=3> </FONT> <BR><BR><FONT face=sans-serif size=2>Case #1 - create a
new serviceID in the ServiceConfirmation</FONT><FONT face=sans-serif
size=3> </FONT><BR><FONT face=sans-serif size=2>Case #2 - create a new
serviceID because we are changing the parameters of the </FONT><BR><FONT
face=sans-serif size=2>
service relationship (it's becoming a new service
relationship)</FONT><FONT face=sans-serif size=3> </FONT><BR><FONT
face=sans-serif size=2>Case #3 - do NOT create a new serviceID -
the existing relationship is being refreshed, </FONT> <BR><FONT
face=sans-serif size=2>
so we should continue to use the same
serviceID</FONT><FONT face=sans-serif size=3> </FONT><BR><BR><BR><FONT
face=sans-serif size=2>However, the wording of H.225.0 Annex G does not
seem to say this. </FONT><BR><FONT face=sans-serif size=2>It seems that in ALL
cases, a new serviceID should be created.</FONT><FONT face=sans-serif size=3>
</FONT> <BR><FONT face=sans-serif size=2>To me, this seems to be
incorrect, and I'm not sure that the original</FONT><FONT
face=sans-serif size=3> </FONT><BR><FONT face=sans-serif size=2>intent took
into account case #3.</FONT><FONT face=sans-serif size=3>
</FONT><BR><FONT face=sans-serif size=2>I think that in case #3, we
should not be creating a new service ID.</FONT><FONT face=sans-serif size=3>
</FONT><BR><BR><FONT face=sans-serif size=2>The following sections from
H.225.0 Annex G are relevant:</FONT><FONT face=sans-serif size=3>
</FONT><BR><BR><FONT face=sans-serif size=2>[from section
1.8.2]</FONT><FONT face=sans-serif size=3> </FONT><BR><FONT
face=sans-serif size=2>service ID - This identifer identifies a
particular service relationship session between</FONT><FONT face=sans-serif
size=3> </FONT><BR><FONT face=sans-serif size=2>two border elements. Whenever
a border element receives a ServiceRequest message, </FONT><BR><FONT
face=sans-serif size=2>it allocates a globally unique service ID
and returns it to the sender of the</FONT><FONT face=sans-serif size=3>
</FONT> <BR><FONT face=sans-serif size=2>ServiceRequest message in the
ServiceConfirm message.</FONT><FONT face=sans-serif size=3>
</FONT><BR><BR><FONT face=sans-serif size=2>[from section 1.8.2.5]
</FONT> <BR><FONT face=sans-serif size=2>A border element may send a
ServiceRequest message to a border element with which </FONT><BR><FONT
face=sans-serif size=2>it has an existing relationship, with the intent that
the terms of the original relationship </FONT><BR><FONT face=sans-serif
size=2>be terminated and replaced with the new terms. Service relationships
may have limited time to live. </FONT><BR><FONT face=sans-serif size=2>A
border element may refresh the relationship by sending a new Service
Request.</FONT><FONT face=sans-serif size=3> </FONT><BR><BR><FONT
face=sans-serif size=2>[from section 1.8.2.6]</FONT><FONT
face=sans-serif size=3> </FONT><BR><FONT face=sans-serif size=2>Every new
service relationship is identified by a service identifier.
Whenever a border element</FONT><FONT face=sans-serif size=3>
</FONT><BR><FONT face=sans-serif size=2>receives a new ServiceRequest
message, it allocates a unique service ID and returns it to the
</FONT> <BR><FONT face=sans-serif size=2>sender of the service request
message in the "service confirm" message. If the border element
already</FONT><FONT face=sans-serif size=3> </FONT> <BR><FONT
face=sans-serif size=2>has a service relationship with the border
element that sent the ServiceRequest message, </FONT><BR><FONT
face=sans-serif size=2>sending ServiceConfirmation indicates that the terms of
the original relationship are terminated </FONT><BR><FONT
face=sans-serif size=2>and replaced with the new terms.</FONT><FONT
face=sans-serif size=3> </FONT><BR><BR><FONT face=sans-serif size=2>Any
comments?</FONT><FONT face=sans-serif size=3> </FONT><BR><FONT
face=sans-serif size=2>If people agree that the wording needs to be
changed to unambiguously handle case #3,</FONT><FONT face=sans-serif size=3>
</FONT><BR><FONT face=sans-serif size=2>now is the time to speak up. The
deadline for contributions for the Geneva meeting is fast
approaching.</FONT><FONT face=sans-serif size=3> </FONT><BR><BR><BR><FONT
face=sans-serif size=2>Michael Fortinsky</FONT> <BR><FONT
face=sans-serif
size=2>-----------------------------------------------------------------</FONT>
<BR><FONT face=sans-serif size=2>Senior Program Manager, IP Telephony
Group, VocalTec Communications Ltd.</FONT> <BR><FONT face=sans-serif
size=2>Email: mike@vocaltec.com Tel: 972 9 9707768
Fax: 972 9 9561867
</FONT><BR><BR></BLOCKQUOTE></BODY></HTML>