Re: [Sip] New I-D - TOTE - "INFO" on the media path

[Jonathan Rosenberg <[e-mail]>]

inline:

Ted Hardie wrote:

>> OK; this was just a -00. There are two ways to deal with that:
>>
>> 1. add the additional negotiation needed for this as new SDP parameters, or
>>
>> 2. don't bother at all with MIME negotiation as part of SDP for TOTE;
>> rather, each purpose would have a protocol to doing the negotiations
>> needed to make its functionality work. This avoids needing to do a
>> general purpose MIME thing. FOr example, in the case of "pic", we'd
>> actually define a little protocol that negotiates pictures sizes and
>> supported types. In that applications, buckets and multiparts aren't an
>> issue.
>>
>> I'm inclined towards #2 actually. But note that, I put into TOTE exactly
>> the same level of MIME negotiation that SIP itself provides. SO if it is
>> grossly inadequate here, so it is there.
> 
> I'd be interested in seeing more on how #2 works.

Well, I'm thinking on my feet here, but for picture sharing, something 
like this:

A->B INVITE tote session, purpose=pic
B->A 200 OK tote, purpose=pic
A->B ACK

A->B [TOTE] I support jpg, png. Screen resolution here is just 100x200, 
8 bits color.
B->A [TOTE] I support just jpg, but I have a huge screen so up to 
1000x1000 is fine. 24 bits color.

and then later:

A->B [TOTE] Hey I'd like to send a picture, 200x200, jpg, 8 bits color. 
 From the camera. OK?
B  (prompts user, "Joe would like to send you a photo. Accept?". user 
accepts)
B->A [TOTE] yes proceed
A->B [TOTE] sends image
B->A [TOTE] file received


Again, thinking on my feet here.


   One of my concerns
> with "pic", to take one example, is how a very generic purpose like
> trading images gets used by applications that want it.  How does a
> system know when a pic being sent from one side of the TOTE exchange
> to the other is meant as a new user icon, an avatar for a MMORPG, or
> a stand-alone picture relevant to some ongoing exchange on a
> real time channel? 

I see your concern. I think the main criteria is that, this is used when 
the primary purpose is to render an image to the recipient, and allow 
them the option to save. Since a part of this is rendering you need to 
think about screen sizes, colors and so on to make sure the image is in 
a form that can be processed by the recipient for rendering. So anything 
that needs this - negotiation of picture sizes for immediate rendering - 
could use it. Primary application would presumably be cameras on mobile 
phones.


  If there is more interaction than just "purpose"
> and mime type, then re-use of this by applications that want the facility
> may work.
>  Otherwise, it seems you are either going to head towards
> purposes like "vnd.WoW" that have no generality or you are going
> to get what amounts to a least-common-denominator application.
> The "I can send you my name" application is not really too compelling.

Agreed. No dispute that each purpose needs to be well defined and broad 
enough to be useful and narrow enough to meet the needs of the specific 
use cases well. But thats always the case in engineering.


> 
> 
>>> Having a dispatch based on purpose without detailed specifications or
>>> reference to specific applications seems to hit a middle ground that's
>>> kind of nobody's sweet spot.
>> That was never the intent. The IANA considerations section states that
>> these require specification.
>>
>>> A specific application already has detailed
>>> semantics that go beyond this purpose to actual decisions of whether
>>> to render or store, user permissions needed, sizes accepted, etc;
>>> generalized MIME transfer protocols like SMTP or HTTP already
>>> use a different system for deciding which applications to invoke
>>> when faced with a MIME object, and this forces systems with that
>>> logic to have a parallel track.
>> That would seem to argue for pulling the MIME aspects out of TOTE.
>>
>>> The muxing seems liable to head of line blocking unless BEEP-like
>>> channels are introduced.
>> This is discussed; if the purpose requires significant content, set it
>> up as a separate session/tcp connection.
> 
> What you have there now is:
> 
>    However, if a purpose represents a
>    significant amount of data, such that head-of-line blocking might
>    occur between purposes, an agent SHOULD utilize a separate TOTE
>    session for that purpose.
> 
> I guess this still worries me.  If an application wants to set up a TOTE
> connection with an existing peer, I'm guessing it will need to decide
> whether to re-use an exiting session or set up a new one.  

Right.

> While it
> may have a sense of whether it will have large amounts of data to
> send, it doesn't have any idea of the sensitivity to head of line
> blocking from the other users of the connection.  

Well there is only one other user, the recipient. But I tend to think 
this is mostly a function of the 'purpose'. You'd put picture share by 
itself, but more control-style functions (i.e., camera control or 
conference controls) could be multiplexed.


That pushes the
> decision into the agent which knows something about both.
> But that ends up requiring a lot of knowledge of the protocol
> usage characteristics of the using application which go beyond
> what TOTE will carry on the wire (some uses of "pic" with image/jpeg
> are really highly unlikely to cause head of line blocking; others might be a
> real clog).

So I agree that this kind of dynamic decision is really complicated and 
a static decision based on purpose is much easier.


>> I was trying to provide a common mechanism for addressing those cases
>> where we don't want to send all this garbage over SIP - we want it over
>> the media plane. Are you objecting to that?
> 
> A number of your purposes seem pretty far outside the info-use-cases
> draft, and the level of generality does raise issues. 

I think the level of generality in there is EXACTLY the same as the 
INFO-usages. Thats why the reactions here surprise me. Fair enough that 
I do point out some use cases that are not in the INFO cases draft, but 
it was the whole INFO discussion that got me thinking that we have a 
need for a media-plane equivalent of INFO-events. TOTE is a nearly 
direct translation of the mechanism in Hadriels draft into the media 
plane. Purpose = info package, and the MIME negotiation is already there 
in SIP via Accept.

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[e-mail]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip