Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 25 Feb 2008 13:44:56 -0500

Howdy,
I'm new to this mailing list, so I don't know if this has been discussed before (and search tools for IETF mailing lists are pathetic).  I've been told there was some discussion last year, but not what the final outcome was.

My question is does the WG want this mechanism to work across SBCs generally? (like for example across providers, between enterprises and providers, etc.)  Actually, even some generic B2BUA's would break it.
I guess the real question is does the WG purposefully want it to NOT work across them, or does it not care either way?

I know people have strong feelings on both sides, and I don't want to drudge up past mailing list discussion.

If this was already discussed and the consensus was the WG does not want it to work, then I have no issues with this draft.  I just couldn't figure it out from the mailing list archive. (maybe the draft should say so itself)

Otherwise the dialog-id thing needs to change.  [And really even from an architectural aspect I don't know why "media" should know anything about SIP dialog identifier information, but that's a personal view and orthogonal to the question.]

-hadriel

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

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 27 Feb 2008 11:08:39 -0000

Media Controllers,

After talking extensively with Hadriel off-line, I am in full agreement
with his suggestions for the Media Control Framework.  Just to be clear:

'We are not proposing to radically change the Framework to work with
SBC's'.

We are:

'Proposing a tweak to the current dialog association mechanism that will
help traversal of B2BUA devices that are in our networks today'.

It was clear at the time that the current mechanism was not ideal (I
certainly remember Christer and others raising good points) and that it
would be revisited - so here we are.

The proposed change is:

- We will continue to use the SYNCH message to correlate the underlying
control channel with the SIP dialog.
- Instead of using a concatenation of the SIP dialog identifiers - we
will use an SDP attribute with an appropriately random identifier.  This
in no way harms the current direction of the Framework and in fact
enhances its potential usage and adoption (with only a small change).

PLEASE COMMENT (support/not support) on the proposal and I'm sure
Hadriel will chime in if appropriate.  If we agree then I will roll the
change into the next version of the draft. 

Scott - if we decide to follow the recommendations this would raise the
question of should we align the 'connection-ID' construction in the
common XML.  I would suggest that we do for clarity and consistency (and
it would also now work across B2BUA type devices).

Chris.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
Sent: 25 February 2008 18:45
To: [email-masked]
Subject: Re: [MEDIACTRL]
draft-ietf-mediactrl-sip-control-framework-01.txt

Howdy,
I'm new to this mailing list, so I don't know if this has been discussed
before (and search tools for IETF mailing lists are pathetic).  I've
been told there was some discussion last year, but not what the final
outcome was.

My question is does the WG want this mechanism to work across SBCs
generally? (like for example across providers, between enterprises and
providers, etc.)  Actually, even some generic B2BUA's would break it.
I guess the real question is does the WG purposefully want it to NOT
work across them, or does it not care either way?

I know people have strong feelings on both sides, and I don't want to
drudge up past mailing list discussion.

If this was already discussed and the consensus was the WG does not want
it to work, then I have no issues with this draft.  I just couldn't
figure it out from the mailing list archive. (maybe the draft should say
so itself)

Otherwise the dialog-id thing needs to change.  [And really even from an
architectural aspect I don't know why "media" should know anything about
SIP dialog identifier information, but that's a personal view and
orthogonal to the question.]

-hadriel

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

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 28 Feb 2008 11:25:35 +0200

Chris,
So if we are going this way I will raise again the issue of the
connection establishment order. In the case you describe the AS defines
the association token not based on the SIP dialog.

This means that the AS can first add the user to a conference using the
JOIN command and afterwards when the MS receives the SIP call it will
see in the SDP the same token and will be ready to process the SIP
INVITE.

Another outcome is that the AS will need to add this attribute to the
SDP that will come from the endpoint.

Roni

> Behalf Of Chris Boulton
> Sent: Wednesday, February 27, 2008 1:09 PM
> To: Hadriel Kaplan; [email-masked]
> Subject: Re: [MEDIACTRL]

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 28 Feb 2008 09:49:45 -0000

Chris,

[Chris Boulton] Correct.  The only difference is the semantic sugar that
makes up the identifier.  It appears at the MS at the same time only in
SDP rather than being constructed by the concatenation of the dialog
identifiers. 

[Chris Boulton] this situation could happen BUT I don't see that as a
by-product of changing how we construct the identifier - do you agree?
It seems to me a matter of policy if an MS allows a dialog to be added.

[Chris Boulton] Correct.  So are you against this change?

Roni

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 28 Feb 2008 11:55:57 +0200

Chris,
I am for this change mostly because I would also like to see the option
to use JOIN before sending the SIP INVITE to the MS. I would like to see
it mentioned in the flows in the document
Roni

> From: Chris Boulton [mailto:[email-masked]]
> Sent: Thursday, February 28, 2008 11:50 AM
> To: Even, Roni; Hadriel Kaplan; [email-masked]
> Subject: RE: [MEDIACTRL]
> > Otherwise the dialog-id thing needs to change.  [And really even
from
> an

---

From: "McGlashan, Scott" <[email-masked]>
Date: Thu, 28 Feb 2008 10:57:46 +0000

On the connectionid in the common XML, I agree we should align the contents of the attribute (assuming no change in the attribute name itself).

And I fully support the proposal.

Thanks

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton
Sent: Wednesday, February 27, 2008 12:09
To: Hadriel Kaplan; [email-masked]
Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt

Media Controllers,

After talking extensively with Hadriel off-line, I am in full agreement with his suggestions for the Media Control Framework.  Just to be clear:

'We are not proposing to radically change the Framework to work with SBC's'.

We are:

'Proposing a tweak to the current dialog association mechanism that will help traversal of B2BUA devices that are in our networks today'.

It was clear at the time that the current mechanism was not ideal (I certainly remember Christer and others raising good points) and that it would be revisited - so here we are.

The proposed change is:

- We will continue to use the SYNCH message to correlate the underlying control channel with the SIP dialog.
- Instead of using a concatenation of the SIP dialog identifiers - we will use an SDP attribute with an appropriately random identifier.  This in no way harms the current direction of the Framework and in fact enhances its potential usage and adoption (with only a small change).

PLEASE COMMENT (support/not support) on the proposal and I'm sure Hadriel will chime in if appropriate.  If we agree then I will roll the change into the next version of the draft.

Scott - if we decide to follow the recommendations this would raise the question of should we align the 'connection-ID' construction in the common XML.  I would suggest that we do for clarity and consistency (and it would also now work across B2BUA type devices).

Chris.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: 25 February 2008 18:45
To: [email-masked]
Subject: Re: [MEDIACTRL]

Howdy,

-hadriel

---

From: "McGlashan, Scott" <[email-masked]>
Date: Thu, 28 Feb 2008 11:35:22 +0000

Hi Roni,

Just thinking through the scenario you describe in terms of framework and conference control package.

(a) The MS would receive a <join id1="connectionid1" id2="conferenceid1"> in a CONTROL framework message from the AS. At this point, there would be a conference but no SIP connection actually connected to the MS.

(b) The MS would wait until the connection is available (in which case it tries to carry out the join operation and reports success/failure), or waits until some 'waiting for connection' timeout expires. In both cases, it may extend the framework transaction as normal.

If this is a correct description of the scenario (please correct me if I'm wrong), then I have a few questions

1. Should the MS behavior of 'waiting for a connection to connect' be manadatory for an MS supporting conference package? I would think yes, but I only see it applying to the <join> operation (<modifyjoin> and <unjoin> would require the connection to be present).

2. The timeout for the MS to wait for a connection: if this is something the package should define, any ideas on a reasonable value? Or is it entirely a local policy matter for the MS?

3. Does this scenario also apply to the IVR package where a <dialogstart connectionid="con1" ...>  CONTROL message could be sent before the con1 is connected? i.e. the AS orders the dialog to start before the connection is connected? I would think it does.

4. Does the framework doc need to be modified? I can certainly see the packages being modified for specific commands, but I can't quite see what we would modify in the framework document.

Thanks

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Even, Roni
Sent: Thursday, February 28, 2008 10:56
To: Chris Boulton; Hadriel Kaplan; [email-masked]
Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt

Chris,
I am for this change mostly because I would also like to see the option to use JOIN before sending the SIP INVITE to the MS. I would like to see it mentioned in the flows in the document Roni

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 28 Feb 2008 14:20:21 +0200

Scott,
Inline
Roni

> From: McGlashan, Scott [mailto:[email-masked]]
> Sent: Thursday, February 28, 2008 1:35 PM
> To: Even, Roni; [email-masked]
> Subject: RE: [MEDIACTRL]
> 
> Hi Roni,
> 
> Just thinking through the scenario you describe in terms of framework
and
> conference control package.
> 
> (a) The MS would receive a <join id1="connectionid1"
id2="conferenceid1">
> in a CONTROL framework message from the AS. At this point, there would
be
> a conference but no SIP connection actually connected to the MS.
[RE:] The conference on the MS was created before, now it will know that
connectionid1 is going to join the conference
> 
> (b) The MS would wait until the connection is available (in which case
it
> tries to carry out the join operation and reports success/failure), or
> waits until some 'waiting for connection' timeout expires. In both
cases,
> it may extend the framework transaction as normal.
[RE:] Yes, but it may report that failure like no resources, for example
if the MS runs out of mixing resources.
> 
> 
> If this is a correct description of the scenario (please correct me if
I'm
> wrong), then I have a few questions
> 
> 1. Should the MS behavior of 'waiting for a connection to connect' be
> manadatory for an MS supporting conference package? I would think yes,
but
> I only see it applying to the <join> operation (<modifyjoin> and
<unjoin>
> would require the connection to be present).
[RE:] Yes
> 
> 2. The timeout for the MS to wait for a connection: if this is
something
> the package should define, any ideas on a reasonable value? Or is it
> entirely a local policy matter for the MS?
[RE:] The value is local policy. BTW: we did not define timeout for
other operations, example is conference create, how long do you keep the
defined conference if no JOIN or no Destroy or all parties un-joined
> 
> 3. Does this scenario also apply to the IVR package where a
<dialogstart
> connectionid="con1" ...>  CONTROL message could be sent before the
con1 is
> connected? i.e. the AS orders the dialog to start before the
connection is
> connected? I would think it does.
[RE:] Make sense, this way the MS can start the right prompt when the
media channel is available from the SIP invite
> 
> 4. Does the framework doc need to be modified? I can certainly see the
> packages being modified for specific commands, but I can't quite see
what
> we would modify in the framework document.
[RE:] In the framework it is the flow examples
> Behalf Of Even, Roni
> 
> Chris,
> I am for this change mostly because I would also like to see the
option to
> use JOIN before sending the SIP INVITE to the MS. I would like to see
it
> mentioned in the flows in the document Roni

---

From: "McGlashan, Scott" <[email-masked]>
Date: Thu, 28 Feb 2008 12:37:28 +0000

Thanks Roni.

I'll update the IVR package to indicate that an MS MUST support a <dialogstart> being received before the connection is connected to the MS, but the time to wait for the connection is a matter of local MS policy. Similar updates to be applied in the next version of conference package for <join>.

Following on from our previous discussion about the maximum time a dialog can remain prepared (and the maximum duration of a dialog once it is started), we could state these timeouts are also a matter of local MS policy - the MS must apply a timeout, but its value is not defined by the package. Do you agree?

Scott

-----Original Message-----
From: Even, Roni [mailto:[email-masked]]
Sent: Thursday, February 28, 2008 13:20
To: McGlashan, Scott; [email-masked]
Subject: RE: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt

Scott,
Inline
Roni

and
id2="conferenceid1">
be
it
cases,
> it may extend the framework transaction as normal.
[RE:] Yes, but it may report that failure like no resources, for example if the MS runs out of mixing resources.
I'm
but
<unjoin>
[RE:] Yes
something
> entirely a local policy matter for the MS?
[RE:] The value is local policy. BTW: we did not define timeout for other operations, example is conference create, how long do you keep the defined conference if no JOIN or no Destroy or all parties un-joined
<dialogstart
con1 is
connection is
> connected? I would think it does.
[RE:] Make sense, this way the MS can start the right prompt when the media channel is available from the SIP invite
what
option to
it

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 28 Feb 2008 14:40:50 +0200

Scott,
I think that maybe the TO should be notified to the AS enabling him to
take corrective action.
Roni

> Sent: Thursday, February 28, 2008 2:37 PM
> 
> Thanks Roni.
> 
> I'll update the IVR package to indicate that an MS MUST support a
> <dialogstart> being received before the connection is connected to the
MS,
> but the time to wait for the connection is a matter of local MS
policy.
> Similar updates to be applied in the next version of conference
package
> for <join>.
> 
> Following on from our previous discussion about the maximum time a
dialog
> can remain prepared (and the maximum duration of a dialog once it is
> started), we could state these timeouts are also a matter of local MS
> policy - the MS must apply a timeout, but its value is not defined by
the
> package. Do you agree?
> [RE:] The value is local policy. BTW: we did not define timeout for
other
> operations, example is conference create, how long do you keep the
defined
> conference if no JOIN or no Destroy or all parties un-joined
> >

---

From: "McGlashan, Scott" <[email-masked]>
Date: Thu, 28 Feb 2008 12:45:28 +0000

Good point. I'll add mandatory reporting of TOs for both cases.

Scott

-----Original Message-----
From: Even, Roni [mailto:[email-masked]]
Sent: Thursday, February 28, 2008 13:41
To: McGlashan, Scott; [email-masked]
Subject: RE: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt

Scott,
I think that maybe the TO should be notified to the AS enabling him to take corrective action.
Roni

MS,
policy.
package
dialog
the
other
defined

---

From: [email-masked]
Date: Thu, 28 Feb 2008 15:05:50 +0100

Roni, Scott,

I fail to understand the use case, or even the need, for such a  
feature. What's the point in attaching a user to something, be it a  
dialog or a conference, before the user has been added to the MS by  
completing its negotiation with the MS? n different things may happen  
causing the negotiation to fail or to be different from what the AS  
and the UAC might expect it to be (e.g. the MS accepting only a subset  
of the media the UAC proposed, or refusing them all for some reason).  
Besides, it may work if you want to attach a user session as a whole  
to something (the SDP attribute would take the place of the from~to  
tags concatenation, addressing all the media from the user), but would  
obviously fail if a finer granularity is needed (no media has been  
negotiated yet, which means no labels). Additionally, IMHO it would  
add other issues: how would you distinguish between a connectionid  
that is coming soon and a connectionid that has been miswritten or  
just doesn't exist?

What's wrong in manipulating through the control channel only what  
both the AS and the MS are aware of?

Lorenzo

Quoting "McGlashan, Scott" <[email-masked]>:

> <dialogstart> being received before the connection is connected to   
> the MS, but the time to wait for the connection is a matter of local  
>  MS policy. Similar updates to be applied in the next version of   
> conference package for <join>.
>
> dialog can remain prepared (and the maximum duration of a dialog   
> once it is started), we could state these timeouts are also a matter  
>  of local MS policy - the MS must apply a timeout, but its value is   
> not defined by the package. Do you agree?
>
> Scott
>
>
>
>
> [RE:] Yes, but it may report that failure like no resources, for   
> example if the MS runs out of mixing resources.
>>
>>
> other operations, example is conference create, how long do you keep  
>  the defined conference if no JOIN or no Destroy or all parties   
> un-joined
>>
> [RE:] Make sense, this way the MS can start the right prompt when   
> the media channel is available from the SIP invite
>>

-- 
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]
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 28 Feb 2008 16:12:10 +0200

Lorenzo,
In my view the MS does not know what to do with the connection or how to negotiate mode with it since it does not know to where this user belongs before the JOIN arrives.
The MS does not know what to send the user when it connects so if the user gets the 200 it mat hear silence, no picture. Having him connected still does not guarantee that he will be able to JOIN. Example is the case when the MS supports video and audio conferences. He may have audio resources but not video but until the MS knows the conference it cannot tell.
Roni 

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, February 28, 2008 4:06 PM
> To: McGlashan, Scott
> Cc: Even, Roni; [email-masked]

---

From: "Steve Buko" <[email-masked]>
Date: Thu, 28 Feb 2008 09:20:18 -0500

Roni,

Although I don't totally agree with this change, I WAS understanding the reasoning somewhat.
That is, until your last comment.  

Are you saying that the MS will use the information in the JOIN to negotiate the media with the endpoint when the call arrives.
This doesn't make sense to me.  

The media negotation should be independent of what media operations is currently "queued up" to be performed on the endpoint.

Steve

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
|Behalf Of Even, Roni
|Sent: Thursday, February 28, 2008 9:12 AM
|To: [email-masked]; McGlashan, Scott
|Cc: [email-masked]
|Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt
|
|Lorenzo,
|In my view the MS does not know what to do with the connection or how to
|negotiate mode with it since it does not know to where this user belongs
|before the JOIN arrives.
|The MS does not know what to send the user when it connects so if the user
|gets the 200 it mat hear silence, no picture. Having him connected still
|does not guarantee that he will be able to JOIN. Example is the case when
|the MS supports video and audio conferences. He may have audio resources
|but not video but until the MS knows the conference it cannot tell.
|Roni
|
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]]
|> Sent: Thursday, February 28, 2008 4:06 PM
|> To: McGlashan, Scott
|> Cc: Even, Roni; [email-masked]
|> Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-
|01.txt
|>
|> Roni, Scott,
|>
|> I fail to understand the use case, or even the need, for such a
|> feature. What's the point in attaching a user to something, be it a
|> dialog or a conference, before the user has been added to the MS by
|> completing its negotiation with the MS? n different things may happen
|> causing the negotiation to fail or to be different from what the AS
|> and the UAC might expect it to be (e.g. the MS accepting only a subset
|> of the media the UAC proposed, or refusing them all for some reason).
|> Besides, it may work if you want to attach a user session as a whole
|> to something (the SDP attribute would take the place of the from~to
|> tags concatenation, addressing all the media from the user), but would
|> obviously fail if a finer granularity is needed (no media has been
|> negotiated yet, which means no labels). Additionally, IMHO it would
|> add other issues: how would you distinguish between a connectionid
|> that is coming soon and a connectionid that has been miswritten or
|> just doesn't exist?
|>
|> What's wrong in manipulating through the control channel only what
|> both the AS and the MS are aware of?
|>
|> Lorenzo
|>
|>
|> Quoting "McGlashan, Scott" <[email-masked]>:
|>
|> > Thanks Roni.
|> >
|> > I'll update the IVR package to indicate that an MS MUST support a
|> > <dialogstart> being received before the connection is connected to
|> > the MS, but the time to wait for the connection is a matter of local
|> >  MS policy. Similar updates to be applied in the next version of
|> > conference package for <join>.
|> >
|> > Following on from our previous discussion about the maximum time a
|> > dialog can remain prepared (and the maximum duration of a dialog
|> > once it is started), we could state these timeouts are also a matter
|> >  of local MS policy - the MS must apply a timeout, but its value is
|> > not defined by the package. Do you agree?
|> >
|> > Scott
|> >
|> >
|> >
|> >
|> > -----Original Message-----
|> > From: Even, Roni [mailto:[email-masked]]
|> > Sent: Thursday, February 28, 2008 13:20
|> > To: McGlashan, Scott; [email-masked]
|> > Subject: RE: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-
|> 01.txt
|> >
|> > Scott,
|> > Inline
|> > Roni
|> >
|> >> -----Original Message-----
|> >> From: McGlashan, Scott [mailto:[email-masked]]
|> >> Sent: Thursday, February 28, 2008 1:35 PM
|> >> To: Even, Roni; [email-masked]
|> >> Subject: RE: [MEDIACTRL]
|> > draft-ietf-mediactrl-sip-control-framework-01.txt
|> >>
|> >> Hi Roni,
|> >>
|> >> Just thinking through the scenario you describe in terms of framework
|> > and
|> >> conference control package.
|> >>
|> >> (a) The MS would receive a <join id1="connectionid1"
|> > id2="conferenceid1">
|> >> in a CONTROL framework message from the AS. At this point, there would
|> > be
|> >> a conference but no SIP connection actually connected to the MS.
|> > [RE:] The conference on the MS was created before, now it will know
|that
|> > connectionid1 is going to join the conference
|> >>
|> >> (b) The MS would wait until the connection is available (in which case
|> > it
|> >> tries to carry out the join operation and reports success/failure), or
|> >> waits until some 'waiting for connection' timeout expires. In both
|> > cases,
|> >> it may extend the framework transaction as normal.
|> > [RE:] Yes, but it may report that failure like no resources, for
|> > example if the MS runs out of mixing resources.
|> >>
|> >>
|> >> If this is a correct description of the scenario (please correct me if
|> > I'm
|> >> wrong), then I have a few questions
|> >>
|> >> 1. Should the MS behavior of 'waiting for a connection to connect' be
|> >> manadatory for an MS supporting conference package? I would think yes,
|> > but
|> >> I only see it applying to the <join> operation (<modifyjoin> and
|> > <unjoin>
|> >> would require the connection to be present).
|> > [RE:] Yes
|> >>
|> >> 2. The timeout for the MS to wait for a connection: if this is
|> > something
|> >> the package should define, any ideas on a reasonable value? Or is it
|> >> entirely a local policy matter for the MS?
|> > [RE:] The value is local policy. BTW: we did not define timeout for
|> > other operations, example is conference create, how long do you keep
|> >  the defined conference if no JOIN or no Destroy or all parties
|> > un-joined
|> >>
|> >> 3. Does this scenario also apply to the IVR package where a
|> > <dialogstart
|> >> connectionid="con1" ...>  CONTROL message could be sent before the
|> > con1 is
|> >> connected? i.e. the AS orders the dialog to start before the
|> > connection is
|> >> connected? I would think it does.
|> > [RE:] Make sense, this way the MS can start the right prompt when
|> > the media channel is available from the SIP invite
|> >>
|> >> 4. Does the framework doc need to be modified? I can certainly see the
|> >> packages being modified for specific commands, but I can't quite see
|> > what
|> >> we would modify in the framework document.
|> > [RE:] In the framework it is the flow examples
|> >>
|> >> Thanks
|> >>
|> >> Scott
|> >>
|> >>
|> >>
|> >>
|> >> -----Original Message-----
|> >> From: [email-masked] [mailto:[email-masked]]
|> > On
|> >> Behalf Of Even, Roni
|> >> Sent: Thursday, February 28, 2008 10:56
|> >> To: Chris Boulton; Hadriel Kaplan; [email-masked]
|> >> Subject: Re: [MEDIACTRL]
|> > draft-ietf-mediactrl-sip-control-framework-01.txt
|> >>
|> >> Chris,
|> >> I am for this change mostly because I would also like to see the
|> > option to
|> >> use JOIN before sending the SIP INVITE to the MS. I would like to see
|> > it
|> >> mentioned in the flows in the document Roni
|> >
|> > _______________________________________________
|> > MEDIACTRL mailing list
|> > [email-masked]
|> > https://www.ietf.org/mailman/listinfo/mediactrl
|> > Supplemental Web Site:
|> > http://www.standardstrack.com/ietf/mediactrl
|> >
|>
|>
|>
|> --
|> 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]
|_______________________________________________
|MEDIACTRL mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/mediactrl
|Supplemental Web Site:
|http://www.standardstrack.com/ietf/mediactrl
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 28 Feb 2008 16:43:45 +0200

Steve,

Let's take an example of an MS that support audio conferencing, video conferencing, audio IVR and video IVR. 
Now an Invite comes to the MS, what should the MS respond with, should it send 200 or reject the call.

What should the MS respond in the SDP for the 200 if it does not know the target. (maybe it cannot accept all codecs to this specific conference, should the AS know all the capabilities of all the MS that it use?)
 
After sending the 200 or even before the MS can start sending media to the caller (it has its SDP) but what should it send. This is a user experience issue since the assumption is that once the remote side gets a 200 it expects to hear and see the other side.

Roni

> From: Steve Buko [mailto:[email-masked]]
> Sent: Thursday, February 28, 2008 4:20 PM
> To: Even, Roni; [email-masked]; McGlashan, Scott
> Cc: [email-masked]
> Are you saying that the MS will use the information in the JOIN to
> negotiate the media with the endpoint when the call arrives.
> The media negotation should be independent of what media operations is
> currently "queued up" to be performed on the endpoint.
> 
> Steve
> 
> 
> 
>

---

From: "Steve Buko" <[email-masked]>
Date: Thu, 28 Feb 2008 09:53:43 -0500

Roni,

For the inbound call, the MS should respond with a 200OK containing an SDP that reflects the media/coders that the MS supports.
It cannot simply rely on a queued request (to put the party in a conference for example) to negotiate the media.  That queued request is a single request.  Other requests can be received during the lifetime of the call.  And those subsequent requests might require additional media resources.
If the AS wants to limit the coders used, it can modify the SDP prior to sending it to the MS.  The AS contains the business logic.  The MS is simply performing the media manipulation instructions that it is given.

Following your idea, take this example.
Suppose the MS received a prior request to put a party in an audio only conference.
Then when the party arrives, the MS would negotiate an audio only call (because of the prior request).
What happens later when the AS wants to move to party to a video conference or simply play a video?

In my opinion, media control requests are totally independent of media negotiation.  The AS can control media negotiation if it chooses to by manipulating the SDP.  

Steve

|-----Original Message-----
|From: Even, Roni [mailto:[email-masked]]
|Sent: Thursday, February 28, 2008 9:44 AM
|To: Steve Buko; [email-masked]; McGlashan, Scott
|Cc: [email-masked]
|Subject: RE: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt
|
|Steve,
|
|Let's take an example of an MS that support audio conferencing, video
|conferencing, audio IVR and video IVR.
|Now an Invite comes to the MS, what should the MS respond with, should it
|send 200 or reject the call.
|
|What should the MS respond in the SDP for the 200 if it does not know the
|target. (maybe it cannot accept all codecs to this specific conference,
|should the AS know all the capabilities of all the MS that it use?)
|
|After sending the 200 or even before the MS can start sending media to the
|caller (it has its SDP) but what should it send. This is a user experience
|issue since the assumption is that once the remote side gets a 200 it
|expects to hear and see the other side.
|
|
|Roni
|
|
|> -----Original Message-----
|> From: Steve Buko [mailto:[email-masked]]
|> Sent: Thursday, February 28, 2008 4:20 PM
|> To: Even, Roni; [email-masked]; McGlashan, Scott
|> Cc: [email-masked]
|> Subject: RE: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-
|01.txt
|>
|> Roni,
|>
|> Although I don't totally agree with this change, I WAS understanding the
|> reasoning somewhat.
|> That is, until your last comment.
|>
|> Are you saying that the MS will use the information in the JOIN to
|> negotiate the media with the endpoint when the call arrives.
|> This doesn't make sense to me.
|>
|> The media negotation should be independent of what media operations is
|> currently "queued up" to be performed on the endpoint.
|>
|> Steve
|>
|>
|>
|>
|> |-----Original Message-----
|> |From: [email-masked] [mailto:[email-masked]] On
|> |Behalf Of Even, Roni
|> |Sent: Thursday, February 28, 2008 9:12 AM
|> |To: [email-masked]; McGlashan, Scott
|> |Cc: [email-masked]
|> |Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-
|> 01.txt
|> |
|> |Lorenzo,
|> |In my view the MS does not know what to do with the connection or how to
|> |negotiate mode with it since it does not know to where this user belongs
|> |before the JOIN arrives.
|> |The MS does not know what to send the user when it connects so if the
|> user
|> |gets the 200 it mat hear silence, no picture. Having him connected still
|> |does not guarantee that he will be able to JOIN. Example is the case
|when
|> |the MS supports video and audio conferences. He may have audio resources
|> |but not video but until the MS knows the conference it cannot tell.
|> |Roni
|> |
|> |> -----Original Message-----
|> |> From: [email-masked] [mailto:[email-masked]]
|> |> Sent: Thursday, February 28, 2008 4:06 PM
|> |> To: McGlashan, Scott
|> |> Cc: Even, Roni; [email-masked]
|> |> Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-
|> |01.txt
|> |>
|> |> Roni, Scott,
|> |>
|> |> I fail to understand the use case, or even the need, for such a
|> |> feature. What's the point in attaching a user to something, be it a
|> |> dialog or a conference, before the user has been added to the MS by
|> |> completing its negotiation with the MS? n different things may happen
|> |> causing the negotiation to fail or to be different from what the AS
|> |> and the UAC might expect it to be (e.g. the MS accepting only a subset
|> |> of the media the UAC proposed, or refusing them all for some reason).
|> |> Besides, it may work if you want to attach a user session as a whole
|> |> to something (the SDP attribute would take the place of the from~to
|> |> tags concatenation, addressing all the media from the user), but would
|> |> obviously fail if a finer granularity is needed (no media has been
|> |> negotiated yet, which means no labels). Additionally, IMHO it would
|> |> add other issues: how would you distinguish between a connectionid
|> |> that is coming soon and a connectionid that has been miswritten or
|> |> just doesn't exist?
|> |>
|> |> What's wrong in manipulating through the control channel only what
|> |> both the AS and the MS are aware of?
|> |>
|> |> Lorenzo
|> |>
|> |>
|> |> Quoting "McGlashan, Scott" <[email-masked]>:
|> |>
|> |> > Thanks Roni.
|> |> >
|> |> > I'll update the IVR package to indicate that an MS MUST support a
|> |> > <dialogstart> being received before the connection is connected to
|> |> > the MS, but the time to wait for the connection is a matter of local
|> |> >  MS policy. Similar updates to be applied in the next version of
|> |> > conference package for <join>.
|> |> >
|> |> > Following on from our previous discussion about the maximum time a
|> |> > dialog can remain prepared (and the maximum duration of a dialog
|> |> > once it is started), we could state these timeouts are also a matter
|> |> >  of local MS policy - the MS must apply a timeout, but its value is
|> |> > not defined by the package. Do you agree?
|> |> >
|> |> > Scott
|> |> >
|> |> >
|> |> >
|> |> >
|> |> > -----Original Message-----
|> |> > From: Even, Roni [mailto:[email-masked]]
|> |> > Sent: Thursday, February 28, 2008 13:20
|> |> > To: McGlashan, Scott; [email-masked]
|> |> > Subject: RE: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-
|> |> 01.txt
|> |> >
|> |> > Scott,
|> |> > Inline
|> |> > Roni
|> |> >
|> |> >> -----Original Message-----
|> |> >> From: McGlashan, Scott [mailto:[email-masked]]
|> |> >> Sent: Thursday, February 28, 2008 1:35 PM
|> |> >> To: Even, Roni; [email-masked]
|> |> >> Subject: RE: [MEDIACTRL]
|> |> > draft-ietf-mediactrl-sip-control-framework-01.txt
|> |> >>
|> |> >> Hi Roni,
|> |> >>
|> |> >> Just thinking through the scenario you describe in terms of
|> framework
|> |> > and
|> |> >> conference control package.
|> |> >>
|> |> >> (a) The MS would receive a <join id1="connectionid1"
|> |> > id2="conferenceid1">
|> |> >> in a CONTROL framework message from the AS. At this point, there
|> would
|> |> > be
|> |> >> a conference but no SIP connection actually connected to the MS.
|> |> > [RE:] The conference on the MS was created before, now it will know
|> |that
|> |> > connectionid1 is going to join the conference
|> |> >>
|> |> >> (b) The MS would wait until the connection is available (in which
|> case
|> |> > it
|> |> >> tries to carry out the join operation and reports success/failure),
|> or
|> |> >> waits until some 'waiting for connection' timeout expires. In both
|> |> > cases,
|> |> >> it may extend the framework transaction as normal.
|> |> > [RE:] Yes, but it may report that failure like no resources, for
|> |> > example if the MS runs out of mixing resources.
|> |> >>
|> |> >>
|> |> >> If this is a correct description of the scenario (please correct me
|> if
|> |> > I'm
|> |> >> wrong), then I have a few questions
|> |> >>
|> |> >> 1. Should the MS behavior of 'waiting for a connection to connect'
|> be
|> |> >> manadatory for an MS supporting conference package? I would think
|> yes,
|> |> > but
|> |> >> I only see it applying to the <join> operation (<modifyjoin> and
|> |> > <unjoin>
|> |> >> would require the connection to be present).
|> |> > [RE:] Yes
|> |> >>
|> |> >> 2. The timeout for the MS to wait for a connection: if this is
|> |> > something
|> |> >> the package should define, any ideas on a reasonable value? Or is
|it
|> |> >> entirely a local policy matter for the MS?
|> |> > [RE:] The value is local policy. BTW: we did not define timeout for
|> |> > other operations, example is conference create, how long do you keep
|> |> >  the defined conference if no JOIN or no Destroy or all parties
|> |> > un-joined
|> |> >>
|> |> >> 3. Does this scenario also apply to the IVR package where a
|> |> > <dialogstart
|> |> >> connectionid="con1" ...>  CONTROL message could be sent before the
|> |> > con1 is
|> |> >> connected? i.e. the AS orders the dialog to start before the
|> |> > connection is
|> |> >> connected? I would think it does.
|> |> > [RE:] Make sense, this way the MS can start the right prompt when
|> |> > the media channel is available from the SIP invite
|> |> >>
|> |> >> 4. Does the framework doc need to be modified? I can certainly see
|> the
|> |> >> packages being modified for specific commands, but I can't quite
|see
|> |> > what
|> |> >> we would modify in the framework document.
|> |> > [RE:] In the framework it is the flow examples
|> |> >>
|> |> >> Thanks
|> |> >>
|> |> >> Scott
|> |> >>
|> |> >>
|> |> >>
|> |> >>
|> |> >> -----Original Message-----
|> |> >> From: [email-masked] [mailto:mediactrl-
[email-masked]]
|> |> > On
|> |> >> Behalf Of Even, Roni
|> |> >> Sent: Thursday, February 28, 2008 10:56
|> |> >> To: Chris Boulton; Hadriel Kaplan; [email-masked]
|> |> >> Subject: Re: [MEDIACTRL]
|> |> > draft-ietf-mediactrl-sip-control-framework-01.txt
|> |> >>
|> |> >> Chris,
|> |> >> I am for this change mostly because I would also like to see the
|> |> > option to
|> |> >> use JOIN before sending the SIP INVITE to the MS. I would like to
|> see
|> |> > it
|> |> >> mentioned in the flows in the document Roni
|> |> >
|> |> > _______________________________________________
|> |> > MEDIACTRL mailing list
|> |> > [email-masked]
|> |> > https://www.ietf.org/mailman/listinfo/mediactrl
|> |> > Supplemental Web Site:
|> |> > http://www.standardstrack.com/ietf/mediactrl
|> |> >
|> |>
|> |>
|> |>
|> |> --
|> |> 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]
|> |_______________________________________________
|> |MEDIACTRL mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/mediactrl
|> |Supplemental Web Site:
|> |http://www.standardstrack.com/ietf/mediactrl
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 28 Feb 2008 17:00:39 +0200

Scott

Sending all the supported media is meaningless since it may require a RE-invite when the conference target is known (this will be the case for the video for voice activated video switch when the MS cannot transcode video but need to set a common mode)

"Following your idea, take this example.
Suppose the MS received a prior request to put a party in an audio only conference.
Then when the party arrives, the MS would negotiate an audio only call (because of the prior request).
What happens later when the AS wants to move to party to a video conference or simply play a video?"

The AS need to unjoin him from the audio conference, join him to the new conference and send a re-invite. 

Roni

---

From: [email-masked]
Date: Thu, 28 Feb 2008 15:59:29 +0100

Roni,

actually, the MS sends its 200 to the AS and not directly to the  
remote side, since it's a 3PCC. This means that, before the AS relays  
the 200 to the UAC, the AS may do something else on the control  
channel to manipulate the new (and negotiated) connection and achieve  
the desired scenario. Or it may do it right after relaying the 200 to  
the UAC. In both cases, I think the issue could be solved in the  
application logic. Same for the limited set of allowed codecs for a  
conference: the AS might filter the UAC SDP before forwarding it to  
the MS, according to its policies or implementation choices.

I just think the MS should always negotiate all it can according to an  
incoming INVITE: if a break is needed, it's up to the AS. Just my two  
cents of course.

Lorenzo

Quoting "Even, Roni" <[email-masked]>:

> Steve,
>
> Let's take an example of an MS that support audio conferencing,   
> video conferencing, audio IVR and video IVR.
> What should the MS respond in the SDP for the 200 if it does not   
> know the target. (maybe it cannot accept all codecs to this specific  
>  conference, should the AS know all the capabilities of all the MS   
> that it use?)
>
> After sending the 200 or even before the MS can start sending media   
> to the caller (it has its SDP) but what should it send. This is a   
> user experience issue since the assumption is that once the remote   
> side gets a 200 it expects to hear and see the other side.
>
>
> Roni
>
>

---

From: "Steve Buko" <[email-masked]>
Date: Thu, 28 Feb 2008 10:48:57 -0500

Well actually you don't send all the supported media.  You send what was negotiated using what was "offered" as a priority list.
The AS controls the "offered" list and it's priority.
And it's far from meaningless IMO. :)

Regarding the "common mode" for a video conference when transcoding is not supported, this would be up to the AS to make sure it modified the SDP properly.  The AS has the business logic.

Again, the MS should not be using a single inbound media control request to negotiate the media for the call.  The AS owns the SDP and what should be negotiated.

Forcing the AS to send re-INVITE requests every time it wants to perform a different type of media operation is not desired or required.

|From: Even, Roni [mailto:[email-masked]]
|Sent: Thursday, February 28, 2008 10:01 AM
|To: Steve Buko; [email-masked]; McGlashan, Scott
|Cc: [email-masked]
|Subject: RE: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt
|
|Scott
|
|Sending all the supported media is meaningless since it may require a RE-
|invite when the conference target is known (this will be the case for the
|video for voice activated video switch when the MS cannot transcode video
|but need to set a common mode)
|
|
|
|"Following your idea, take this example.
|Suppose the MS received a prior request to put a party in an audio only
|conference.
|Then when the party arrives, the MS would negotiate an audio only call
|(because of the prior request).
|What happens later when the AS wants to move to party to a video conference
|or simply play a video?"
|
|
|The AS need to unjoin him from the audio conference, join him to the new
|conference and send a re-invite.
|
|Roni
|

---

From: "McGlashan, Scott" <[email-masked]>
Date: Thu, 28 Feb 2008 17:05:48 +0000

I agree - we want/need separation on the MS between the negotiated connection capabilities and any operation applied by the MS. It's the AS's job to make sure they match up.

The proposal to allow the MS to accept a join/dialogstart command when the connection is not already available seems reasonable to me for cases where there could be a slight timing difference between when the MS receives a join/start command and the connection being in a connected state. If the AS sends the command too late, you get a 'dead air' delay between call connection and media processing (such as an announcement) - not good for the end-user experience. And I don't think we want the AS repeatedly sending the command until it is accepted (unnecessary traffic and still the potential for a delay with RTT).

The specs are currently agnostic on this issue - they don't explicitly allow it or disallow it. So we could:

(a) Change nothing: it is an implementation issue.

(b) Explicitly state that an error is raised if a join/dialogstart command contains a connectionid which is not already connected.

(c) Clarify that an MS MAY implement dialogstart/join so that if a connection is not already available, execution of the operation may be queued for a short time prior to the connection being connected.

(d)  Clarify that an MS MUST implement dialogstart/join so that if a connection is not already available, execution of the operation is queued for a short time prior to the connection being connected.

Based on list discussion so far, there are some objections to (b) and (d). Could we agree on (a) or (c)?

I vote for (c) but would be ok with (a). I'm open to (b) if someone can explain how to avoid a 'dead air' delay.

Scott

-----Original Message-----
From: Steve Buko [mailto:[email-masked]]
Sent: Thursday, February 28, 2008 16:49
To: Even, Roni; [email-masked]; McGlashan, Scott
Cc: [email-masked]
Subject: RE: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt

|From: Even, Roni [mailto:[email-masked]]
|Sent: Thursday, February 28, 2008 10:01 AM
|To: Steve Buko; [email-masked]; McGlashan, Scott
|Cc: [email-masked]
|Subject: RE: [MEDIACTRL]
|draft-ietf-mediactrl-sip-control-framework-01.txt
|
|Scott
|
|Sending all the supported media is meaningless since it may require a
|RE- invite when the conference target is known (this will be the case
|for the video for voice activated video switch when the MS cannot
|transcode video but need to set a common mode)
|
|
|
|"Following your idea, take this example.
|Suppose the MS received a prior request to put a party in an audio only
|conference.
|Then when the party arrives, the MS would negotiate an audio only call
|(because of the prior request).
|What happens later when the AS wants to move to party to a video
|conference or simply play a video?"
|
|
|The AS need to unjoin him from the audio conference, join him to the
|new conference and send a re-invite.
|
|Roni
|

---

From: "Steve Buko" <[email-masked]>
Date: Thu, 28 Feb 2008 12:25:47 -0500

I personally prefer (b), but I'm OK with (c).

For (b) I think the dead air issue can be solved in most cases by the
AS. 
It can issue the media control commands prior to answering the call back
to the endpoint.

i.e.

UA               AS              MS
----- INVITE ---->
                 ----- INVITE ---->
                 <---- 200OK ------
                 --- MC Request -->
                 <-- MC Response --
<--- 200OK ------

Going with option (c) may eliminate the dead air issue, but won't it
create a converse issue of clipping.
In other words, we are saying that as soon as the MS receives the
INVITE, it should process the queued media control request.
In this case, the MS may be streaming media to an endpoint that is
hearing ringback because the AS hasn't responded to the UA with a 200OK
yet.
This may be acceptable for a conference.  Not so acceptable for a
greeting.

Steve

|-----Original Message-----
|From: McGlashan, Scott [mailto:[email-masked]]
|Sent: Thursday, February 28, 2008 12:06 PM
|To: Steve Buko; Even, Roni; [email-masked]
|Cc: [email-masked]
|Subject: RE: [MEDIACTRL]
draft-ietf-mediactrl-sip-control-framework-01.txt
|
|I agree - we want/need separation on the MS between the negotiated
|connection capabilities and any operation applied by the MS. It's the
AS's
|job to make sure they match up.
|
|The proposal to allow the MS to accept a join/dialogstart command when
the
|connection is not already available seems reasonable to me for cases
where
|there could be a slight timing difference between when the MS receives
a
|join/start command and the connection being in a connected state. If
the AS
|sends the command too late, you get a 'dead air' delay between call
|connection and media processing (such as an announcement) - not good
for
|the end-user experience. And I don't think we want the AS repeatedly
|sending the command until it is accepted (unnecessary traffic and still
the
|potential for a delay with RTT).
|
|The specs are currently agnostic on this issue - they don't explicitly
|allow it or disallow it. So we could:
|
|(a) Change nothing: it is an implementation issue.
|
|(b) Explicitly state that an error is raised if a join/dialogstart
command
|contains a connectionid which is not already connected.
|
|(c) Clarify that an MS MAY implement dialogstart/join so that if a
|connection is not already available, execution of the operation may be
|queued for a short time prior to the connection being connected.
|
|(d)  Clarify that an MS MUST implement dialogstart/join so that if a
|connection is not already available, execution of the operation is
queued
|for a short time prior to the connection being connected.
|
|Based on list discussion so far, there are some objections to (b) and
(d).
|Could we agree on (a) or (c)?
|
|I vote for (c) but would be ok with (a). I'm open to (b) if someone can
|explain how to avoid a 'dead air' delay.
|
|
|Scott
|
|
|-----Original Message-----
|From: Steve Buko [mailto:[email-masked]]
|Sent: Thursday, February 28, 2008 16:49
|To: Even, Roni; [email-masked]; McGlashan, Scott
|Cc: [email-masked]
|Subject: RE: [MEDIACTRL]
draft-ietf-mediactrl-sip-control-framework-01.txt
|
|Well actually you don't send all the supported media.  You send what
was
|negotiated using what was "offered" as a priority list.
|The AS controls the "offered" list and it's priority.
|And it's far from meaningless IMO. :)
|
|Regarding the "common mode" for a video conference when transcoding is
not
|supported, this would be up to the AS to make sure it modified the SDP
|properly.  The AS has the business logic.
|
|Again, the MS should not be using a single inbound media control
request to
|negotiate the media for the call.  The AS owns the SDP and what should
be
|negotiated.
|
|Forcing the AS to send re-INVITE requests every time it wants to
perform a
|different type of media operation is not desired or required.
|
|
|
|
|
||From: Even, Roni [mailto:[email-masked]]
||Sent: Thursday, February 28, 2008 10:01 AM
||To: Steve Buko; [email-masked]; McGlashan, Scott
||Cc: [email-masked]
||Subject: RE: [MEDIACTRL]
||draft-ietf-mediactrl-sip-control-framework-01.txt
||
||Scott
||
||Sending all the supported media is meaningless since it may require a
||RE- invite when the conference target is known (this will be the case
||for the video for voice activated video switch when the MS cannot
||transcode video but need to set a common mode)
||
||
||
||"Following your idea, take this example.
||Suppose the MS received a prior request to put a party in an audio
only
||conference.
||Then when the party arrives, the MS would negotiate an audio only call
||(because of the prior request).
||What happens later when the AS wants to move to party to a video
||conference or simply play a video?"
||
||
||The AS need to unjoin him from the audio conference, join him to the
||new conference and send a re-invite.
||
||Roni
||

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 28 Feb 2008 20:04:01 +0200

Steve,
The control request is not for negotiating the media for the call. It is to let the MS know what the target of the connection in the INVITE is.
I am not sure that the AS will want to handle the common mode of the conference and change it based on the highest common codec using re-invites to all parties. This is not business logic. The AS will tell the MS to do voice activated video switch and ask for information about the current speakers.
In the model you suggest the AS will know which codecs are supported by each MS and what it can do with each codec. 
Roni

> Sent: Thursday, February 28, 2008 5:49 PM
> Well actually you don't send all the supported media.  You send what was
> negotiated using what was "offered" as a priority list.
> Regarding the "common mode" for a video conference when transcoding is not
> supported, this would be up to the AS to make sure it modified the SDP
> properly.  The AS has the business logic.
> 
> Again, the MS should not be using a single inbound media control request
> to negotiate the media for the call.  The AS owns the SDP and what should
> be negotiated.
> 
> Forcing the AS to send re-INVITE requests every time it wants to perform a
> different type of media operation is not desired or required.
> 
> 
> 
> 
> 
> conference

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 28 Feb 2008 20:21:30 +0200

Hi,
I vote for option d. Option c does not mean much, you will need at least
to know if the MS supports this mode or not to allow the AS to select
which mode to work in.

I think that one question we need to ask is to which depth do we want
the AS to handle media changes and media control. 

BTW: the current data in the package means that the AS need to either
know all the information about the media capabilities of the MS (codecs,
mixing capabilities, resolutions, frame-rates,...) by provisioning(?) or
it should tell the MS do video and let the MS select the mode.
Roni

> Sent: Thursday, February 28, 2008 7:06 PM
> To: Steve Buko; Even, Roni; [email-masked]
> Cc: [email-masked]
> Subject: RE: [MEDIACTRL]
> 
> I agree - we want/need separation on the MS between the negotiated
> connection capabilities and any operation applied by the MS. It's the
AS's
> job to make sure they match up.
> 
> The proposal to allow the MS to accept a join/dialogstart command when
the
> connection is not already available seems reasonable to me for cases
where
> there could be a slight timing difference between when the MS receives
a
> join/start command and the connection being in a connected state. If
the
> AS sends the command too late, you get a 'dead air' delay between call
> connection and media processing (such as an announcement) - not good
for
> the end-user experience. And I don't think we want the AS repeatedly
> sending the command until it is accepted (unnecessary traffic and
still
> the potential for a delay with RTT).
> 
> (b) Explicitly state that an error is raised if a join/dialogstart
command
> contains a connectionid which is not already connected.
> 
> (c) Clarify that an MS MAY implement dialogstart/join so that if a
> connection is not already available, execution of the operation may be
> queued for a short time prior to the connection being connected.
> 
> (d)  Clarify that an MS MUST implement dialogstart/join so that if a
> connection is not already available, execution of the operation is
queued
> for a short time prior to the connection being connected.
> 
> Based on list discussion so far, there are some objections to (b) and
(d).
> Could we agree on (a) or (c)?
> 
> I vote for (c) but would be ok with (a). I'm open to (b) if someone
can
> explain how to avoid a 'dead air' delay.
> 
> 
> Scott
> 
>

---

From: [email-masked]
Date: Thu, 28 Feb 2008 20:22:20 +0100

I also am with (b), and agree with Steve about his sequence diagram. I  
proposed a similar approach in a mail I sent some hours ago in reply  
to a message of the discussion, but it looks like it never made it to  
the list... in the mail I also gave a reason why I'd prefer (b) over  
(c): the MS wouldn't be able to distinguish between a connection that  
is not available yet and a connection that has been miswritten (a  
typo) or simply doesn't exist; error tracking would be appalling.  
However, (b) is probably the same as (a): an error is already raised  
when the connectionid is unknown.

Lorenzo

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 28 Feb 2008 23:24:49 +0200

Hi,
I could agree to (b) only if the invite from AS to MS will be to a URI that identify the specific conference or the specific IVR service. 
Otherwise the only thing the MS can do it send a 200 with all the codecs received from the AS supplying some transport address which may need to be changed later after it receives the JOIN/Dialog start.
Roni

> Sent: Thursday, February 28, 2008 9:22 PM
> To: Steve Buko
> Cc: McGlashan, Scott; Even, Roni; [email-masked]

---

From: Rahul <[email-masked]>
Date: Fri, 29 Feb 2008 10:45:22 +0530

Media Negotiation via SIP and specific MS operations (requests to join
conference/IVR) are two different things they should not be mixed.
Going into specifics if the AS is trying to negotiate via regular offer
answer nothing should stop MS from sending a transport address even though
its not connected to a conference ,IVR or whatever.
If AS has to send specific control requests before offer answer takes place
then how to support the scenarios when first INVITE to MS is not with offer
or negotiation is done with hold SDP. 
Suppose the offer answer exchange was an audio SDP now requests comes to
join a video conference then MS should either send reINVITE with conference
codecs. (I would prefer re-INVITE) 
Whatever way is agreed upon at least it should be done when basic offer
answer is exchanged. If the MS feels the negotiated media is not enough to
go ahead SIP gives the flexibility of starting renegotiation. 
Also I don't agree it can be left with vendor implementation. This means I
can't design AS independent of the vendors. 

Regards,
Rahul

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Even, Roni
Sent: Friday, February 29, 2008 2:55 AM
To: [email-masked]; Steve Buko
Cc: [email-masked]
Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt

Hi,
I could agree to (b) only if the invite from AS to MS will be to a URI that
identify the specific conference or the specific IVR service. 
Otherwise the only thing the MS can do it send a 200 with all the codecs
received from the AS supplying some transport address which may need to be
changed later after it receives the JOIN/Dialog start.
Roni

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 29 Feb 2008 08:56:33 -0000

Yes - it's important to consider an 'offer-less' INVITE where the AS is probing for all available media from an MS (basic operation rather than prior knowledge).

Chris.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rahul
Sent: 29 February 2008 05:15
To: 'Even, Roni'; [email-masked]; 'Steve Buko'
Cc: [email-masked]
Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt

Regards,
Rahul

-----Original Message-----

Hi,

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 29 Feb 2008 18:40:44 +0200

Rahul,
You described the simple case. What if the first offer answer is Audio SDP and when the JOIN for video arrives the MS do not have resources.

I also think that to do a second re-invite that could have been prevented if the JOIN came first is not the best approach
Roni

> From: Rahul [mailto:[email-masked]]
> Sent: Friday, February 29, 2008 7:15 AM
> To: Even, Roni; [email-masked]; 'Steve Buko'
> Cc: [email-masked]

---

From: "Even, Roni" <[email-masked]>
Date: Fri, 29 Feb 2008 18:46:08 +0200

Chris,
What should the MS answer if it can do audio IVR and video conferencing?
Roni

> Sent: Friday, February 29, 2008 10:57 AM
> To: [email-masked]; Even, Roni; [email-masked]; Steve Buko
> Cc: [email-masked]
> Yes - it's important to consider an 'offer-less' INVITE where the AS is
> probing for all available media from an MS (basic operation rather than
> prior knowledge).
> 
> Chris.
> 
> 
> Behalf Of Rahul

---

From: "Steve Buko" <[email-masked]>
Date: Fri, 29 Feb 2008 11:47:20 -0500

Roni,

If the AS sends an "audio only" SDP to the MS, this means that the remote endpoint is not video capable or the AS is limiting its capabilities to audio only.

Either way though, the AS should not be adding that endpoint to a video conference unless they are expecting to have that endpoint participate as an audio only party in a video conference.

Steve

|-----Original Message-----
|From: Even, Roni [mailto:[email-masked]]
|Sent: Friday, February 29, 2008 11:41 AM
|To: [email-masked]; [email-masked]; Steve Buko
|Cc: [email-masked]
|Subject: RE: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt
|
|Rahul,
|You described the simple case. What if the first offer answer is Audio SDP
|and when the JOIN for video arrives the MS do not have resources.
|
|I also think that to do a second re-invite that could have been prevented
|if the JOIN came first is not the best approach
|Roni
|
|
|> -----Original Message-----
|> From: Rahul [mailto:[email-masked]]
|> Sent: Friday, February 29, 2008 7:15 AM
|> To: Even, Roni; [email-masked]; 'Steve Buko'
|> Cc: [email-masked]
|> Subject: RE: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-
|01.txt
|>
|> Media Negotiation via SIP and specific MS operations (requests to join
|> conference/IVR) are two different things they should not be mixed.
|> Going into specifics if the AS is trying to negotiate via regular offer
|> answer nothing should stop MS from sending a transport address even
|though
|> its not connected to a conference ,IVR or whatever.
|> If AS has to send specific control requests before offer answer takes
|> place
|> then how to support the scenarios when first INVITE to MS is not with
|> offer
|> or negotiation is done with hold SDP.
|> Suppose the offer answer exchange was an audio SDP now requests comes to
|> join a video conference then MS should either send reINVITE with
|> conference
|> codecs. (I would prefer re-INVITE)
|> Whatever way is agreed upon at least it should be done when basic offer
|> answer is exchanged. If the MS feels the negotiated media is not enough
|to
|> go ahead SIP gives the flexibility of starting renegotiation.
|> Also I don't agree it can be left with vendor implementation. This means
|I
|> can't design AS independent of the vendors.
|>
|> Regards,
|> Rahul
|>
|>
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]] On
|> Behalf Of Even, Roni
|> Sent: Friday, February 29, 2008 2:55 AM
|> To: [email-masked]; Steve Buko
|> Cc: [email-masked]
|> Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-
|01.txt
|>
|> Hi,
|> I could agree to (b) only if the invite from AS to MS will be to a URI
|> that
|> identify the specific conference or the specific IVR service.
|> Otherwise the only thing the MS can do it send a 200 with all the codecs
|> received from the AS supplying some transport address which may need to
|be
|> changed later after it receives the JOIN/Dialog start.
|> Roni
|>
|> > -----Original Message-----
|> > From: [email-masked] [mailto:[email-masked]]
|> > Sent: Thursday, February 28, 2008 9:22 PM
|> > To: Steve Buko
|> > Cc: McGlashan, Scott; Even, Roni; [email-masked]
|> > Subject: RE: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-
|> 01.txt
|> >
|> > I also am with (b), and agree with Steve about his sequence diagram. I
|> > proposed a similar approach in a mail I sent some hours ago in reply
|> > to a message of the discussion, but it looks like it never made it to
|> > the list... in the mail I also gave a reason why I'd prefer (b) over
|> > (c): the MS wouldn't be able to distinguish between a connection that
|> > is not available yet and a connection that has been miswritten (a
|> > typo) or simply doesn't exist; error tracking would be appalling.
|> > However, (b) is probably the same as (a): an error is already raised
|> > when the connectionid is unknown.
|> >
|> > Lorenzo
|> >
|> >
|> >
|> > Quoting Steve Buko <[email-masked]>:
|> >
|> > >
|> > > I personally prefer (b), but I'm OK with (c).
|> > >
|> > >
|> > > For (b) I think the dead air issue can be solved in most cases by the
|> > > AS.
|> > > It can issue the media control commands prior to answering the call
|> back
|> > > to the endpoint.
|> > >
|> > > i.e.
|> > >
|> > > UA               AS              MS
|> > > ----- INVITE ---->
|> > >                  ----- INVITE ---->
|> > >                  <---- 200OK ------
|> > >                  --- MC Request -->
|> > >                  <-- MC Response --
|> > > <--- 200OK ------
|> > >
|> > >
|> > >
|> > > Going with option (c) may eliminate the dead air issue, but won't it
|> > > create a converse issue of clipping.
|> > > In other words, we are saying that as soon as the MS receives the
|> > > INVITE, it should process the queued media control request.
|> > > In this case, the MS may be streaming media to an endpoint that is
|> > > hearing ringback because the AS hasn't responded to the UA with a
|> 200OK
|> > > yet.
|> > > This may be acceptable for a conference.  Not so acceptable for a
|> > > greeting.
|> > >
|> > >
|> > > Steve
|> > >
|> > >
|> > >
|> > > |-----Original Message-----
|> > > |From: McGlashan, Scott [mailto:[email-masked]]
|> > > |Sent: Thursday, February 28, 2008 12:06 PM
|> > > |To: Steve Buko; Even, Roni; [email-masked]
|> > > |Cc: [email-masked]
|> > > |Subject: RE: [MEDIACTRL]
|> > > draft-ietf-mediactrl-sip-control-framework-01.txt
|> > > |
|> > > |I agree - we want/need separation on the MS between the negotiated
|> > > |connection capabilities and any operation applied by the MS. It's
|the
|> > > AS's
|> > > |job to make sure they match up.
|> > > |
|> > > |The proposal to allow the MS to accept a join/dialogstart command
|> when
|> > > the
|> > > |connection is not already available seems reasonable to me for cases
|> > > where
|> > > |there could be a slight timing difference between when the MS
|> receives
|> > > a
|> > > |join/start command and the connection being in a connected state. If
|> > > the AS
|> > > |sends the command too late, you get a 'dead air' delay between call
|> > > |connection and media processing (such as an announcement) - not good
|> > > for
|> > > |the end-user experience. And I don't think we want the AS repeatedly
|> > > |sending the command until it is accepted (unnecessary traffic and
|> still
|> > > the
|> > > |potential for a delay with RTT).
|> > > |
|> > > |The specs are currently agnostic on this issue - they don't
|> explicitly
|> > > |allow it or disallow it. So we could:
|> > > |
|> > > |(a) Change nothing: it is an implementation issue.
|> > > |
|> > > |(b) Explicitly state that an error is raised if a join/dialogstart
|> > > command
|> > > |contains a connectionid which is not already connected.
|> > > |
|> > > |(c) Clarify that an MS MAY implement dialogstart/join so that if a
|> > > |connection is not already available, execution of the operation may
|> be
|> > > |queued for a short time prior to the connection being connected.
|> > > |
|> > > |(d)  Clarify that an MS MUST implement dialogstart/join so that if a
|> > > |connection is not already available, execution of the operation is
|> > > queued
|> > > |for a short time prior to the connection being connected.
|> > > |
|> > > |Based on list discussion so far, there are some objections to (b)
|and
|> > > (d).
|> > > |Could we agree on (a) or (c)?
|> > > |
|> > > |I vote for (c) but would be ok with (a). I'm open to (b) if someone
|> can
|> > > |explain how to avoid a 'dead air' delay.
|> > > |
|> > > |
|> > > |Scott
|> > > |
|> > > |
|> > > |-----Original Message-----
|> > > |From: Steve Buko [mailto:[email-masked]]
|> > > |Sent: Thursday, February 28, 2008 16:49
|> > > |To: Even, Roni; [email-masked]; McGlashan, Scott
|> > > |Cc: [email-masked]
|> > > |Subject: RE: [MEDIACTRL]
|> > > draft-ietf-mediactrl-sip-control-framework-01.txt
|> > > |
|> > > |Well actually you don't send all the supported media.  You send what
|> > > was
|> > > |negotiated using what was "offered" as a priority list.
|> > > |The AS controls the "offered" list and it's priority.
|> > > |And it's far from meaningless IMO. :)
|> > > |
|> > > |Regarding the "common mode" for a video conference when transcoding
|> is
|> > > not
|> > > |supported, this would be up to the AS to make sure it modified the
|> SDP
|> > > |properly.  The AS has the business logic.
|> > > |
|> > > |Again, the MS should not be using a single inbound media control
|> > > request to
|> > > |negotiate the media for the call.  The AS owns the SDP and what
|> should
|> > > be
|> > > |negotiated.
|> > > |
|> > > |Forcing the AS to send re-INVITE requests every time it wants to
|> > > perform a
|> > > |different type of media operation is not desired or required.
|> > > |
|> > > |
|> > > |
|> > > |
|> > > |
|> > > ||From: Even, Roni [mailto:[email-masked]]
|> > > ||Sent: Thursday, February 28, 2008 10:01 AM
|> > > ||To: Steve Buko; [email-masked]; McGlashan, Scott
|> > > ||Cc: [email-masked]
|> > > ||Subject: RE: [MEDIACTRL]
|> > > ||draft-ietf-mediactrl-sip-control-framework-01.txt
|> > > ||
|> > > ||Scott
|> > > ||
|> > > ||Sending all the supported media is meaningless since it may require
|> a
|> > > ||RE- invite when the conference target is known (this will be the
|> case
|> > > ||for the video for voice activated video switch when the MS cannot
|> > > ||transcode video but need to set a common mode)
|> > > ||
|> > > ||
|> > > ||
|> > > ||"Following your idea, take this example.
|> > > ||Suppose the MS received a prior request to put a party in an audio
|> > > only
|> > > ||conference.
|> > > ||Then when the party arrives, the MS would negotiate an audio only
|> call
|> > > ||(because of the prior request).
|> > > ||What happens later when the AS wants to move to party to a video
|> > > ||conference or simply play a video?"
|> > > ||
|> > > ||
|> > > ||The AS need to unjoin him from the audio conference, join him to
|the
|> > > ||new conference and send a re-invite.
|> > > ||
|> > > ||Roni
|> > > ||
|> > >
|> > >
|> >
|> >
|> >
|> > --
|> > 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]
|> _______________________________________________
|> MEDIACTRL mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/mediactrl
|> Supplemental Web Site:
|> http://www.standardstrack.com/ietf/mediactrl

---

From: "Tim Melanchuk" <[email-masked]>
Date: Fri, 29 Feb 2008 09:23:36 -0800

i agree with steve here. the AS controls the SDP. the MS simply answers
the SDP that is offered and can only use the media that is negotiated for
services. the AS can re-negotiate when/if it wants.

the <join> operation allows specification of specific media streams. so
the AS can be explicit about which media streams to join, and a MS
can error case invalid requests.

timm

On Fri, Feb 29, 2008 at 8:47 AM, Steve Buko <[email-masked]> wrote:

> Roni,
>
> If the AS sends an "audio only" SDP to the MS, this means that the remote
> endpoint is not video capable or the AS is limiting its capabilities to
> audio only.
>
> Either way though, the AS should not be adding that endpoint to a video
> conference unless they are expecting to have that endpoint participate as an
> audio only party in a video conference.
>
>
> Steve
>
>

---

From: "Even, Roni" <[email-masked]>
Date: Sat, 1 Mar 2008 01:15:46 +0200

Hi,

I was referring to the example that Rahul gave in the thread. My claim here based also on your answer is that the MS response to the first offer with the offered SDP may cause in many cases a need to re-invite after the JOIN which can be prevented.

The exception is if the AS MUST handle the conference common mode and change it, or not, based on the parties joining the conference. This means that the AS must know the full capability of all MS which I am not sure was what we wanted.

Roni

________________________________

From: Tim Melanchuk [mailto:[email-masked]] 
Sent: Friday, February 29, 2008 7:24 PM
To: Steve Buko
Cc: Even, Roni; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt

timm

Roni,

Steve