Subject: RE: [MEDIACTRL] MS capabilities

From: "Chris Boulton" <[email-masked]>
Date: Wed, 4 Apr 2007 09:25:31 +0100

I think the context of Eric's point is important.  Taking SIP Servlets
as an example - you can implement a B2BUA using JSR 116 without actually
having to delve into any SDP at the application level (BUT you can if
you want to).  'DOES NOT NEED' to implies that IF the BFCP server is
running on the SIP A/S and it is required to set up connections then it
MAY need to parse SDP - if it is co-located with the MS then probably
not.

Chris.

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: 04 April 2007 07:39
To: Adnan Saleem; Eric Burger; Lorenzo Miniero
Cc: [email-masked]
Subject: RE: [MEDIACTRL] MS capabilities

Hi guys,
So please let me know where is BFCP running. Creating a BFCP connection
is done via SDP.
Roni

> -----Original Message-----
> From: Adnan Saleem [mailto:[email-masked]]
> Sent: Wednesday, April 04, 2007 6:59 AM
> To: 'Eric Burger'; 'Lorenzo Miniero'
> Cc: [email-masked]
> Subject: RE: [MEDIACTRL] MS capabilities
> 
> 
> Same view here, ie a SIP application server should never
> need to parse SDP when interfacing with MS. If needed in
> support of signalling gateways etc, then this is certainly
> out of scope.
> 
> Adnan
> 
> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: April 3, 2007 8:36 PM
> To: Lorenzo Miniero
> Cc: [email-masked]
> Subject: Re: [MEDIACTRL] MS capabilities
> 
> The AS needs to understand SDP *IF AND ONLY IF* it forwards non-SIP,
non-
> SDP
> calls.  However, for SIP calls (which is what most of us care about),
the
> AS
> *DOES NOT NEED* to understand SDP.
> 
> Please don't burden us with the corner case.  If you are building a
full
> signaling gateway (e.g., H.323 - SIP or ISUP - SIP), the little bit
extra
> to
> do SDP is trivial.  If you are building a SIP application server,
there is
> no need to build-in a requirement to parse SDP.
> 
> 
> On 3/29/07 11:53 AM, "Lorenzo Miniero" <[email-masked]>
wrote:
> 
> > Hi Roni and Eric,
> >
> > I was thinking the same thing: the AS will need to gateway different
> > CSP, and so will need to parse and talk SIP/SDP anyway in order to
> > forward non-SIP calls to the MS.
> >
> > Lorenzo
> >
> >
> >> Eric,
> >> So that goes to the question if the AS is B2BUA.
> >>
> >> What about the event package, who consolidate it if the conference
> >> span over two MS.
> >>
> >> What about H.323 clients calling an XCON AS, do you see the AS just
> >> sending H.323 to the MS.
> >>
> >> Roni
> >>
> >>> -----Original Message-----
> >>> From: Eric Burger [mailto:[email-masked]]
> >>> Sent: Thursday, March 29, 2007 5:25 PM
> >>> To: Even, Roni
> >>> Cc: [email-masked]
> >>> Subject: Re: [MEDIACTRL] MS capabilities
> >>>
> >>> Wrong layer in the stack:  "label" is an SDP attribute.  That
means
> >> the AS
> >>> MUST parse and understand the SDP, hack in a label, associate it
> >>> with
> >> a
> >>> SIP
> >>> dialog and track it around.  Requiring the AS to parse and
> >>> understand
> >> SDP
> >>> is
> >>> not good.  Allowing it is good, if the AS *does* care about
> >> manipulating
> >>> SDP, but I would offer that will be rare.
> >>>
> >>> The AS lives in the SIP level of the stack.  The *only* thing the
AS
> >> must
> >>> track is SIP dialogs.  I could see, as a hack to work around
busted
> >>> B2BUA's, adding a dialog identifier header.  Moreover, I could see
> >>> the value of that header being the AS' view of CallID, To, and
From.
> >>> The MS would
> >> consider
> >>> it
> >>> an opaque tag.
> >>>
> >>> I *really* do not like that approach, as it burdens the MS with a
> >>> ton
> >> of
> >>> state, associating this opaque tag with the real dialog ID.  Worse
> >> yet, it
> >>> re-opens all of the security problems enumerated in mscl-thoughts
> >>>
<http://www.faqs.org/ftp/internet-drafts/draft-burger-mscl-thoughts-
> >>> 01.txt>.
> >>>
> >>>
> >>> On 3/29/07 11:14 AM, "Even, Roni" <[email-masked]> wrote:
> >>>
> >>>> Eric,
> >>>> I am repeating myself. We had the same issue in the conference
> >>>> event
> >>> package;
> >>>> need to correlate between users and media in the notification and
> >> the
> >>> SIP
> >>>> dialog. RFC 4575 only use SIP information.
> >>>> Roni
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Eric Burger [mailto:[email-masked]]
> >>>>> Sent: Thursday, March 29, 2007 3:19 PM
> >>>>> To: Diego B
> >>>>> Cc: [email-masked]
> >>>>> Subject: Re: [MEDIACTRL] MS capabilities
> >>>>>
> >>>>> [As participant]
> >>>>>
> >>>>> To reiterate: B2BUA's are undefined network elements.  It is not
> >> worth
> >>>>> debating if they are good or bad.  Let us just say that it is
the
> >>>>> responsibility of the B2BUA to keep up with new protocols, not
the
> >>>>> responsibility of the IETF to hack protocols to keep up with
poor
> >> B2BUA
> >>>>> implementations.  A good B2BUA implementation will manage the
> >> protocol
> >>>>> appropriately.
> >>>>>
> >>>>> [I am saying this as participant, and not chair, as I might be
> >>> convinced
> >>>>> that we need such a beast anyway.  Jumping way ahead to
> >> implementation,
> >>> I
> >>>>> can just imagine Keith and Dean's reaction when we send a
> >> requirement
> >>> to
> >>>>> the
> >>>>> SIP Work Group asking for a mechanism (i.e., header) that looks,
> >> acts,
> >>> and
> >>>>> behaves like the SIP Dialog ID, but isn't the SIP Dialog ID...]
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 3/29/07 6:31 AM, "Diego B" <[email-masked]> wrote:
> >>>>>
> >>>>>> Inline
> >>>>>>
> >>>>>> Regards
> >>>>>> Diego B
> >>>>>>
> >>>>>> Chris Boulton wrote:
> >>>>>>> I agree, we can not decide on how the deployment may look
like.
> >>>>>>> There can be a B2BUA for several reasons ( I can think of:
> >> Billing
> >>>>>>> Mediation, Policy, Codec enforcement, Bandwith Allocation
based
> >>>>>>> on SDP negotiation on a wireless
> >>> environment,
> >>>>>>> etc).
> >>>>>>>
> >>>>>>> [Chris Boulton] There COULD be - BUT we certainly shouldn't
mold
> >> out
> >>>>>>> core solution based on the presence of a meddling middle box.
> >>>>>>>
> >>>>>> [DB] Yes, I agree with you, but those boxes are widely
deployed.
> >> It is
> >>>>> not
> >>>>>> an sporadic example. Those B2BUA are everywhere.
> >>>>>>
> >>>>>>> We may check others possibilities to coreleate  the SIP dialog
> >> and
> >>> the
> >>>>>>> media channel.
> >>>>>>> Anything related to the AS<==>MS Dialog ID can be broken by a
> >> B2BUA
> >>> in
> >>>>>>> the middle
> >>>>>>> (AS<==>B2BUA<==>MS)
> >>>>>>>
> >>>>>>> [Chris Boulton] Yes - The core solution will currently break.
> >>>>>>>
> >>>>>>> We can think of an identifier sent from the MS to the AS in
the
> >> 200
> >>> OK
> >>>>>>> in a SIP header tag.
> >>>>>>> ( A similar method was proposed to return the KA mechanism in
> >>>>>>> the outbound draft).
> >>>>>>>
> >>>>>>> [Chris Boulton] What is the difference?  You are still not
> >> guaranteed
> >>>>>>> that a B2BUA will pass this through - remember, nothing in
their
> >>>>>>> behavior is standard in this context.
> >>>>>>> Just a draft description:
> >>>>>>> AS "hints" (optional) a Session ID to the MS in the new SIP
> >> Header
> >>> tag.
> >>>>>>> if the MS accepts the session ID, it replicates it on the 200
OK
> >>>>>>> if not, it returns a new generated ID to the AS.
> >>>>>>>
> >>>>>>> [Chris Boulton] Again - how do you know for sure this
traverses
> >> the
> >>>>>>> B2BUA?
> >>>>>>>
> >>>>>> [DB]I don't know (Keep reading). But if this is a case, a B2BUA
> >> will
> >>>>>> break any new SIP extension
> >>>>>> that adds/extends  SIP headers.
> >>>>>>> Then this Session ID is used in the control channel.
> >>>>>>>
> >>>>>>> Now any B2BUA in the middle must forward any unknown SIP
> >> header/tag
> >>>>>>> untouched :)
> >>>>>>>
> >>>>>>> [Chris Boulton] BINGO!!!! - This is the very reason why this
> >> can't be
> >>>>> in
> >>>>>>> the core solution.
> >>>>>>>
> >>>>>> [DB] You reach the smiley ;)
> >>>>>>> I saw this behavior so far, any comments ?
> >>>>>>>
> >>>>>>> [Chris Boulton] As I said earlier - we should keep the core
> >> without
> >>>>> such
> >>>>>>> assumptions.  If folks REALLY think this is a requirement then
> >>>>>>> we
> >>> need
> >>>>>>> to look at an extension Relay solution (as MSRP has done)
which
> >> is
> >>>>> aware
> >>>>>>> of its requirements.  I think that should be the basis for
> >> further
> >>>>>>> discussion in the future.
> >>>>>>>
> >>>>>> [DB] This is a basic requirement. And I think this has to be
> >> defined
> >>>>> soon.
> >>>>>> I agree with you that we should keep the core without such
> >>> assumptions,
> >>>>> but
> >>>>>> we have real world out there that uses B2BUAs and we can not
> >> ignore
> >>> it.
> >>>>>> Diego B
> >>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> _______________________________________________
> >>>>> MEDIACTRL mailing list
> >>>>> [email-masked]
> >>>>> https://www1.ietf.org/mailman/listinfo/mediactrl
> >>>>> Supplemental Web Site:
> >>>>> http://www.standardstrack.com/ietf/mediactrl
> >>>
> >>>
> >>> 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.
> >>
> >> _______________________________________________
> >> MEDIACTRL mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/mediactrl
> >> Supplemental Web Site:
> >> http://www.standardstrack.com/ietf/mediactrl
> >>
> >
> 
> 
> 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.
> 
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
> 
> 
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl

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

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

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 04 Apr 2007 12:39:22 +0200

Hi all,

IMHO the AS will have to talk SDP even if not gatewaying anything.
If you think at how the framework is conceived right now, the AS does 
make use of SDP to negotiate the connection towards the MS according to 
the COMEDIA specification. So, if the AS can speak COMEDIA, it can 
certainly understand generic SDP as well, at least for parsing. Besides,
since BFCP connections are (or even better, could be) negotiated through 
a slightly enhanced COMEDIA-based SDP (RFC4583), I think this answers 
Roni's concern as well: the AS could take care of them directly. And 
BFCP is only an example: a lot of connections can be negotiated through 
SIP/SDP, and many of them could be of no interest to the MS (e.g. I 
wouldn't see the point of having the MS negotiate an MSRP session, which 
could be routed by the AS to another component).

Coming back to BFCP, let me "pull the water to my mill", as we say in 
Italy :)
Looking again at how the framework is conceived at the moment, it is 
obvious that the AS has an important logical role. For example, if you 
want a PIN-based access to a conference, the AS would create and manage 
a conference using the conference control package, and route users' 
calls to the IVR control package before assing them to the conference 
control package, since only a successful result in the IVR dialog would 
mean a successful join to the conference (e.g. the user inserting the 
right PIN). I used this simple example to underline the strong 
application logic the AS will have, and the RPC-like role of the MS: the 
AS will have to correlate results from various sources to implement a 
well-formed and well-working application. This suggests having BFCP in 
the application logic as well: it is much easier, and much cleaner, 
having the AS manage the policies regarding the access to media 
resources, and appropriately orchestrate the mixer's mixing operation 
accordingly. Besides, this is compliant with the possible "controller" 
value for <audio-mixing> in the conference control package (see section 
5.11.1).
To meet Roni's concern, however, BFCP could be implemented as a, purely 
logical of course, control package of the framework. This would give us 
a way to have the AS interact with the FCS (i.e. through the control 
channel) and thus use the results there to orchestrate the mixer's 
operations when media resources are floor-moderated, by however having 
the FCS colocated with the mixer for the other scenarios Roni described. 
What do you think about this?

Regards,
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: Eric Burger <[email-masked]>
Date: Wed, 04 Apr 2007 06:46:51 -0400

Let me echo Pelli Xu:

   I don't think we need to make a single general
   regulation on whether AS should touch SDP or not.
   Application Server is such a general term which may or
   may not do any thing.
   Whether to parse SDP should be discussed case by case
   depending on what "application" is excecuted.

The key word is "regulation."  Some proposals here would REQUIRE the AS to
touch the SDP.  Others would allow the AS to simply pass on SDP, *UNLESS*
the AS needs to examine it.

That sounds like gibberish, but it really is not.  If 90% of the AS in the
world do not need to touch the SDP, than we will have made life easy for the
bulk of the world.  Moreover, if, when you need to touch the SDP, it is easy
to do, then we have made life easy for the remaining 10%.

>> have received this message in error, please immediately return this by

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, 05 Apr 2007 07:47:21 -0400

Two observations:

First, it is considerably easier to compose a request, like COMEDIA in SDP,
than to parse a request.  The former can be hard-coded; the latter really
should be processed.

Second, while the BFCP discussion is interesting, there are at least two
orders of magnitude more IVR / announcement ports than conference ports out
there.  It is unquestionably a goal of mediactrl to meet the needs of XCON
and the conference world.  However, I would offer that we not make things
unnecessarily complex for the 99% (not 90%) case here.  In fact, given a
choice, I'd eagerly opt to make it a little harder for the 1% case if it
makes is a lot easier for the 99% case.

Don't flame on me for appearing to ignore BFCP; lower priority does not mean
"kill it."  However, lower priority does mean let's not make things hard for
the rest of us *unnecessarily*.

---

From: Lorenzo Miniero <[email-masked]>
Date: Tue, 10 Apr 2007 10:36:38 +0200

Hi Eric,

> than to parse a request.  The former can be hard-coded; the latter really

But if you compose a request, you should then parse the answer, since 
it's a negotiation. Of course, if the application is only going to 
negotiate the connection towards the MS, then parsing can be made a lot 
simplier by customizing it on the expected result (as it could be done 
if we decide the AS does not need to generically parse SDP), but I keep 
on thinking the AS should be able to at least read and parse SDP 
contents. Which does not mean the AS should modify it before passing it 
to the MS. I just see it a necessary step both for application logic 
behavior (since SDP can contain a lot of negotiations we could want to 
take care ourselves, out of the mixer) and, as Keith pointed out, for 
avoiding broken messages to be uselessly forwarded to the MS.
But I agree with you that both the solutions should be compliant with 
the work we're going to make on the MS, since this is what we're 
specifying, and not application servers...

> the rest of us *unnecessarily*.

I know, that's why I proposed the idea of having a separate control 
package for BFCP. This way the AS would have a means for accessing its 
functionality, and only if it wanted to.

Regards,
Lorenzo