Subject: Re: [MEDIACTRL] MS capabilities

From: "Eric Burger" <[email-masked]>
Date: Wed, 28 Mar 2007 16:09:25 -0700

What is the use case for the B2BUA?

--
Sent from my wireless e-mail device. Sorry if terse.  We all need lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.

-----Original Message-----
From: Adnan Saleem <[email-masked]>
To: Eric Burger; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
CC: [email-masked] <[email-masked]>
Sent: Wed Mar 28 13:53:56 2007
Subject: RE: [MEDIACTRL] MS capabilities

I think this issue may be addressed if the SIP dialog 
identifier (for the media session) is not directly used 
within the control commands sent over the control channel.

The problem seems to arise (with B2BUA in between) because
the B2BUA with create a new SIP call leg to the MS. And
this identifier will not be known to the AS which creates
the command to the MS and needs to identify the media
stream to be operated on. The identifier of the media 
session could be abstracted (or decoupled) from the actual 
SIP dialog which created the media session, to avoid this 
problem.

Adnan

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: March 28, 2007 1:43 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [MEDIACTRL] MS capabilities

<As paricipant>

If there is a B2BUA in the middle, as opposed to a proxy, then all bets are
off. If it is something like an SBC, then it will have to do "repair" to
keep things working. 

Any use cases out there for a B2BUA out there?

--
Sent from my wireless e-mail device. Sorry if terse.  We all need lemonade:
see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.

-----Original Message-----
From: Chris Boulton <[email-masked]>
To: Adnan Saleem <[email-masked]>; Diego B
<[email-masked]>; Eric Burger
CC: [email-masked] <[email-masked]>
Sent: Wed Mar 28 01:14:03 2007
Subject: RE: [MEDIACTRL] MS capabilities

3/
Another point to note (and still under some discussion) is how a media
session can be identified by the control 'commands' sent via one of the
control channels, which 'manipulate' a given media stream (eg play
announcement). One thought is that a unique SIP dialog identifier
(identifying one of the *y* SIP dialogs) should be directly used in the
commands sent over the control channel. 
This works fine when AS and MS are co-located, and as we had discussed in
our first WG meeting, this may not always be case when a B2BUA is in between
the AS and the MS. We will need to sort through this issue some more.

[Chris Boulton] I think this is an important scope issue to address (Mr B -
your thoughts?).  In my opinion, to make such assertions (e.g.
insertion of a B2BUA between the AS and MS) is not in the scope of the
requirements OR core protocol design.  You are correct that a B2BUA will
break the current mechanism BUT then B2BUA functionality IS NOT defined
anywhere and so whatever tricks you adopt to traverse this could adversely
fail (man I have seen some weird stuff out in the wild).  For this reason
the base should be kept as pure as possible.  IF we (as the
group) feel there is a requirement (I have already discussed this with a
number of folks) for the Control Framework to have some sort of Relay
extension (not core - as MSRP has done) then so be it.  This would allow a
Control Framework compliant box to be able to traverse and appropriately
manipulate the underlying PDU's as it would RELAY the control channel.  I am
against 'shoe-horning' logic into the core solution which will not guarantee
success due to a vast and wide variety of B2BUA behavior.

Thanks.

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.

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

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Wed, 28 Mar 2007 18:40:02 -0500

The use case is where the AS and MS are in different SP/EP domains. 

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2007 7:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [MEDIACTRL] MS capabilities

--
Sent from my wireless e-mail device. Sorry if terse.  We all need
lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what
lemonade is.

-----Original Message-----
From: Adnan Saleem <[email-masked]>
To: Eric Burger; [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>
CC: [email-masked] <[email-masked]>
Sent: Wed Mar 28 13:53:56 2007
Subject: RE: [MEDIACTRL] MS capabilities

Adnan

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: March 28, 2007 1:43 PM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]

<As paricipant>

If there is a B2BUA in the middle, as opposed to a proxy, then all bets
are
off. If it is something like an SBC, then it will have to do "repair" to
keep things working. 

--
Sent from my wireless e-mail device. Sorry if terse.  We all need
lemonade:
see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.

-----Original Message-----
From: Chris Boulton <[email-masked]>
To: Adnan Saleem <[email-masked]>; Diego B

3/
Another point to note (and still under some discussion) is how a media
session can be identified by the control 'commands' sent via one of the
control channels, which 'manipulate' a given media stream (eg play
announcement). One thought is that a unique SIP dialog identifier
(identifying one of the *y* SIP dialogs) should be directly used in the
commands sent over the control channel. 
This works fine when AS and MS are co-located, and as we had discussed
in
our first WG meeting, this may not always be case when a B2BUA is in
between
the AS and the MS. We will need to sort through this issue some more.

[Chris Boulton] I think this is an important scope issue to address (Mr
B -
your thoughts?).  In my opinion, to make such assertions (e.g.
insertion of a B2BUA between the AS and MS) is not in the scope of the
requirements OR core protocol design.  You are correct that a B2BUA will
break the current mechanism BUT then B2BUA functionality IS NOT defined
anywhere and so whatever tricks you adopt to traverse this could
adversely
fail (man I have seen some weird stuff out in the wild).  For this
reason
the base should be kept as pure as possible.  IF we (as the
group) feel there is a requirement (I have already discussed this with a
number of folks) for the Control Framework to have some sort of Relay
extension (not core - as MSRP has done) then so be it.  This would allow
a
Control Framework compliant box to be able to traverse and appropriately
manipulate the underlying PDU's as it would RELAY the control channel.
I am
against 'shoe-horning' logic into the core solution which will not
guarantee
success due to a vast and wide variety of B2BUA behavior.

Thanks.

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.

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: "Adnan Saleem" <[email-masked]>
Date: Wed, 28 Mar 2007 16:45:43 -0700

others I can think of at the moment are
inline MRBs, certain type of border elements,
and split AS nodes. This is of course not
a comprehensive list.

Adnan 

-----Original Message-----
From: Adnan Saleem <[email-masked]>
To: Eric Burger; [email-masked] <[email-masked]>;

I think this issue may be addressed if the SIP dialog identifier (for the
media session) is not directly used within the control commands sent over
the control channel.

The problem seems to arise (with B2BUA in between) because the B2BUA with
create a new SIP call leg to the MS. And this identifier will not be known
to the AS which creates the command to the MS and needs to identify the
media stream to be operated on. The identifier of the media session could be
abstracted (or decoupled) from the actual SIP dialog which created the media
session, to avoid this problem.

Adnan

-----Original Message-----
From: Eric Burger [mailto:[email-masked]]
Sent: March 28, 2007 1:43 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [MEDIACTRL] MS capabilities

<As paricipant>

-----Original Message-----
From: Chris Boulton <[email-masked]>
To: Adnan Saleem <[email-masked]>; Diego B

3/

Thanks.

Chris.