Subject: [MMUSIC] comments on draft-garcia-mmusic-sdp-collaboration-00

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 09 Mar 2008 13:17:39 -0400

Firstly, I think it would be good to finally solve this problem. We've 
taken a run at this in ietf at least two times, and it fizzled out in 
all cases.

That said, I'm not sure I agree on the direction here for several 
reasons. Firstly, it doesn't actually define just one solution for app 
sharing - it defines two and possibly three. So if I wanted to share my 
web browser, I could use t120, RFB, or the url-transfer. Without a 
minimum mandatory-to-implement mechanism, we'll have loads of interop 
problems here, as everyone will pick something different.

I particularly dislike the co-browsing solution. Its almost NEVER going 
to work since these days most sites are dynamic and render content based 
on the identity of the user (cookies, login, etc.). Why specify 
something that will have a relatively low and unpredictable rate of success?

Also, I think one of the reasons our efforts at collab have failed is 
that we are always too ambitious. If we look at the most common usage of 
collaboration in practice today, its one person sharing a PPT document 
or word document with others. I think this is the most common case by a 
lot - 90% of collab is probably of this variety. There is no remote 
control, no remote mouse or keyboard. And today its mostly done through 
web technologies like flash, which are, in essence, "video codecs" for 
the web.

And so, I would suggest that, to lower the bar for collab in SIP, we 
define a baseline mechanism that is basically "use video". We can pick a 
codec (something like h264 SVC is particularly well suited, though this 
will no doubt be a nice debate), and make sure its clear how to signal 
it in SDP (is it m=video? m=application). Presto - we have a simple 
collab solution that makes sense. You can share your web browser, your 
PPT, word document, whatever, and get reasonably good efficiency out of 
it.  We can layer in, ontop of that, additional mechanisms for remote 
mouse and keyboard or shared whiteboard, but these are niche and I don't 
want to let the perfect be the enemy of the good. If I have to go 
implement all of T.120 just to share PPT - well thats not very good news.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 15 Mar 2008 17:39:24 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jonathan Rosenberg
>

I concur - it's a bad idea, for the reasons you cite.  It also raises several security issues, for which TLS as described in the security section provides absolutely no protection, because they're at a higher layer.  For example, I can inadvertently/unknowingly be sending a url-transfer that directs your browser somewhere not so nice.  It would also mean pop-up-filters are bypassed, and more.  It's just a big can of worms.

> control, no remote mouse or keyboard.

Actually, I think your company (at least the WebEx group) would dispute that. ;)  Simultaneous control may not be big, but exchanging the focus of control is not so niche I think.

Personally I like the RFB model.  I know nothing about H.264 SVC - does it offer pointer and key-press mechanisms like RFB?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 15 Mar 2008 18:00:11 -0400

One note about the proposed T.120 encoding in this draft: it defines an SDP attribute for indicating the SIP call-id, from-tag, and to-tag.  This is the second time in the past couple weeks I've seen this idea (the other was mediactrl).  It's not good.

For one, I actually think it's architecturally unsound to expect the media plane to know squat about the SIP call-id, and certainly not the tags.  SIP is the rendezvous protocol of choice for you, but there's no reason the media mechanism couldn't use a different one if warranted someday.  (ie, it shouldn't be defining a SIP-only SDP attribute)

For another, there are middleboxes which change SIP call-ids (and tags for that matter), which will break it. (and no, it's not just SBCs)

So I think if you need a session identifier at the media plane, define an SDP attribute that is one.  Like, oh, for example the already existent o= line session-id... or a new one.  Maybe we need a common one, if multiple drafts are going this way?

I also don't see what the field is used for when it's set to the dialog info.  The draft says the answerer verifies the attribute value by checking if a matching SIP dialog is found, but since that's in the SIP request carrying the SDP (because the draft says for the offerer to create it as such), what value is this? (wouldn't it always pass verification?)  I would expect verification to be something done in the T.120 connection layer itself, using the session info.

-hadriel

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 17 Mar 2008 12:56:42 +0200

> For one, I actually think it's architecturally unsound to expect the media plane to know squat about the SIP call-id, and certainly not the tags.  SIP is the rendezvous protocol of choice for you,…

Well, we are trying to correlate the media with the signaling. This 
requires a correlation mechanism of any kind, which implies that the 
media plane must be aware of some piece of data from the signaling plane.
> So I think if you need a session identifier at the media plane, define an SDP attribute that is one.  Like, oh, for example the already existent o= line session-id... or a new one.  Maybe we need a…

And those middleboxes that you refer earlier (including also SBCs) do 
not change the o= line in SDP or "forget" to include unknown SDP 
parameters, right?

I think any SBC in the path will create harm, no matter which parameters 
we decided to use for the correlation.

> I also don't see what the field is used for when it's set to the dialog info.  The draft says the answerer verifies the attribute value by checking if a matching SIP dialog is found, but since that…

I agree with you that the explanation is lame. It goes in to the deeps 
of T.120. There is a parameter in T120 call ConferenceName that acts as 
some sort of conference identifier. This is the field that allows an 
endpoint to correlate the media plane with the signaling plane. That's 
the reason why the draft proposes that the T.120 session includes a well 
known ConferenceName.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 17 Mar 2008 15:11:10 -0400

> From: Miguel Garcia [mailto:[email-masked]]
>
> Hadriel Kaplan wrote:
> > For one, I actually think it's architecturally unsound to expect the
> > media plane to know squat about the SIP call-id, and certainly not the
> > tags.  SIP is the rendezvous protocol of choice for you, but there's no
> > reason the media mechanism couldn't use a different one if warranted
> > someday.  (ie, it shouldn't be defining a SIP-only SDP attribute)
>

Are you trying to correlate the media with the signaling session, or with the media session?
By that I mean if the SDP contained a media session identifier, is that good enough?

> > For another, there are middleboxes which change SIP call-ids (and tags
> > for that matter), which will break it. (and no, it's not just SBCs)
> > So I think if you need a session identifier at the media plane, define
> > an SDP attribute that is one.  Like, oh, for example the already
> > existent o= line session-id... or a new one.  Maybe we need a common
> > one, if multiple drafts are going this way?
>

It's a game of probabilities.  There are SBCs and B2BUA's which have to know all SDP they see; or are provisioned to work on a whitelist basis, only allowing SDP attributes they are set to allow; or do so because they really are the terminator of the media session (for example when doing transcoding).

However, for those types of SBCs, or when SBCs are provisioned to act that way, they would need to add support for this T.120 most likely anyway.  But I believe that type of configuration is the minority, not majority. (though I don't have a perfect view of what even my own customers configure, let alone other SBC vendors)

There are SBC configurations which change the o= line session id, because it has been found that one can fairly accurately discern the endpoint vendor type based on that field's contents.  Again I think it's a minority (maybe).  Using a new SDP attribute may be more successful.

The important thing though is not to make the T.120 behavior incompatible with what SBCs have to do - and that includes topology hiding.  Using the SIP call-id is not the type of thing that SBCs could go and stop changing if they need to support T.120, because the Call-id has IP Addresses.  What we need to do is simply use something that is not contradictory with their goals.  And my guess is doing so will also happen to work through many currently deployed configurations without changes, which is a good thing.

I'm not saying we need to support SBC environments, just that I see no reason to explicitly make it NOT work in their environments.  It's kinda like NATs - you can either try to avoid things which you know will break, or you can knowingly make a protocol not work through NATs.

-hadriel

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 18 Mar 2008 09:39:51 +0200

Inline

> By that I mean if the SDP contained a media session identifier, is that good enough?

At this point, I think any kind of correlation will work. Perhaps 
preferable with the media session, as you mentioned.

> The important thing though is not to make the T.120 behavior incompatible with what SBCs have to do - and that includes topology hiding.  Using the SIP call-id is not the type of thing that SBCs co…

I think this is a fair requirement. So, any sort of magic cookie or 
token expressed in SDP will make this work.

/Miguel

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 20 Mar 2008 15:48:57 +0000

Miguel,

See below.

John 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Garcia, Miguel 
> (NSN - FI/Espoo)
> Sent: 18 March 2008 07:40
> To: Hadriel Kaplan
> Cc: Joerg Ott; IETF MMUSIC WG
> Subject: Re: [MMUSIC] comments on 
> draft-garcia-mmusic-sdp-collaboration-00
> 
> Inline
> 
> Hadriel Kaplan wrote:
> > 
[JRE] Should it be with the entire session or with a particular m-line?
Depending on the answer the cookie could be a session level or a media
level attribute.

> > It's a game of probabilities.  There are SBCs and B2BUA's 
> which have to know all SDP they see; or are provisioned to 
> work on a whitelist basis, only allowing SDP attributes they 
> are set to allow; or do so because they really are the 
> terminator of the media session (for example when doing transcoding).
> > 
> > However, for those types of SBCs, or when SBCs are 
> provisioned to act that way, they would need to add support 
> for this T.120 most likely anyway.  But I believe that type 
> of configuration is the minority, not majority. (though I 
> don't have a perfect view of what even my own customers 
> configure, let alone other SBC vendors)
> > 
> > There are SBC configurations which change the o= line 
> session id, because it has been found that one can fairly 
> accurately discern the endpoint vendor type based on that 
> field's contents.  Again I think it's a minority (maybe).  
> Using a new SDP attribute may be more successful.
> > 
> > The important thing though is not to make the T.120 
> behavior incompatible with what SBCs have to do - and that 
> includes topology hiding.  Using the SIP call-id is not the 
> type of thing that SBCs could go and stop changing if they 
> need to support T.120, because the Call-id has IP Addresses.  
> What we need to do is simply use something that is not 
> contradictory with their goals.  And my guess is doing so 
> will also happen to work through many currently deployed 
> configurations without changes, which is a good thing.
> 
[JRE] I agree with Hadriel. Some end-to-end token, rather than call-ID,
would make it a lot more deployable.

> 
> > 
> > I'm not saying we need to support SBC environments, just 
> that I see no reason to explicitly make it NOT work in their 
> environments.  It's kinda like NATs - you can either try to 
> avoid things which you know will break, or you can knowingly 
> make a protocol not work through NATs.
> > 
> > -hadriel
> > 
> 
> /Miguel
> --

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 27 Mar 2008 15:05:33 +0200

Hi John:

Thanks for your comments. Inline thoughts.

> Depending on the answer the cookie could be a session level or a media

I think correlation is required at the media level, not at the session 
level.

> would make it a lot more deployable.

Fine with me.

/Miguel