Subject: Re: [MEDIACTRL] MS capabilities

From: "Eric Burger" <[email-masked]>
Date: Wed, 28 Mar 2007 13:42:30 -0700

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

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

---

From: "Adnan Saleem" <[email-masked]>
Date: Wed, 28 Mar 2007 13:53:56 -0700

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. 

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

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 29 Mar 2007 10:09:22 +0200

Whether there is a use case or not, I will let other people decide on that.

What I do not is that the AS / MS interface does need to be inter-operator, and therefore does meet any measures adopted by such operators for connecting their two networks.

Regards

Keith  

> Sent: Wednesday, March 28, 2007 9:43 PM
> 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.
> 
> 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 
> 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 
> 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.
>

---

From: Diego B <[email-masked]>
Date: Thu, 29 Mar 2007 10:22:57 +0200

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

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)

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).
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.
Then this Session ID is used in the control channel.

Now any B2BUA in the middle must forward any unknown SIP header/tag 
untouched :)
I saw this behavior so far, any comments ?

Regards
Diego B

---

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

Absolutely.  Make sure the Requirements capture this.

On 3/29/07 4:09 AM, "Drage, Keith (Keith)" <[email-masked]> wrote:

> What I do not is that the AS / MS interface does need to be inter-operator,
> and therefore does meet any measures adopted by such operators for connecting
> their two networks.
> 
> Regards
> 
> Keith 
>