Subject: RE: [MEDIACTRL] MS capabilities

From: "Chris Boulton" <[email-masked]>
Date: Tue, 27 Mar 2007 17:26:45 +0100

[Chair-hat off, purely as a participant]

In the pure model, there is a one-to-one correspondence with inbound,
endpoint SIP dialogs with AS-MS SIP dialogs.  That fully leverages the
existing SIP capabilities negotiation state machine (read, existing
code).

[Chris Boulton] 100% agreed.

Passing SDP through the control channel means the control channel
mechanism
needs to re-create the SIP state machine, yet do it not in SIP.  See
H.248
for an example of where that can go wrong.

[Chris Boulton] Yuch.

I used to be adamant there would be one SIP dialog per "call leg", and
an
additional SIP dialog (or other mechanism) per "conference".  I have
been
convinced there are situations where it might be desirable to
consolidate
conference control legs, due to a perceived performance improvement from
not
having so many SIP dialogs.  For example, some folks have applications
which
are essentially all enhanced 3-party conferences (remember, simple
conferences get taken care of quite nicely by RFC 4042).  If you had a
6,000
port media server, you could have 2,000 3-party conferences, but you
would
also have 8,000 SIP dialogs (6,000 for each leg and 2,000 for each
control
channel per conference).

Thinking out loud, I think the confusion comes from thinking of the
control
channel in terms of H.248, and not in terms of SIP.  I would offer the
ONLY
way to establish a media session with a media server is with SIP. 

[Chris Boulton] Yes - that is the way the current Control Framework is
written.  The AS 'knows' about the normal SIP Sessions that have been
routed to the MS and can 'reference' then within a Control Channel.

 To
reiterate: the control channel is for manipulating those media sessions.
Manipulation DOES NOT include session establishment or tear down.

[Chris Boulton] 100% agreed and again how the current draft is written.

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.

_______________________________________________
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: Wed, 28 Mar 2007 11:12:29 +0100

If i missed anything (including some old discussion on that topic),
please 
feel free to give me some links on the topic.

> I would argue that it greatly 
> complicates the logic in the AS and introduces a whole raft of
> race/error conditions as you basically transcode SIP-->new protocol.

Could you please elaborate the reasons a little more? I quite do not 
understand the point.

[Chris Boulton] By basically transcoding between SIP and another
protocol (used on control channel) you are pulling together two
protocols that do not have the same transactional model OR requirements
e.g. handling a late offer, SDP renegotiation etc.  This is what SIP was
designed for so we should let it do its stuff.

Chris.

p.s. I'm also going to mention 'Layer Violation' before Eric does.
p.p.s. I'm also going to mention 'recreating h.248' before Eric does -
talk about stealing his thunder :-).