Subject: [MEDIACTRL] Negotiation

From: "Chris Boulton" <[email-masked]>
Date: Thu, 4 Oct 2007 10:49:12 +0100

Hi All,

Just wanted to highlight a question from Lorenzo that appeared on an
earlier mail (including my comment):

I noticed you removed the headers in the initial negotiation (Requires:
escs,

Control-Packages: ..), leaving this further negotiation to after the
channel has been setup. I think it's good to have it there, considering
it's more flexible, but wouldn't a previous negotiation be good as well?
e.g. if the MS doesn't support a CP the AS needs, then the control
channel wouldn't need to be opened at all. I remember a discussion in
Prague about having these negotiation in the SDP itself, even if I'm not
sure it would be the best solution. What are your feelings about this?

[Chris Boulton] I agree that it would be useful (hence the reason I
first put it in SIP headers).  My gut feeling is that it should be kept
out of the core framework.  We 'could' then define an extension draft
for MMUSIC that defines some new SDP attributes.  The attributes could
then provide a hint of supported packages and enable the call to be
rejected before the channel it setup.  Do others think this is a good
path forward? 

I was expecting quite a lot of feedback on this point but all has been
quiet.  It seems useful to be able to not set up a control channel in
the event of no compatibility.  The negotiation that then goes on within
the channel would be dynamic.  Thoughts?

Chris.

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

---

From: "Krishna Prasad Kalluri" <[email-masked]>
Date: Fri, 5 Oct 2007 09:48:59 +0200

Hi Chris,

I like the idea of keeping the control packages negotiation out side the
core framework.

How about server advertising the packages once the control link is
setup?

First the control channel is setup between the client and server. Then
server can publish the supported packages may be using REPORT method.

May be in some cases if a media server publishes a certain control
package it implies it has certain resources or capabilities also. 

I think this way its possible to discover the capabilities of the Media
Server also. 

Regards
/Krishna

________________________________

From: Chris Boulton [mailto:[email-masked]] 
Sent: den 4 oktober 2007 11:49
To: [email-masked]
Subject: [MEDIACTRL] Negotiation

Hi All,

 

Chris.

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 05 Oct 2007 10:25:22 +0200

Hi Krishna,

the negotiation is already done after the control link is setup, by 
means of a SYNCH request. We were asking whether this would be better 
done *before* opening the link, in the SIP dialog.

Regards,
Lorenzo

Krishna Prasad Kalluri ha scritto:
> How about server advertising the packages once the control link is setup?
> 
> ------------------------------------------------------------------------
> *From:* Chris Boulton [mailto:[email-masked]]
> *Sent:* den 4 oktober 2007 11:49
> *To:* [email-masked]
> *Subject:* [MEDIACTRL] Negotiation
> 
> Hi All,
> 
>  
> 
> ------------------------------------------------------------------------
> 

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 5 Oct 2007 10:05:55 +0100

Hi Krishna,

[Chris Boulton] Just to clarify.  The mechanism currently done within
the link is dynamic and allows addition + subtraction of package support
to a session.  This is now the preferred way to decide what PDU's will
be passed.  The question is do we want an additional mechanism (in the
SDP) that is part of the Offer/Answer exchange.  This would serve as a
hint of capability set for the upcoming channel (you show me your and I
will show you mine :-).  It's a one hit hint in the initial INVITE and
allows (at the SIP level) to not proceed if there is no chance of
talking (and not have to set up the channel to find out).  Subsequent
offer/answers do not impact as negotiation is then passed off to the one
for the control channels.

Thoughts?

---

From: "MUNSON, GARY A (GARY A)" <[email-masked]>
Date: Fri, 5 Oct 2007 09:22:22 -0400

Hi Chris,

The discussion on what to do wrt the control framework draft on this
topic has me thinking that there would be value in allowing the AS to
include in a query to the MRB the set of control packages it wants
to/could use; and that the MRB publish interface take that into account
as well, i.e., MRB knows what control package any given MS supports. 

Maybe you have already thought about it. Same  kind of motivation.

cheers,

Gary

-----Original Message-----
From: Chris Boulton [mailto:[email-masked]] 
Sent: Friday, October 05, 2007 5:06 AM
To: Lorenzo Miniero; Krishna Prasad Kalluri
Cc: [email-masked]
Subject: RE: [MEDIACTRL] Negotiation

Hi Krishna,

Thoughts?

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 8 Oct 2007 10:25:29 +0100

Hi Chris,

[Chris Boulton]Sounds reasonable to me - anyone object to this being
added to the discussion?

Chris.

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 08 Oct 2007 13:18:36 +0300

Hi Chris,

see my comments in line

/sal

On Fri, 2007-10-05 at 10:05 +0100, Chris Boulton wrote: 
> be passed.  

Actually the Krishna idea it is quite interesting. In fact inside the
link, after the link has been setup, there is no way for a peer to
discover the supported packages. The only way is trying and receiving a
422 error listing all the "Supported" packages. 

Now I have a question, what happens if a *new* SYNCH message is sent
deleting (all) the previous package(s) and adding a different one
package that it is not supported.
I guess the peer will receive a 422 error response, but does it also
means that the previous package has been deleted or not?

> The question is do we want an additional mechanism (in the

generally speaking defining a 'ctrl-framework' SDP attribute it is a
good idea. You should define it as a media-level attribute that MAY be
included in conjunction with an m= line, when the m= line indicates
"TCP/ESCS" or "TCP/TLS/ESCS" .

the 'ctrl-framework' SDP attribute should have the following syntax:

ctrl-framework = ctrl-framework-label ":" ctrl-label *(SP ctrl-label)
ctrl-framework-label = "ctrl-framework"
ctrl-label = (to be defined )

In this way you can also use this attribute to discover the capabilities
(in this case the control packages supported) via OPTION, before start
(and without the necessity) an INVITE transaction.

However, IMHO the way this attribute can impact the Offers/Answer
exchange need more thoughts.

---

From: "McGlashan, Scott" <[email-masked]>
Date: Thu, 11 Oct 2007 12:56:25 +0200

Definitely useful to have the possibility of negotiation outside the
control channel. 
 
The spec mentions other SIP methods, including caller/callee
preferences, for exposing the (package) negotiation. Would it be worth
looking at these in a little more detail? We may be able to use this
approach without requiring a extended spec from another WG. 
 
Scott 

From: Chris Boulton [mailto:[email-masked]] 
Sent: Thursday, October 04, 2007 11:49
To: [email-masked]
Subject: [MEDIACTRL] Negotiation

Hi All,

 

Chris.

---

From: "Krishna Prasad Kalluri" <[email-masked]>
Date: Thu, 25 Oct 2007 11:59:20 +0200

Salvatore,

I read the chapter 7.1.4 carefully this time and the frame work allows
control client or server to send the SYNCH request after the initial
SYNCH request from the 'active' entity or 'active' UA determined by
COMEDIA. 
Also in reply to the SYNCH the responding entity (assume Media Server)
can place any additional packages in the 'supported' header.

Now I have additional comments/questions to Chris and the group,

1) I think in the document in some places the usage of the term 'client'
is confusing. In the terms definition section under Control client it
says "In this document, we often refer to the Control Client simply as
"the Client". 

The points 2,3,4 are about the same question/comment about the term
client. The initial SYNCH can be sent by control client or control
server. Who has to send is determined by the setup='active'. So if some
thing is determined by COMEDIA setup=active (eg. Who has to send the
first SYNCH), its better not to state the client or server and keep that
as generic. 

2) Section 7: In the beginning of Section 7 what is the definition of
client?

Here is the text from the document.
As a consequence, some rules are applied to allow a connecting (defined
as 'active' role in COMEDIA) client to identify the associated SIP
dialog that triggered the connection.

Alt 1: The client is the one initiating the connection whose role is
'active' in the initial SDP a=setup attribute negotiation. rfc4145 is
not defining/using any term called client
Alt 2: We shouldn't use the term client. State some thing like 'active'
entity or 'active' UA. As Client or Server can have the 'active' role
and 
accordingly initiate the First SYNCH request.

Alt2 is better.

3) 7.1.3.2 Its the same comment as above. Instead of 'active' client Say
'active' entity (or 'active' UA) and 'passive' client to 'passive'
entity (or 'passive' UA).

4) In Section 7.1.4: From the document

"An entity receiving the initial SYNCH request should carefully examine
the contents of the "Packages" header."

[Krishna] I liked above statement. As its not stating client or server.

At the end of the 3rd para you can find
"This is to provide a hint to the client generating the SYNCH message
that the receiving client also supports the listed Control Packages."

[Krishna] Here also the same comment as above. The same kind of
confusion is there in some more sentences in this section.

5) In section 11.1 the status is defined as ("pending" / "update" /
"terminate" )
I think "notify" is missing in this 

6) First SYNCH with SBCs and NAT:

I know there is enough discussion about SBCs in this mailing list. I
assume that will be covered by another doc. I have one
more point to consider. 

If I understand this is a generic frame work and its possible to use
between control client and control server which are behind NAT.
When the client and server is behind the NAT and by the presence of SBCs
it gets more tricky. If the control channel has to pass
through the SBC then this may force both the client and server to become
active.
Related to TCP media (COMEDIA) the SBCs I saw changes a=setup:active to
a=setup:passive.

So the problem in this case is client and server both thinks they are
active and other side is passive. In this case both may 
issue the first SYNCH request. So what happens in this case? How they
synch with the packages and keep-active timer value?
Is this relevant to this document to state some thing about the presence
of SBCs in the section 7 when it talks about first SYNCH and package
negotiation
or not?

Regards
/Krishna

-----Original Message-----
From: Salvatore Loreto [mailto:[email-masked]] 
Sent: den 8 oktober 2007 12:19
To: Chris Boulton
Cc: Lorenzo Miniero; Krishna Prasad Kalluri; [email-masked]
Subject: RE: [MEDIACTRL] Negotiation

Hi Chris,

see my comments in line

/sal

On Fri, 2007-10-05 at 10:05 +0100, Chris Boulton wrote: 
> the link is dynamic and allows addition + subtraction of package 
> support to a session.  This is now the preferred way to decide what 
> PDU's will be passed.

> hint of capability set for the upcoming channel (you show me your and 
> I will show you mine :-).  It's a one hit hint in the initial INVITE 
> and allows (at the SIP level) to not proceed if there is no chance of 
> offer/answers do not impact as negotiation is then passed off to the 
> one for the control channels.