Re: [MEDIACTRL] "Media Control Channel Framework" clarifications needed

Hi Elena

I agree with your point mentioned in 1^st query and think that there should be clearer description in this regard.

About 2^nd query, here is my understanding of a 202 response:

In case a server is in process of successfully handling a control request from Client and while doing so its transaction timer expires (which is 4 seconds in this case), it needs to update the client regarding the receipt of request and at the same time update that this is not the final response for the underlying package request. Server should then send 202 indicating the response for CONTROL request however at the same time indicating that the transaction is yet not complete (note that REPORTs have same transaction id). The updates regarding the package request (mixer/ivr) shall follow in REPORT transactions.

This comes prominently into picture when downloading/uploading external files from/to an external server (eg: see mediactrl-ivr: 4.2.2 src, 4.3.1.5 loc).

Regards,

Puneet Sharma

Senior Software Engineer

Ph: +91 124 4176333 x 5105

Mob: +91 9811621209

A R I C E N T

From: mediactrl-bounces at ietf.org [mailto:mediactrl-bounces at ietf.org] On Behalf Of Tebesoi Elena-B10300
Sent: Thursday, August 27, 2009 8:45 PM
To: mediactrl at ietf.org
Subject: [MEDIACTRL] "Media Control Channel Framework" clarifications needed

Hello,

There are some paragraphs from draft-ietf-mediactrl-sip-control-framework-10 that I find to be ambiguous and I would appreciate if you can clarify them.

1. The first observation is that the terms 'the Client' and 'the Server' are not used in a consistent way.
My understanding from the above mentioned draft is that 'the Client' role would be played by an Application Server and 'the Server' role
corresponds to the Media Server, as it is suggested by the definitions of these two terms from chapter '2. Conventions and Terminology'.
Considering this, how should one interpret the information presented in chapter '6.3.4.1. Timeout Negotiation for the Initial SYNC Transaction' :

"The initial SYNC request allows the timeout period for the control-channel keep alive mechanism to be negotiated. The following rules MUST be followed for the initial SYNC request:
   o If the Client initiating the SDP Offer has a COMEDIA setup
      attribute equal to active, the Keep-Alive header MUST be included
      in the SYNC message generated by the offerer. The value of the
      Keep-Alive header SHOULD be in the range of 95 to 120 seconds
      (this is consistent with SIP Outbound[I-D.ietf-sip-outbound]).
      The client that generated the SDP "Answer" (the passive client)
      MUST copy the Keep-Alive header into the 200 response to the SYNC
      message with the same value.      .....
"

The paragraph describes the negotiation of the keep alive mechanism for the control-channel. The definition for the control channel indicates it to
be a reliable connection between a Client and a Server. However, the paragraph makes no reference to a Server, but instead it talks about an active
Client and a passive Client.

There are several other places inside the draft where the same _expression_ is used, implying the interaction of two Clients (e.g. 6.3.4.2. Package Negotiation).
If this proves to be an issue, the entire document should be revised.

2. The second question is about the 202 Reponse Code.
The definition says:
" The 202 response code indicates the completion of a successful
   framework protocol transaction with additional information to be
   provided at a later time through the REPORT mechanism defined in
   Section 6.3.2."

And in chapter 10. Examples it says:

   "In this example, the Control Client establishes a control channel,
   SYNCs with the Control Server, and issues a CONTROL request that
   can't be completed within the 'Transaction-Timeout', so the Control
   Server returns a 202 response code to extend the transaction."

My question is: the 202 response indicates the completion of a successful transaction or that the transaction will be extended?

Elena Tebeşoi

Software Engineer

Freescale Semiconductor Romania

45 Tudor Vladimirescu Street,

Tati Business Center,

Bucharest, Romania

Tel.: +40213052219

[ x ] Public

[ ] Freescale Semiconductor Internal Use Only

[ ] Freescale Semiconductor Confidential Proprietary