Subject: RE: [MEDIACTRL] MS capabilities

From: "Chris Boulton" <[email-masked]>
Date: Wed, 28 Mar 2007 10:15:30 +0100

From the design as well as implementation point of view, it seems to me
to be 
much easier to let the AS also create and destroy the SIP sessions with
the 
user.

[Chris Boulton] So in essence you want the AS to terminate all media
Dialogs with endpoints?  Then use the control channel to query a MS to
enable it to populate the resulting SDP?  Sorry in advance if I am
misinterpreting BUT this two stage media mediation model (AS receive
request --> get connection/media detail from AS --> populate SDP) really
doesn't make implementation any easier.  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.

Chris.

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: Raphael Coeffic <[email-masked]>
Date: Wed, 28 Mar 2007 11:48:36 +0200

On Wednesday 28 March 2007 11:15, Chris Boulton wrote:
> enable it to populate the resulting SDP?  

[Raphael] Yes, this is exactly what i meant.

> Sorry in advance if I am 
> doesn't make implementation any easier.  

[Raphael] Well, this is the way B2BUAs are implemented, and they are not that 
bad with this strategy. As i understood, the control channel is not session 
specific (as they can be multiplexed on one channel). So, the flow would be:

[a control channel is established btw. AS and MS, whether on-demand or at 
start-up time or whenever it is required]

 1. AS receives an INVITE from user and executes some logic to figure out the 
service/application.
 2. AS uses the control channel to request a new session for the user at the 
MS, thus serving as a middle-man for the SDP negotiation. At the same time, 
the session could be added to a conference mix, or be an IVR session or 
whatever is needed.
 3. MS answers with its own SDP.
 4. AS replies the user transaction.

With the model proposed previously (excuse me in advance if i missunderstood 
anything), we would have following flow:

 1. same as above.
 2. AS forwards the INVITE to the MS and remembers the session information, to 
be able to reference it in the control channel.
 3. MS builds the 200 OK with SDP and forwards it to the AS.
 4. AS extends its record for that call leg with the AS To-tag and forwards 
back to the user.
 5. (possibly at another place) AS uses control channel to manipulate the 
session.

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 

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

Regards
Raphael.

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 28 Mar 2007 12:12:50 +0200

Hi Raphael,

Putting all in the control channel "pipe" (as the session negotiation in 
your point 2. envisages) has its own advantages, e.g. the implicit 
realization of a queue that would help avoiding race conditions and the 
like while adding/removing users to/from a session, or sessions 
themselves. However, IMHO, it would nonetheless introduce a dangerous 
single point of failure when compared to the currently proposed 
solution. Besides, it would weigh down both the AS and MS, and would 
force us to add to "reinvent the wheel" by adding to the MSCP media 
negotiation capabilities, while protocols for this, in our case SIP, 
already exist.

Just my two cents, of course.

Cheers,
Lorenzo

-- 
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: Raphael Coeffic <[email-masked]>
Date: Wed, 28 Mar 2007 12:41:19 +0200

Thanks for the answers. So we will focus on the second call flow, right?

>>  1. AS receives an INVITE from user and executes some logic to figure out
>>     the service/application.
>>  2. AS forwards the INVITE to the MS and remembers the session
>>     information, to be able to reference it in the control channel.
>>  4. AS extends its record for that call leg with the AS To-tag and
>>     forwards back to the user.

Cheers
Raphael.

On Wednesday 28 March 2007 12:12, Lorenzo Miniero wrote:
> > [Raphael] Well, this is the way B2BUAs are implemented, and they are not
> > that bad with this strategy. As i understood, the control channel is not
> > session specific (as they can be multiplexed on one channel). So, the
> > flow would be:
> >
> >  1. AS receives an INVITE from user and executes some logic to figure out
> > the service/application.
> >  2. AS uses the control channel to request a new session for the user at
> > the MS, thus serving as a middle-man for the SDP negotiation. At the same
> > time, the session could be added to a conference mix, or be an IVR
> > session or whatever is needed.
> > With the model proposed previously (excuse me in advance if i
> > missunderstood anything), we would have following flow:
> >
> >  1. same as above.
> >  2. AS forwards the INVITE to the MS and remembers the session
> > information, to be able to reference it in the control channel.
> >  4. AS extends its record for that call leg with the AS To-tag and
> > forwards back to the user.
> > If i missed anything (including some old discussion on that topic),
> > please feel free to give me some links on the topic.
> >

-- 
Dipl. Inf. Raphael Coeffic

iptelorg GmbH
Am Borsigturm 11
13507 Berlin
Germany

[email-masked]
www.iptelorg.com

T +49-30-3251-3218
F +49-30-6908-8248

---

From: "Steve Buko" <[email-masked]>
Date: Wed, 28 Mar 2007 08:33:55 -0400

I am in favor of having separate SIP dialogs for each call leg and agree
that trying to drive all that functionality through the control channel
will be troublesome.  

I think it's important to remember that we are not trying to reinvent
the 3PCC functionality that exists in so many AS today.  IMO Chris has
done a really good job of keeping this type of functionality out of the
control framework draft.  This is very important I think.

Also, I tend to disagree slightly with a few comments earlier in this
thread regarding the functionality of these SIP dialogs.  
The "y" Dialogs between the AS and MS (on behalf of the remote UA
client) are not only doing media negotiation.  
Granted, those dialogs are not doing media control functionality, but
they could be doing a number of things above and beyond the initial
media negotiation.  Media renegotiation (reINVITE) and Video I-Frame
fast update come to mind immediately.

Steve

|-----Original Message-----
|From: Raphael Coeffic [mailto:[email-masked]]
|Sent: Wednesday, March 28, 2007 6:41 AM
|To: Lorenzo Miniero
|Cc: [email-masked]
|Subject: Re: [MEDIACTRL] MS capabilities
|
|
|Thanks for the answers. So we will focus on the second call flow,
right?
|
|>>  1. AS receives an INVITE from user and executes some logic to
figure
|out
|>>     the service/application.
|>>  2. AS forwards the INVITE to the MS and remembers the session
|>>     information, to be able to reference it in the control channel.
|>>  3. MS builds the 200 OK with SDP and forwards it to the AS.
|>>  4. AS extends its record for that call leg with the AS To-tag and
|>>     forwards back to the user.
|>>  5. (possibly at another place) AS uses control channel to
manipulate
|the
|>>     session.
|
|Cheers
|Raphael.
|
|On Wednesday 28 March 2007 12:12, Lorenzo Miniero wrote:
|> Hi Raphael,
|>
|> Putting all in the control channel "pipe" (as the session negotiation
|in
|> your point 2. envisages) has its own advantages, e.g. the implicit
|> realization of a queue that would help avoiding race conditions and
|the
|> like while adding/removing users to/from a session, or sessions
|> themselves. However, IMHO, it would nonetheless introduce a dangerous
|> single point of failure when compared to the currently proposed
|> solution. Besides, it would weigh down both the AS and MS, and would
|> force us to add to "reinvent the wheel" by adding to the MSCP media
|> negotiation capabilities, while protocols for this, in our case SIP,
|> already exist.
|>
|> Just my two cents, of course.
|>
|> Cheers,
|> Lorenzo
|>
|> Raphael Coeffic ha scritto:
|> > On Wednesday 28 March 2007 11:15, Chris Boulton wrote:
|> >> From the design as well as implementation point of view, it seems
|to me
|> >> to be
|> >> much easier to let the AS also create and destroy the SIP sessions
|with
|> >> the
|> >> user.
|> >>
|> >> [Chris Boulton] So in essence you want the AS to terminate all
|media
|> >> Dialogs with endpoints?  Then use the control channel to query a
MS
|to
|> >> enable it to populate the resulting SDP?
|> >
|> > [Raphael] Yes, this is exactly what i meant.
|> >
|> >> Sorry in advance if I am
|> >> misinterpreting BUT this two stage media mediation model (AS
|receive
|> >> request --> get connection/media detail from AS --> populate SDP)
|really
|> >> doesn't make implementation any easier.
|> >
|> > [Raphael] Well, this is the way B2BUAs are implemented, and they
are
|not
|> > that bad with this strategy. As i understood, the control channel
is
|not
|> > session specific (as they can be multiplexed on one channel). So,
|the
|> > flow would be:
|> >
|> > [a control channel is established btw. AS and MS, whether on-demand
|or at
|> > start-up time or whenever it is required]
|> >
|> >  1. AS receives an INVITE from user and executes some logic to
|figure out
|> > the service/application.
|> >  2. AS uses the control channel to request a new session for the
|user at
|> > the MS, thus serving as a middle-man for the SDP negotiation. At
the
|same
|> > time, the session could be added to a conference mix, or be an IVR
|> > session or whatever is needed.
|> >  3. MS answers with its own SDP.
|> >  4. AS replies the user transaction.
|> >
|> > With the model proposed previously (excuse me in advance if i
|> > missunderstood anything), we would have following flow:
|> >
|> >  1. same as above.
|> >  2. AS forwards the INVITE to the MS and remembers the session
|> > information, to be able to reference it in the control channel.
|> >  3. MS builds the 200 OK with SDP and forwards it to the AS.
|> >  4. AS extends its record for that call leg with the AS To-tag and
|> > forwards back to the user.
|> >  5. (possibly at another place) AS uses control channel to
|manipulate the
|> > session.
|> >
|> > 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.
|> >
|> > Regards
|> > Raphael.
|> >
|> > _______________________________________________
|> > MEDIACTRL mailing list
|> > [email-masked]
|> > https://www1.ietf.org/mailman/listinfo/mediactrl
|> > Supplemental Web Site:
|> > http://www.standardstrack.com/ietf/mediactrl
|
|--
|Dipl. Inf. Raphael Coeffic
|
|iptelorg GmbH
|Am Borsigturm 11
|13507 Berlin
|Germany
|
[email-masked]
|www.iptelorg.com
|
|T +49-30-3251-3218
|F +49-30-6908-8248
|
|_______________________________________________
|MEDIACTRL mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/mediactrl
|Supplemental Web Site:
|http://www.standardstrack.com/ietf/mediactrl

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Wed, 28 Mar 2007 21:02:54 +0200

Don't know if it is inappropriate to mention this, but seeing a
reference to the XCON WG in this charter - and XCON being signaling
protocol agnostic - it seems like the capability discussion here only
embraces SIP and SDP.

Matching dialog states between endpoint-AS and AS-MS can be hard to
handle for an AS supporting Jabber clients.

Disclaimer: I write code in a SIP stack almost every day.

A question to answer could be: 
Where do we want to put our ICE and SDP capability negotiation
implementations?  Should they be in the MS, AS or in both of them?

Geir Arne

-----Original Message-----
From: Steve Buko [mailto:[email-masked]] 
Sent: 28 March 2007 14:34
To: [email-masked]
Subject: RE: [MEDIACTRL] MS capabilities

Steve

---

From: Eric Burger <[email-masked]>
Date: Thu, 29 Mar 2007 09:09:44 -0400

Another thing that might be slightly confusing is it is entirely valid to
have an AS-MS interaction without a control channel.  See RFC 4240.

> |> > understand the point.

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.

---

From: Eric Burger <[email-masked]>
Date: Thu, 29 Mar 2007 09:12:58 -0400

XCON is protocol agnostic with respect to media because the charter is all
about the UA control of the conference.

MEDIACTRL is all about an instantiation of the AS-MS protocol.  There is
more than consensus that SIP/SDP is the mechanism for media negotiation.  If
you like the split model, feel free to use H.248 (said seriously, not in
jest).  It is just that physics dictates that model is incredibly
inefficient, error prone, and virtually impossible to build multi-vendor,
interoperable solutions.