Subject: [MEDIACTRL] MS capabilities

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Fri, 23 Mar 2007 13:20:25 +0100

The general requirement that the MS should be able to tell the AS its
functionality will probably include media capabilities.

If we were to go ahead using SIP and SDP for setting up the control
channels, it would be tempting to use SDP for the media capabilities as
well.  

 Would the SDP then go inside the control channel, or in the SIP dialog
for setting up the channel? 

Geir Arne

_______________________________________________
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: Fri, 23 Mar 2007 14:57:37 +0200

There are two different negotiation as I see here:

1- The AS connection to the MS
They have to agree on control address ( IP:PORT )
and to agree on control packages.
At this stage the AS has no knowledge of any session that needs media resources.

2- An incoming SIP session to the AS that needs media resources (
specified in the
INVITE / ACK SDP ).
At this stage there is a control connection AS<->MS.
So, the SDP from the end point ( or any mapping performed by the
AS)must be tunneled
through the current ( or new ) media control channel.
And a negotiation procedure must take place so the AS can build and
return the SDP to the end point representing the MS capabilities for
the session.

.....
>From 2  I make a new requirement.

There has to be a way that the AS
can create an SDP for the OK response when there is no SDP on the INVITE.
This is common 3PCC scenario used in several application where
mid-call announcement
has to take place.

Regards
Diego B

On 3/23/07, Geir Arne Sandbakken <[email-masked]> wrote:
>  Would the SDP then go inside the control channel, or in the SIP dialog for
> setting up the channel?
>
>
>
> Geir Arne
>
>

---

From: "Geir Arne Sandbakken" <[email-masked]>
Date: Fri, 23 Mar 2007 14:50:01 +0100

Assuming the AS could terminate calls other than SIP, I would prefer
that such a requirement be more general:

The AS shall be able to query media capabilities for new or existing
sessions.

This requirement is for session by session handling.  What about the MS
telling the AS it's capabilities outside participant sessions?  Is this
a configuration issue outside of scope of this WG?

Geir Arne

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Diego
B
Sent: 23 March 2007 13:58
To: Geir Arne Sandbakken
Cc: [email-masked]
Subject: Re: [MEDIACTRL] MS capabilities

1- The AS connection to the MS
They have to agree on control address ( IP:PORT )
and to agree on control packages.
At this stage the AS has no knowledge of any session that needs media
resources.

.....

There has to be a way that the AS
can create an SDP for the OK response when there is no SDP on the
INVITE.
This is common 3PCC scenario used in several application where
mid-call announcement
has to take place.

Regards
Diego B

---

From: "Asher Shiratzky" <[email-masked]>
Date: Fri, 23 Mar 2007 18:43:04 +0200

The AS is terminating the SIP and SDP from the user side, based on
knowledge on MS capabilities (which is right now out of scope of the SIP
control framework, and should be solved by the MRB/ resource manager
functionality, or by AS specific functionality/ policy)
The outcome of the SDP will be transferred on the control channel , but
it does not needs to be SDP, for example it can point out to a specific
VXML which already deals with media capacities supported by the end
user, or it can be transferred as part of the control channel.

As one of the options is to multiplex multiple dialogs in one control
channel it means that SDP of the end user can't be part of the SDP for
creation of the Control Channel.

I tend to agree that there should be implicit and explicit ways to pass
the end user media capabilities as part of the control channel.

Best regards,
Asher

-----Original Message-----
From: Diego B [mailto:[email-masked]] 
Sent: Friday, March 23, 2007 2:58 PM
To: Geir Arne Sandbakken
Cc: [email-masked]
Subject: Re: [MEDIACTRL] MS capabilities

1- The AS connection to the MS
They have to agree on control address ( IP:PORT ) and to agree on
control packages.
At this stage the AS has no knowledge of any session that needs media
resources.

2- An incoming SIP session to the AS that needs media resources (
specified in the INVITE / ACK SDP ).
At this stage there is a control connection AS<->MS.
So, the SDP from the end point ( or any mapping performed by the AS)must
be tunneled through the current ( or new ) media control channel.
And a negotiation procedure must take place so the AS can build and
return the SDP to the end point representing the MS capabilities for the
session.

....

mid-call announcement
has to take place.

Regards
Diego B

On 3/23/07, Geir Arne Sandbakken <[email-masked]> wrote:
> channels, it would be tempting to use SDP for the media capabilities 
> as well.
>
>
>
>  Would the SDP then go inside the control channel, or in the SIP 
> dialog for setting up the channel?
>
>
>
> Geir Arne
>
>

---

From: Eric Burger <[email-masked]>
Date: Tue, 27 Mar 2007 11:53:40 -0400

[Chair-hat off, purely as a participant]

In the pure model, there is a one-to-one correspondence with inbound,
endpoint SIP dialogs with AS-MS SIP dialogs.  That fully leverages the
existing SIP capabilities negotiation state machine (read, existing code).

Passing SDP through the control channel means the control channel mechanism
needs to re-create the SIP state machine, yet do it not in SIP.  See H.248
for an example of where that can go wrong.

I used to be adamant there would be one SIP dialog per "call leg", and an
additional SIP dialog (or other mechanism) per "conference".  I have been
convinced there are situations where it might be desirable to consolidate
conference control legs, due to a perceived performance improvement from not
having so many SIP dialogs.  For example, some folks have applications which
are essentially all enhanced 3-party conferences (remember, simple
conferences get taken care of quite nicely by RFC 4042).  If you had a 6,000
port media server, you could have 2,000 3-party conferences, but you would
also have 8,000 SIP dialogs (6,000 for each leg and 2,000 for each control
channel per conference).

Thinking out loud, I think the confusion comes from thinking of the control
channel in terms of H.248, and not in terms of SIP.  I would offer the ONLY
way to establish a media session with a media server is with SIP.  To
reiterate: the control channel is for manipulating those media sessions.
Manipulation DOES NOT include session establishment or tear down.

>> dialog for setting up the channel?

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: Tue, 27 Mar 2007 21:15:15 +0200

What you are saying is that there is a one ( or more ) SIP dialog 
between AS-MS for the
establishment of control sessions.
And for each end-point requiring media services there is a new SIP 
Dialog between AS-MS.
So, actually each *User Agent* will do media negotiation with the MS 
using normal SIP and RFC 3264.

If I want to diagram this it may look something like (from 
draft-boulton-sip-control-framework):

                                   +--------Control SIP Dialog(n)---------+
                                   |                                      |
                                   v                                      v
  +-----+                        +-----+                                +--+--+
  |User |--------+-------------->| SIP |<----- Media SIP Dialog (y)---->| SIP |
  |Agent|        |               |Stack|                                |Stack|
  +-----+        |           +---+-----+---+                        +---+-----+---+
                 |           |             |                        |             |
  +-----+        |           |   Control   |<--Control Channel(n)-->|             |
  |User |--------+           |   Client    |                        |   Control   |
  |Agent|        |           +-------------+                        |   Server    |
  +-----+        |                                                  |             |
     :           |                                                  +-------------+
    (y)          |
     :           |
  +-----+        |
  |User |--------+
  |Agent|
  +-----+

Where *n* is the number of control sessions opened from AS to MS ( it 
can be only one if we multiplex all the control messages from one channel )
And *y* is the number of SIP end-points connected to the AS receiving 
media-services from the MS.

What is the function of the *y* SIP Dialogs ? Just media negotiation ?

Regards
Diego B

---

From: "Adnan Saleem" <[email-masked]>
Date: Tue, 27 Mar 2007 17:04:15 -0700

three comments:

1/
"So, actually each *User Agent* will do media negotiation with the MS 
using normal SIP and RFC 3264."

	  >> User agent would typically negotiate media sessions on 
           the MS, via the AS in accordance with 3PCC rules.

2/
"What is the function of the *y* SIP Dialogs ? Just media negotiation ?"
 
        >> yes, *y* SIP dialogs are used to negotiate y media sessions.

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.

Adnan

________________________________

From: Diego B [mailto:[email-masked]] 
Sent: March 27, 2007 12:15 PM
To: Eric Burger
Cc: [email-masked]
Subject: Re: [MEDIACTRL] MS capabilities

What you are saying is that there is a one ( or more ) SIP dialog between
AS-MS for the
establishment of control sessions.
And for each end-point requiring media services there is a new SIP Dialog
between AS-MS.
So, actually each *User Agent* will do media negotiation with the MS using
normal SIP and RFC 3264.

                                   +--------Control SIP Dialog(n)---------+
                                   |                                      |
                                   v                                      v
  +-----+                        +-----+
+--+--+
  |User |--------+-------------->| SIP |<----- Media SIP Dialog (y)---->|
SIP |
  |Agent|        |               |Stack|
|Stack|
  +-----+        |           +---+-----+---+
+---+-----+---+
                 |           |             |                        |
|
  +-----+        |           |   Control   |<--Control Channel(n)-->|
|
  |User |--------+           |   Client    |                        |
Control   |
  |Agent|        |           +-------------+                        |
Server    |
  +-----+        |                                                  |
|
     :           |
+-------------+
    (y)          |
     :           |
  +-----+        |
  |User |--------+
  |Agent|
  +-----+

Where *n* is the number of control sessions opened from AS to MS ( it can be
only one if we multiplex all the control messages from one channel )
And *y* is the number of SIP end-points connected to the AS receiving
media-services from the MS.

Regards
Diego B

Eric Burger wrote: 

	In the pure model, there is a one-to-one correspondence with
inbound,
	endpoint SIP dialogs with AS-MS SIP dialogs.  That fully leverages
the
	existing SIP capabilities negotiation state machine (read, existing
code).
	
	Passing SDP through the control channel means the control channel
mechanism
	needs to re-create the SIP state machine, yet do it not in SIP.  See
H.248
	for an example of where that can go wrong.
	
	I used to be adamant there would be one SIP dialog per "call leg",
and an
	additional SIP dialog (or other mechanism) per "conference".  I have
been
	convinced there are situations where it might be desirable to
consolidate
	conference control legs, due to a perceived performance improvement
from not
	having so many SIP dialogs.  For example, some folks have
applications which
	are essentially all enhanced 3-party conferences (remember, simple
	conferences get taken care of quite nicely by RFC 4042).  If you had
a 6,000
	port media server, you could have 2,000 3-party conferences, but you
would
	also have 8,000 SIP dialogs (6,000 for each leg and 2,000 for each
control
	channel per conference).
	
	Thinking out loud, I think the confusion comes from thinking of the
control
	channel in terms of H.248, and not in terms of SIP.  I would offer
the ONLY
	way to establish a media session with a media server is with SIP.
To
	reiterate: the control channel is for manipulating those media
sessions.
	Manipulation DOES NOT include session establishment or tear down.

	On 3/23/07 12:43 PM, "Asher Shiratzky" <[email-masked]>
<mailto:[email-masked]>  wrote:

		The AS is terminating the SIP and SDP from the user side,
based on
		knowledge on MS capabilities (which is right now out of
scope of the SIP
		control framework, and should be solved by the MRB/ resource
manager
		functionality, or by AS specific functionality/ policy)
		The outcome of the SDP will be transferred on the control
channel , but
		it does not needs to be SDP, for example it can point out to
a specific
		VXML which already deals with media capacities supported by
the end
		user, or it can be transferred as part of the control
channel.
		
		As one of the options is to multiplex multiple dialogs in
one control
		channel it means that SDP of the end user can't be part of
the SDP for
		creation of the Control Channel.
		
		I tend to agree that there should be implicit and explicit
ways to pass
		the end user media capabilities as part of the control
channel.
		
		Best regards,
		Asher
		
		-----Original Message-----
		From: Diego B [mailto:[email-masked]]
		Sent: Friday, March 23, 2007 2:58 PM
		To: Geir Arne Sandbakken
		Cc: [email-masked]
		Subject: Re: [MEDIACTRL] MS capabilities

		1- The AS connection to the MS
		They have to agree on control address ( IP:PORT ) and to
agree on
		control packages.
		At this stage the AS has no knowledge of any session that
needs media
		resources.
		
		2- An incoming SIP session to the AS that needs media
resources (
		specified in the INVITE / ACK SDP ).
		At this stage there is a control connection AS<->MS.
		So, the SDP from the end point ( or any mapping performed by
the AS)must
		be tunneled through the current ( or new ) media control
channel.
		And a negotiation procedure must take place so the AS can
build and
		return the SDP to the end point representing the MS
capabilities for the
		session.
		
		....

		There has to be a way that the AS
		can create an SDP for the OK response when there is no SDP
on the
		INVITE.
		This is common 3PCC scenario used in several application
where
		
		mid-call announcement
		has to take place.
		
		Regards
		Diego B
		
		On 3/23/07, Geir Arne Sandbakken
<[email-masked]> <mailto:[email-masked]>  wrote:

			
			The general requirement that the MS should be able
to tell the AS its
			functionality will probably include media
capabilities.

			If we were to go ahead using SIP and SDP for setting
up the control
			channels, it would be tempting to use SDP for the
media capabilities
			as well.

			 Would the SDP then go inside the control channel,
or in the SIP
			dialog for setting up the channel?

			Geir Arne

		

	
	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: Raphael Coeffic <[email-masked]>
Date: Wed, 28 Mar 2007 10:58:08 +0200

Dear Participant (Eric) ;-)

Please excuse me if i missed an important discussion, but i am quite not sure 
why the control protocol (framework) should be only to manipulate existing 
sessions. As you pointed out, it implies that the MS holds quite a lot of SIP 
sessions with different kind of participants. On the other side, the AS has 
to "monitor" the INVITEs coming from the user side before they get passed to 
the MS (including some query to the media broker to select the right MS).

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.

Regards
Raphael.

On Tuesday 27 March 2007 17:53, Eric Burger wrote:
> conference control legs, due to a perceived performance improvement from
> not having so many SIP dialogs.  For example, some folks have applications
> which are essentially all enhanced 3-party conferences (remember, simple
> conferences get taken care of quite nicely by RFC 4042).  If you had a
> 6,000 port media server, you could have 2,000 3-party conferences, but you
> would also have 8,000 SIP dialogs (6,000 for each leg and 2,000 for each
> control channel per conference).
>
> 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.
>

-- 
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: Eric Burger <[email-masked]>
Date: Thu, 29 Mar 2007 08:45:01 -0400

Comments in line.

> establishment of control sessions.

Correct.

> And for each end-point requiring media services there is a new SIP Dialog

Correct; the AS is a B2BUA between the endpoint and MS.

> So, actually each *User Agent* will do media negotiation with the MS using

Absolutely.  That is why we use SIP.

If we did the negotiation in the control channel, then we have to replicate
half the SIP state machine in the endpoint-facing direction and the other
half in the MS-facing direction.  That means we have to burn lots of CPU
cycles and network packets totally unnecessarily, compared to simply
relaying / B2BUA-ing the endpoint-MS SIP interaction.

[chair hat on: make sure this point is in the framework document]

In 3GPP terms, this is why combining the AS and MRFC makes absolutely no
sense, unless one thinks of Mp being SIP.  However, that proposal (SIP for
Mp) was rejected and, as far as I know, will never be acceptable to 3GPP.
If you don't like that decision, bring your thoughts to 3GPP, not here.

>>> On 3/23/07, Geir Arne Sandbakken <[email-masked]>
>>> <mailto:[email-masked]>  wrote:
>>>     
>>>  
>>>>  
>>>> 
>>>> 
>>>> 
>> 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: Lorenzo Miniero <[email-masked]>
Date: Thu, 29 Mar 2007 14:55:37 +0200

Hi Eric,

<cut>

> relaying / B2BUA-ing the endpoint-MS SIP interaction.

Well, actually a bit of CPU cycles will be burnt by the AS anyway to 
gateway the CSP protocols, since while AS-MS interaction will be SIP, 
UA-AS interaction could be protocol agnostic.

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: Thu, 29 Mar 2007 09:00:29 -0400

Theory: true (AS has to do *something*)

Practice: false (copying a buffer is way less processing than parsing,
calculating, and reformatting)