Subject: [MEDIACTRL] Fw: draft-ietf-mediactrl-sip-control-framework questions

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 15 Feb 2010 10:56:21 -0600

This draft has now completed IETF Last Call. Robert has asked the authors to respond to Henry's comments on the working group mailing list as if they were IETF Last Call comments.

This is the last step before Robert puts this draft on an IESG agenda for balloting, but we need to have responses before Robert does that.

Thanks,

Spencer

----- Original Message ----- 
From: Henry Lum 
To: [email-masked] 
Sent: Wednesday, January 06, 2010 3:51 PM
Subject: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework questions

Hi,

I am new to this set of drafts for media control, and I have and some general questions on the latest draft (11) of the framework:

-          Section 3 mentions that the control connections are orthogonal to media sessions, does that mean a control server can control call legs that are not negotiated with application/cfw? In other words, a control client can use dedicated control channel to control all other calls that the control client sends to the control server.

-          If the control client or server detects that the underlying control channel has failed (let's say the TCP connection has dropped for whatever reason), does the SIP dialog implicitly terminate? Can the client with active connection reestablish the connection using the same TCP parameters negotiated in the SDP? Does it require an new offer/answer exchange to re-establish the TCP connection?

-          Is the application/cfw MIME type required to be placed in the Content-Type of the SIP messages? The examples in the draft use application/sdp in the content type, then what is this new MIME type for? 

-          Section 4.1 says that you cannot define more than one control channel with multiple m= lines. Does that mean if I need to create redundant control channels I must use multiple SIP dialogs?

-          If control server sees multiple m= lines, then should it reject the extra ones with port set to "0" or should control server terminate the dialog?

-          I'm a bit confused with the general usage of REPORT method, is the only usage for REPORT is when CONTROL method takes a long time to respond? I see that the framework CONTROL response can embed content in the response message itself, rather than needing to use REPORT to embed content. Would there be other non-timeout cases where a package require that REPORT to be used? 

-          If an asynchronous operation takes a long time to complete, wouldn't it be better for the control server to use a separate CONTROL message instead of relying on maintaining a sequence of REPORT messages to report the status of the original request?

I'll have more questions about the IVR and mixer package after I read through them.

Thanks!
Henry

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. 

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

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Chris Boulton <[email-masked]>
Date: Tue, 16 Feb 2010 18:02:56 +0000

Spencer,

I was under the impression that all of Henry's comments were addressed 
in the latest version of the document.

Chris.

On 15/02/2010 16:56, Spencer Dawkins wrote:
> This draft has now completed IETF Last Call. Robert has asked the 
> authors to respond to Henry's comments on the working group mailing 
> list as if they were IETF Last Call comments.
> This is the last step before Robert puts this draft on an IESG agenda 
> for balloting, but we need to have responses before Robert does that.
> Thanks,
> Spencer
> *From:* Henry Lum <mailto:[email-masked]>
> *To:* [email-masked] <mailto:[email-masked]>
> *Sent:* Wednesday, January 06, 2010 3:51 PM
> *Subject:* [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework 
> questions
>
> Hi,
>
> I am new to this set of drafts for media control, and I have and some 
> general questions on the latest draft (11) of the framework:
>
> - Section 3 mentions that the control connections are orthogonal to 
> media sessions, does that mean a control server can control call legs 
> that are not negotiated with application/cfw? In other words, a 
> control client can use dedicated control channel to control all other 
> calls that the control client sends to the control server.
>
> - If the control client or server detects that the underlying control 
> channel has failed (let's say the TCP connection has dropped for 
> whatever reason), does the SIP dialog implicitly terminate? Can the 
> client with active connection reestablish the connection using the 
> same TCP parameters negotiated in the SDP? Does it require an new 
> offer/answer exchange to re-establish the TCP connection?
>
> - Is the application/cfw MIME type required to be placed in the 
> Content-Type of the SIP messages? The examples in the draft use 
> application/sdp in the content type, then what is this new MIME type for?
>
> - Section 4.1 says that you cannot define more than one control 
> channel with multiple m= lines. Does that mean if I need to create 
> redundant control channels I must use multiple SIP dialogs?
>
> - If control server sees multiple m= lines, then should it reject the 
> extra ones with port set to "0" or should control server terminate the 
> dialog?
>
> - I'm a bit confused with the general usage of REPORT method, is the 
> only usage for REPORT is when CONTROL method takes a long time to 
> respond? I see that the framework CONTROL response can embed content 
> in the response message itself, rather than needing to use REPORT to 
> embed content. Would there be other non-timeout cases where a package 
> require that REPORT to be used?
>
> - If an asynchronous operation takes a long time to complete, wouldn't 
> it be better for the control server to use a separate CONTROL message 
> instead of relying on maintaining a sequence of REPORT messages to 
> report the status of the original request?
>
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain 
> confidential and proprietary information of Alcatel-Lucent and/or its 
> affiliated entities. Access by the intended recipient only is 
> authorized. Any liability arising from any party acting, or refraining 
> from acting, on any information contained in this e-mail is hereby 
> excluded. If you are not the intended recipient, please notify the 
> sender immediately, destroy the original transmission and its 
> attachments and do not disclose the contents to any other person, use 
> it for any purpose, or store or copy the information in any medium. 
> Copyright in this e-mail and any attachments belongs to Alcatel-Lucent 
> and/or its affiliated entities.
>
> ------------------------------------------------------------------------

-- 
Chris Boulton
CTO & Co-founder
NS-Technologies <http://www.ns-technologies.com>
m: +44.7876.476681

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 16 Feb 2010 12:08:41 -0600

Ny apologies - I did not see this discussed on the mailing list. I was looking at what changed in each revision, but wasn't tracking why it changed nearly as closely.

Spencer
  ----- Original Message ----- 
  From: Chris Boulton 
  To: [email-masked] ; [email-masked] 
  Sent: Tuesday, February 16, 2010 12:02 PM
  Subject: Re: [MEDIACTRL] Fw: draft-ietf-mediactrl-sip-control-framework questions

  Spencer,

  I was under the impression that all of Henry's comments were addressed in the latest version of the document.

  Chris.

    Thanks,

    Spencer

    ----- Original Message ----- 
    From: Henry Lum 
    To: [email-masked] 
    Sent: Wednesday, January 06, 2010 3:51 PM
    Subject: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework questions

    Hi,

    <!--[if !supportLists]-->-          <!--[endif]-->Section 3 mentions that the control connections are orthogonal to media sessions, does that mean a control server can control call legs that are not negotiated with application/cfw? In other words, a control client can use dedicated control channel to control all other calls that the control client sends to the control server.

    <!--[if !supportLists]-->-          <!--[endif]-->If the control client or server detects that the underlying control channel has failed (let's say the TCP connection has dropped for whatever reason), does the SIP dialog implicitly terminate? Can the client with active connection reestablish the connection using the same TCP parameters negotiated in the SDP? Does it require an new offer/answer exchange to re-establish the TCP connection?

    <!--[if !supportLists]-->-          <!--[endif]-->Is the application/cfw MIME type required to be placed in the Content-Type of the SIP messages? The examples in the draft use application/sdp in the content type, then what is this new MIME type for? 

    <!--[if !supportLists]-->-          <!--[endif]-->Section 4.1 says that you cannot define more than one control channel with multiple m= lines. Does that mean if I need to create redundant control channels I must use multiple SIP dialogs?

    <!--[if !supportLists]-->-          <!--[endif]-->If control server sees multiple m= lines, then should it reject the extra ones with port set to "0" or should control server terminate the dialog?

    <!--[if !supportLists]-->-          <!--[endif]-->I'm a bit confused with the general usage of REPORT method, is the only usage for REPORT is when CONTROL method takes a long time to respond? I see that the framework CONTROL response can embed content in the response message itself, rather than needing to use REPORT to embed content. Would there be other non-timeout cases where a package require that REPORT to be used? 

    <!--[if !supportLists]-->-          <!--[endif]-->If an asynchronous operation takes a long time to complete, wouldn't it be better for the control server to use a separate CONTROL message instead of relying on maintaining a sequence of REPORT messages to report the status of the original request?

    Thanks!
    Henry

----------------------------------------------------------------------------
    _______________________________________________
    MEDIACTRL mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/mediactrl
    Supplemental Web Site:
    http://www.standardstrack.com/ietf/mediactrl

  -- 
  Chris Boulton
  CTO & Co-founder
  NS-Technologies
  m: +44.7876.476681