Subject: [MEDIACTRL] First pass at new text

From: "Chris Boulton" <[email-masked]>
Date: Tue, 28 Nov 2006 15:19:30 -0000

OK - here is a first pass at some text that would be included in a new
section describing the keep-alive mechanism (as previously mentioned) -
this is just a rough first pass:

<keep-alive>

It is reasonable to expect this document to be used in various network
architectures.  This will include a wide range of deployments where the
clients could be co-located in a secured, private domain or spread
across disparate domains that require traversal of devices such as
Network Address Translators (NAT) and Firewalls (which is covered in
'ref').  It is important, therefore, that this document provides a
'keep-alive' mechanism that enables the control channel being created to
firstly be kept active during times of inactivity (most Firewalls have a
timeout period after which connections are closed) and also provide the
ability for application level failure detection.  It should be noted at
this point that the following procedures apply explicitly to the control
channel being created and for details relating to a SIP keep-alive
mechanism implementers should seek guidance from [insert ref for
Outbound/STUN etc].  The following 'keep-alive' procedures SHOULD be
implemented by all entities but MAY NOT be implemented if it can be
guaranteed that deployments will only occur with entities in a
co-located domain.  It should be noted that choosing to not implement
the 'keep-alive' mechanism in this section, even when in a co-located
architecture, will reduce the ability to detect application level errors
- especially during long periods of in-activity.

[sub-section] Timeout NegotiatFrom [email-masked] Tue Nov 28 12:18:33 2006
content-class: urn:content-classes:message
Date: Tue, 28 Nov 2006 15:19:30 -0000
From: "Chris Boulton" <[email-masked]>
To: <[email-masked]>
Subject: [MEDIACTRL] First pass at new text

This is a multi-part message in MIME format.
OK - here is a first pass at some text that would be included in a new
section describing the keep-alive mechanism (as previously mentioned) -
this is just a rough first pass:

<keep-alive>

It is reasonable to expect this document to be used in various network
architectures.  This will include a wide range of deployments where the
clients could be co-located in a secured, private domain or spread
across disparate domains that require traversal of devices such as
Network Address Translators (NAT) and Firewalls (which is covered in
'ref').  It is important, therefore, that this document provides a
'keep-alive' mechanism that enables the control channel being created to
firstly be kept active during times of inactivity (most Firewalls have a
timeout period after which connections are closed) and also provide the
ability for application level failure detection.  It should be noted at
this point that the following procedures apply explicitly to the control
channel being created and for details relating to a SIP keep-alive
mechanism implementers should seek guidance from [insert ref for
Outbound/STUN etc].  The following 'keep-alive' procedures SHOULD be
implemented by all entities but MAY NOT be implemented if it can be
guaranteed that deployments will only occur with entities in a
co-located domain.  It should be noted that choosing to not implement
the 'keep-alive' mechanism in this section, even when in a co-located
architecture, will reduce the ability to detect application level errors
- especially during long periods of in-activity.

[sub-section] Timeout Negotiation

During the SIP session negotiation the clients will also negotiate a
timeout period for the control channel 'keep-alive' mechanism.  The
following rules MUST be obeyed in conjunction with COMEDIA [ref]:

-          If the Client initiating the SIP INVITE request has a COMEDIA
'setup' attribute equal to 'active', the 'k-alive' 'Control-Packages'
SIP header parameter MUST be included.  The value of the 'k-alive'
header parameter SHOULD be in the range of 95 and 120 seconds (this is
consistent with SIP Outbound).  The client generating the subsequent
answer ('passive'client) MUST copy the 'k-alive' 'Control-Packages'
header parameter into the response with the same value.

-          If the Client initiating the SIP INVITE request has a COMEDIA
'setup' attribute equal to 'passive', the 'k-alive' Control-Packages'
SIP header parameter MUST NOT be included.  The client generating the
subsequent answer ('active' client) MUST include the 'k-alive' header
parameter.  The value of the 'k-alive' header parameter SHOULD be in the
range of 95 and 120 seconds.

-          If the Client initiating the SIP INVITE request has a COMEDIA
'setup' attribute equal to 'actpass', the 'k-alive' 'Control-Packages'
header parameter MUST be included.  The value of the 'k-alive' header
parameter SHOULD be in the range of 95 to 120 seconds.  If the client
generating the subsequent answer places a value of 'active' in the
COMEDIA 'setup' attribute, It MUST include a 'k-alive' header parameter
and MAY choose a value that is different from that received in the
request. The value SHOULD be in the range 95 to 120 seconds.  If the
client generating the subsequent answer places a value of 'passive' in
the COMDEDIA 'setup' attribute, it MUST copy the 'k-alive' header and
value from the request into the 'k-alive' 'Control-Packages' SIP header
parameter.

-          The 'Control-Packages' 'k-alive' header parameter MUST not be
included when the COMEDIA 'setup' attribute is equal to 'holdconn'. 

Following the previous steps ensures that the entity initiating the
control channel connection is always the one specifying the keep-alive
timeout period.  It will always be the initiator of the connection who
generates the 'K-ALIVE' Control Framework level messages.  The following
section describes in more detail how to generate the Control Framework
'K-ALIVE' message.

[sub-section] Generating K-ALIVE Messages

Once the SIP session has been established using the offer answer
mechanism and the control channel has been established (including the
initial identity handshake discussed in section [ref]), both the
'active' and passive' (as defined in COMEDIA) clients MUST start a
keep-alive timer equal to the value negotiated during the offer/answer
exchange (from the 'k-alive' 'Control-Packages' SIP header parameter).

When acting as an 'active' client, a K-ALIVE Control Framework message
MUST be generated before the local 'keep-alive' timer fires.  An active
client is free to send the K-ALIVE Control Framework message when ever
it chooses.  A guideline of 80% of the local 'keep-alive' timer is
suggested.  The 'passive' client MUST generate a 200 OK Control
Framework response to the K-ALIVE message and reset the local
'keep-alive' timer.  No other Control Framework response is valid.  On
receiving the 200 OK Control Framework message, the 'active' client MUST
reset the local 'keep-alive' timer.  If no 200 OK response is received
to the K-ALIVE Control Framework message, before the local 'keep-alive'
timer fires, the 'active' client SHOULD tear down the SIP dialog and
recover the associated control channel resources.  The 'active' client
MAY choose to try and recover the connection by renegotiation using
COMEDIA. 

When acting as a 'passive' client, a K-ALIVE Control Framework message
MUST be received before the local 'keep-alive' timer fires.  The
'passive' client MUST generate a 200 OK control framework response to
the K-ALIVE Control Framework message.  On sending the 200 OK response,
the 'passive' client MUST reset the local 'keepion

During the SIP session negotiation the clients will also negotiate a
timeout period for the control channel 'keep-alive' mechanism.  The
following rules MUST be obeyed in conjunction with COMEDIA [ref]:

-          If the Client initiating the SIP INVITE request has a COMEDIA
'setup' attribute equal to 'active', the 'k-alive' 'Control-Packages'
SIP header parameter MUST be included.  The value of the 'k-alive'
header parameter SHOULD be in the range of 95 and 120 seconds (this is
consistent with SIP Outbound).  The client generating the subsequent
answer ('passive'client) MUST copy the 'k-alive' 'Control-Packages'
header parameter into the response with the same value.

-          If the Client initiating the SIP INVITE request has a COMEDIA
'setup' attribute equal to 'passive', the 'k-alive' Control-Packages'
SIP header parameter MUST NOT be included.  The client generating the
subsequent answer ('active' client) MUST include the 'k-alive' header
parameter.  The value of the 'k-alive' header parameter SHOULD be in the
range of 95 and 120 seconds.

-          If the Client initiating the SIP INVITE request has a COMEDIA
'setup' attribute equal to 'actpass', the 'k-alive' 'Control-Packages'
header parameter MUST be included.  The value of the 'k-alive' header
parameter SHOULD be in the range of 95 to 120 seconds.  If the client
generating the subsequent answer places a value of 'active' in the
COMEDIA 'setup' attribute, It MUST include a 'k-alive' header parameter
and MAY choose a value that is different from that received in the
request. The value SHOULD be in the range 95 to 120 seconds.  If the
client generating the subsequent answer places a value of 'passive' in
the COMDEDIA 'setup' attribute, it MUST copy the 'k-alive' header and
value from the request into the 'k-alive' 'Control-Packages' SIP header
parameter.

-          The 'Control-Packages' 'k-alive' header parameter MUST not be
included when the COMEDIA 'setup' attribute is equal to 'holdconn'. 

Following the previous steps ensures that the entity initiating the
control channel connection is always the one specifying the keep-alive
timeout period.  It will always be the initiator of the connection who
generates the 'K-ALIVE' Control Framework level messages.  The following
section describes in more detail how to generate the Control Framework
'K-ALIVE' message.

[sub-section] Generating K-ALIVE Messages

Once the SIP session has been established using the offer answer
mechanism and the control channel has been established (including the
initial identity handshake discussed in section [ref]), both the
'active' and passive' (as defined in COMEDIA) clients MUST start a
keep-alive timer equal to the value negotiated during the offer/answer
exchange (from the 'k-alive' 'Control-Packages' SIP header parameter).

When acting as an 'active' client, a K-ALIVE Control Framework message
MUST be generated before the local 'keep-alive' timer fires.  An active
client is free to send the K-ALIVE Control Framework message when ever
it chooses.  A guideline of 80% of the local 'keep-alive' timer is
suggested.  The 'passive' client MUST generate a 200 OK Control
Framework response to the K-ALIVE message and reset the local
'keep-alive' timer.  No other Control Framework response is valid.  On
receiving the 200 OK Control Framework message, the 'active' client MUST
reset the local 'keep-alive' timer.  If no 200 OK response is received
to the K-ALIVE Control Framework message, before the local 'keep-alive'
timer fires, the 'active' client SHOULD tear down the SIP dialog and
recover the associated control channel resources.  The 'active' client
MAY choose to try and recover the connection by renegotiation using
COMEDIA. 

When acting as a 'passive' client, a K-ALIVE Control Framework message
MUST be received before the local 'keep-alive' timer fires.  The
'passive' client MUST generate a 200 OK control framework response to
the K-ALIVE Control Framework message.  On sending the 200 OK response,
the 'passive' client MUST reset the local 'keep-alive' timer.  If no
K-ALIVE message is received before the local 'keep-alive' timer fires,
the 'passive' client SHOULD tear down the SIP dialog and recover the
associated control channel resources.  The 'active' client MAY try to
and recover the connection by renegotiating using COMEDIA.  

See the example call flow in section [ref] for more details.

</keep-alive>

------------------------------------------------------------------------
------------------------------------------------------------------------
------------------------------------------------------

TODO - is the 'Control-Packages' header parameter the right place - if
yes then need to define fully in doc.

TODO - need to define BNF for K-ALIVE message - is this an appropriate
name?

TODO - Need to define the Control-Packages 'k-alive' header parameter.

TODO - update the call flow example.

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation.  All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email.  Unless otherwise expressly agreed in writing signed by an officer of Ubiquity Software Corporation, nothing in this communication shall be deemed to be legally binding.  Thank you.

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl