Subject: RE: [MEDIACTRL] Negotiation

From: "Syrett, Mark" <[email-masked]>
Date: Fri, 19 Oct 2007 18:10:02 +0200

Chris, all,
 
re:
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? 

It is interesting to note that for two recent protocols MSRP and MRCPv2
that the capabilities negotiation is done in SDP. This begs the
questions: "Did they get it wrong?" and "Are there good reasons for
doing it differently here?". I think it would be good to have some
coherence across these protocols that all use SIP to setup separate
channels.

MSRP looks like this:

   INVITE sip:[email-masked] SIP/2.0
   To: <sip:[email-masked]>
   From: <sip:[email-masked]>;tag=786
   Call-ID: 3413an89KU
   Content-Type: application/sdp

   c=IN IP4 atlanta.example.com
   m=message 7654 TCP/MSRP *
   a=accept-types:text/plain
   a=path:msrp://atlanta.example.com:7654/jshA7we;tcp

and MRCPv2 like this:

          INVITE sip:[email-masked] SIP/2.0
          Via:SIP/2.0/TCP client.atlanta.example.com:5060;
          branch=z9hG4bK74bf9
          Max-Forwards:6
          To:MediaServer <sip:[email-masked]>
          From:sarvi <sip:[email-masked]>;tag=1928301774
          Call-ID:a84b4c76e66710
          CSeq:314161 INVITE
          Contact:<sip:[email-masked]>
          Content-Type:application/sdp
          Content-Length: 230

          v=0
          o=sarvi 2890844526 2890842808 IN IP4 126.16.64.4
          s=-
          c=IN IP4 224.2.17.12
          m=application 9 TCP/MRCPv2
          a=setup:active
          a=connection:new
          a=resource:speechsynth
          a=cmid:1
          m=audio 49170 RTP/AVP 0 96
          a=rtpmap:0 pcmu/8000
          a=recvonly
          a=mid:1

For me using (re-using) SIP/SDP negotiation (and other SIP functions
like OPTIONS for resource discovery etc.) would mean less new code, less
complexity, fewer interop problems etc. for a control framework
implementation.
 
    regards,
 
        Mark
 
________________________________

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

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: "Chris Boulton" <[email-masked]>
Date: Fri, 19 Oct 2007 17:43:37 +0100

Hi Mark,

It has done quiet BUT the feeling I got at the time from the group was
that this seemed like a good idea (and I personally think it's a good
idea).  It did used to be in the SIP Signaling until we moved to the
Control Framework mechanism as you mentioned.  Do folks want me to make
this an addition to the next version?

Chris.

  _____  

From: Syrett, Mark [mailto:[email-masked]] 
Sent: 19 October 2007 17:10
To: [email-masked]
Subject: RE: [MEDIACTRL] Negotiation

Chris, all,

re:

MSRP looks like this:

and MRCPv2 like this:

          v=0

    regards,

        Mark

  _____  

Hi All,

 

Chris.

---

From: "Adnan Saleem" <[email-masked]>
Date: Fri, 19 Oct 2007 12:37:36 -0700

I agree with Mark's suggestions below, so I vote for moving this to SIP
signalling.
 
Adnan

From: Chris Boulton [mailto:[email-masked]] 
Sent: October 19, 2007 9:44 AM
To: Syrett, Mark; [email-masked]
Subject: RE: [MEDIACTRL] Negotiation

Hi Mark,

Chris.

Chris, all,

re:

MSRP looks like this:

and MRCPv2 like this:

          v=0

    regards,

        Mark

Hi All,

 

Chris.

---

From: Eric Burger <[email-masked]>
Date: Mon, 22 Oct 2007 09:12:13 -0700

[As participant]
I agree with Mark and Adnan.

[As chair of speechsc]
The reason for negotiating capabilities at the SIP level is the client needs
to know the given speech resource can get the job done.  Moreover, we
anticipated speech resource brokers, akin to our MRB, that could dole out
the requests to specialized speech resources.

Note MRCPv2 also has configuration and low-level capabilities discovery
within the MRCPv2 (i.e., control) channel.  However, they do NOT duplicate
the coarse-grained resource negotiation done at the SIP level.

I would offer that logic would hold for us in mediactrl.

[As chair of mediactrl]
We got slapped around silly for even mentioning an extension to SIP in the
early boulton drafts (lower case to indicate it isn't Chris' fault, as he
was reflecting the consensus of the BOFs).  Spencer and I will figure out
how best to proceed.

On 10/19/07 3:37 PM, "Adnan Saleem" <[email-masked]> wrote:

> It has done quiet BUT the feeling I got at the time from the group was that
> this seemed like a good idea (and I personally think it¹s a good idea).  It
> did used to be in the SIP Signaling until we moved to the Control Framework
> mechanism as you mentioned.  Do folks want me to make this an addition to the
> next version?
>  
> Chris.
>  
>  
> 
> 
> 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?
>  
> It is interesting to note that for two recent protocols MSRP and MRCPv2 that
> the capabilities negotiation is done in SDP. This begs the questions: "Did
> they get it wrong?" and "Are there good reasons for doing it differently
> here?". I think it would be good to have some coherence across these protocols
> that all use SIP to setup separate channels.
>  
> MSRP looks like this:
>  
> For me using (re-using) SIP/SDP negotiation (and other SIP functions like
> OPTIONS for resource discovery etc.) would mean less new code, less
> 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.
>  
>  
>  
> 
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.