Subject: RE: [MEDIACTRL] MS capabilities

From: "Chris Boulton" <[email-masked]>
Date: Thu, 29 Mar 2007 10:36:40 +0100

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. 

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?

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.

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.

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: Diego B <[email-masked]>
Date: Thu, 29 Mar 2007 12:31:57 +0200

Inline

Regards
Diego B

> 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.

> [Chris Boulton] Again - how do you know for sure this traverses the
[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.
> [Chris Boulton] BINGO!!!! - This is the very reason why this can't be in
[DB] You reach the smiley ;)
> 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

---

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

[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:

>> 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.

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Thu, 29 Mar 2007 08:36:32 -0500

AS---SBC--MS is REAL life scenario...either grow up or just go back to
school--BTW Diego B - I expect more common sense from my kids. 

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Thursday, March 29, 2007 9:19 AM
To: Diego B
Cc: [email-masked]
Subject: Re: [MEDIACTRL] MS capabilities

[As participant]

[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...]

>> Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales,
United

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: "Even, Roni" <[email-masked]>
Date: Thu, 29 Mar 2007 17:14:05 +0200

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 

> Sent: Thursday, March 29, 2007 3:19 PM

and

> > [DB] Yes, I agree with you, but those boxes are widely deployed. It
is

> not

> >> [Chris Boulton] BINGO!!!! - This is the very reason why this can't
be

> in

> >> [Chris Boulton] As I said earlier - we should keep the core without

> such

> >> to look at an extension Relay solution (as MSRP has done) which is

> aware

> > [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

> >> Information contained in this e-mail and any attachments are
intended

> for the

> >> 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,

> 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 11:25:15 -0400

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 
>  
>> and have received this message in error, please immediately return this by

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 29 Mar 2007 17:38:40 +0200

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

> Sent: Thursday, March 29, 2007 5:25 PM
> To: Even, Roni
> Cc: [email-masked]
> 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
> header being the AS' view of CallID, To, and From.  The MS would
consider
> it
> package;
> > need to correlate between users and media in the notification and
the
> SIP
> >> can just imagine Keith and Dean's reaction when we send a
requirement
> to
> >>> [DB] Yes, I agree with you, but those boxes are widely deployed.
It is
> >>>> 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
> >>>> We can think of an identifier sent from the MS to the AS in the
200
> OK
> >>>> AS "hints" (optional) a Session ID to the MS in the new SIP
Header
> tag.
> >>>> [Chris Boulton] BINGO!!!! - This is the very reason why this
can't be
> >>> we have real world out there that uses B2BUAs and we can not
ignore
> it.
intended
> >> for the
> >>>> use of the addressee only, and may contain confidential
information
> of
this
this by

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 29 Mar 2007 17:53:12 +0200

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

-- 
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: Thu, 29 Mar 2007 11:55:20 -0400

> So that goes to the question if the AS is B2BUA.

AS is almost always a B2BUA.

> What about the event package, who consolidate it if the conference span

The AS.  If the AS asks for two MS, it knows about the two MS, so it does
the consolidation.

If we decide that can go on in the MRFB, then consolidation happens in the
MRFB.  Again, the MRFB, *by definition*, is willing (and someone is paying)
to hack and track the SIP message.

> What about H.323 clients calling an XCON AS, do you see the AS just

Nope.  If the AS chooses to implement H.323, it again has to take the burden
of implementing H.323.  I would offer that is out of scope.

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Thu, 29 Mar 2007 18:36:07 +0200

If SIP and SDP is going to be used to set up the AS-MS control protocol,
the AS must understand SDP and Offer/Answer.

Geir Arne

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: 29 March 2007 17:25
To: Roni Even
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.t
xt>.

package;
is
be
assumptions,
intended
this by

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Thu, 29 Mar 2007 19:32:05 +0200

Comments inline.

Geir Arne

> Sent: 29 March 2007 17:55
> To: Roni Even
> Cc: [email-masked]

[Geir] Using SIP and SDP for call and capability control between AS and
MS, will require the AS to gateway between H.323 and SIP.

> of implementing H.323.  I would offer that is out of scope.

[Geir] We may not promote having a different CSP calling the AS, but we
should not prevent it.  Not preventing it should be in scope of this
work.

> >> I *really* do not like that approach, as it burdens the MS with a
ton
> >> re-opens all of the security problems enumerated in mscl-thoughts
<http://www.faqs.org/ftp/internet-drafts/draft-burger-mscl-thoughts-
> >> 01.txt>.
> >>>>>> [Chris Boulton] There COULD be - BUT we certainly shouldn't
mold
> > out
> >>>>>> assumptions.  If folks REALLY think this is a requirement then
we
> >> need
> >>>>>> Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA,
Wales,
this by

---

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

Yes and no: it is the difference between buying a stack and just saying
"receive call" and "place call" versus having to hack everything in the
application.

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 30 Mar 2007 11:08:48 +0300

Eric,
I think that we have to ask ourselves if the AS MS is based on the XCON
architecture.
If this is the case we should note that XCON does not support only SIP
UAs
Roni 

> Sent: Thursday, March 29, 2007 5:55 PM
> To: Even, Roni
> Cc: [email-masked]
ton
mold
we
Wales,
this by

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 30 Mar 2007 11:25:13 +0300

Eric,
I will continue with examples.

1. A UA establish a SIP connection to the AS. The AS needs IVR service
(how does it know if it needs a voice only or multimedia MS in order to
use the correct IVR MS without looking at SDP.

2. In the case of multimedia (voice + text) (voice, video +text) the AS
may use two MS for the conference (Voice+video MS and a text (SIP
SIMPLE) MS). The AS need to divide the call to two MS and present one
view to the user.

In the conferencing case to me it looks like that the conference state
is managed by the AS (This is XCON) (making the AS a sort of a what
people call B2BUA). I can agree that in some cases you can have the AS
just route calls but we need to look at the reason why we need an AS. 
If it is just routing calls than why do you need call signaling to go
through it at all. 
Maybe we should make a list of AS roles and what it information it needs
and see what part of the SIP session information it need to keep) 

Roni 

> Sent: Thursday, March 29, 2007 8:41 PM
> To: Geir Arne Sandbakken
> Cc: [email-masked]
ton of
the
requirement
> >>>> [DB] Yes, I agree with you, but those boxes are widely deployed.
It
and
B2BUA
200
Header
> >>>>> [Chris Boulton] BINGO!!!! - This is the very reason why this
can't
we
ignore
information
this
this by

---

From: Eric Burger <[email-masked]>
Date: Fri, 30 Mar 2007 11:02:38 -0400

Just a vote:

"based on XCON"?  No.

"satisfy needs from XCON"?  Yes.

---

From: "Adnan Saleem" <[email-masked]>
Date: Fri, 30 Mar 2007 09:11:39 -0700

my vote:

"based on XCON"?  No.

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: March 30, 2007 8:03 AM
To: Roni Even
Cc: [email-masked]
Subject: Re: [MEDIACTRL] MS capabilities

Just a vote:

"based on XCON"?  No.

On 3/30/07 4:08 AM, "Even, Roni" <[email-masked]> wrote:

> Eric,
> I think that we have to ask ourselves if the AS MS is based on the 
> XCON architecture.
> UAs Roni
>> If we decide that can go on in the MRFB, then consolidation happens 
>> in
> the
>> Nope.  If the AS chooses to implement H.323, it again has to take the 
>> burden of implementing H.323.  I would offer that is out of scope.
>> 
>>> 
>>> Roni
>>> 
>>>> B2BUA's, adding a dialog identifier header.  Moreover, I could see 
>>>> the value
> of
>>>> that
>>>>>>>> Mediation, Policy, Codec enforcement, Bandwith Allocation based 
>>>>>>>> on SDP negotiation on a wireless
>>>> environment,
>>>>>>>> etc).
>>>>>>>> 

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: Fri, 30 Mar 2007 13:04:33 -0400

Counter-Example 1:
If the AS is aware of multimedia and cares about different media types, then
it, by definition MAY DECIDE to dive into the SDP.  However, REQUIRING the
AS to dive into the SDP is problematic, as 90% of deployments won't have
such sophisticated routing and application logic.

We need to make sure that we do the easy, straight-forward thing for the 90%
crowd (preserve level integrity and make it easy), yet enable the complex
thing for the 10% crowd (do some application logic based on the media type
requests, what the MS has to offer, and the phase of the moon).

I would offer that not requiring the AS to parse SDP enables the 90% case.
Moreover, as a B2BUA, the AS can always parse the SDP and do whatever it
wants with it, which enables the 10% case.

Counter-Example 2:
I can virtually guarantee that you will use at least two mixing services if
you have A/V + text.  Moreover, I will absolutely guarantee that the
application server, will know, a'priori, that it will be dealing with the
possibility of such a conference, because it presumably is advertising such.
That is, I would not stand for requiring every conference application to
have to know about the potential for every service.  Rather, keep it simple
and let it be trivial for normal conference applications (i.e., the
application only does audio conferencing, so why should it have to extract
the audio m-lines?) and as arbitrarily complex as you want (i.e., the
application figures out precisely what prompts to play depending on whether
or not the caller has text available and includes the a:eatme SDP line).

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Fri, 30 Mar 2007 19:43:45 +0200

I do not think we should limit protocol work to existing stack implementations.   
 
Geir Arne

________________________________

Fra: Eric Burger [mailto:[email-masked]]
Sendt: to 29.03.2007 20:40
Til: Geir Arne Sandbakken
Kopi: [email-masked]
Emne: Re: [MEDIACTRL] MS capabilities

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 30 Mar 2007 22:00:47 +0300

Eric,
I think here we connect the topic of where BFCP runs.
Your direction requires the BFCP to run on the MS and not on the AS.
I do not see how you can do BFCP on the AS without looking at SDP
 
Roni

מאת: Eric Burger [mailto:[email-masked]]
נשלח: ו 30/03/2007 20:04
אל: Even, Roni
עותק לידיעה: [email-masked]
נושא: Re: [MEDIACTRL] MS capabilities

Counter-Example 1:

Counter-Example 2:

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 30 Mar 2007 23:49:36 +0200

Hi Eric,

whatever the case, I think we're starting to focus too much on what the AS might
or might not be/do. Whether it will just relay messages, or parse them before
forwarding (e.g. to act as gateway for other CSPs, or to trigger the
appropriate mixing service, application or whatever else according to the media
lines), the MS will still receive/send SIP from/to it, and that's what matters.
As long as the MS will receive the SDP untouched as it has been sent, of
course...

Lorenzo

Scrive Eric Burger <[email-masked]>:

> 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.
> 

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.