[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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