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

From: "Eric Burger" <[email-masked]>
Date: Tue, 4 Mar 2008 12:00:19 -0800

+1

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

----- Original Message -----
From: Steve Buko <[email-masked]>
To: Even, Roni <[email-masked]>; Eric Burger; Lorenzo Miniero <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Tue Mar 04 05:29:50 2008
Subject: RE: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt

I am restating my previous opinion I guess when I say that I am in favor of option (b).
This would reject all <join> requests unless the INVITE has been received previously.  

Roni and I are 180 degrees apart on this it appears.  
I could accept option (c) which would allow a <join> to be received prior to the INVITE, but does NOT make that support a MUST.

Roni said,
".. if the INVITE is not defined by a previous JOIN it should be rejected."
I am having a hard time with the idea of making inbound SIP requests dependent on a specific media control protocol.  This is what is being said here ultimately.  In my opinion, the inbound SIP request and the "possibly" subsequent media control request(s) are totally independent.  

Personally, I would like my MS to support MSML, MSCML, and the new mediactrl protocol that we are defining.  Rejecting inbound SIP calls because I haven't received a "mediactrl" <join> is not a limitation that I would be interested in adding to my MS.  

Steve

|-----Original Message-----
|From: Even, Roni [mailto:[email-masked]]
|Sent: Tuesday, March 04, 2008 2:13 AM
|To: Eric Burger; Lorenzo Miniero; Steve Buko
|Cc: [email-masked]
|Subject: RE: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt
|
|Eric,
|I am not following your reasons.
|
|I do not see any more error conditions and not any more denial of service
|attacks.
|On the contrary, if the control connection between the AS and MS is secure
|than if the INVITE is not defined by a previous JOIN it should be rejected.
|This is my preference for the call flow.
|
|
|
|Roni
|
|> -----Original Message-----
|> From: Eric Burger [mailto:[email-masked]]
|> Sent: Tuesday, March 04, 2008 2:18 AM
|> To: Even, Roni; Lorenzo Miniero; Steve Buko
|> Cc: [email-masked]
|> Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-
|01.txt
|>
|> I can only agree to (b) [as a participant].  Otherwise, we have a ton of
|> error conditions to deal with, besides opening yet another denial-of-
|> service
|> attack vector.
|>
|>
|>
|> On 2/28/08 4:24 PM, "Even, Roni" <[email-masked]> wrote:
|>
|> > 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
|> Supple
|> > mental Web Site:
|> http://www.standardstrack.com/ietf/mediactrl
|>
|>
|> Notice:  This email message, together with any attachments, may contain
|> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
|> entities,  that may be confidential,  proprietary,  copyrighted  and/or
|> legally privileged, and is intended solely for the use of the individual
|> or entity named in this message. If you are not the intended recipient,
|> and have received this message in error, please immediately return this
|by
|> email and then delete it.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 4 Mar 2008 23:33:53 +0200

Hi,
I will not fight you all.

Still I would like to see some text in the control framework explaining what is expected from the MS as response to the INVITE in terms of the codecs and who decided which media and which codecs to have in the call and who control the common mode for video switch.

If it is the AS than how does he get the supported media from the MS.

The frame work should also say that the MS MSUT be able to get an INVITE without knowing what function will be used (IVR, Conferencing other package)

Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Eric Burger
> Sent: Tuesday, March 04, 2008 10:00 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [MEDIACTRL] draft-ietf-mediactrl-sip-control-framework-01.txt
> 
> +1
> 
> --
> Sent from my wireless e-mail device. Sorry if terse.  We all need
> lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what
> lemonade is.
> 
> I could accept option (c) which would allow a <join> to be received prior
> to the INVITE, but does NOT make that support a MUST.
> 
> 
> Roni said,
> I am having a hard time with the idea of making inbound SIP requests
> dependent on a specific media control protocol.  This is what is being
> said here ultimately.  In my opinion, the inbound SIP request and the
> "possibly" subsequent media control request(s) are totally independent.
> 
> Personally, I would like my MS to support MSML, MSCML, and the new
> mediactrl protocol that we are defining.  Rejecting inbound SIP calls
> because I haven't received a "mediactrl" <join> is not a limitation that I
> would be interested in adding to my MS.
> 
> 
> Steve
> 
> 
> 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.