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

[Jonathan Rosenberg <[e-mail]>]

It only gets pushed to the client if the client indicates support for 
it. Thus, the typical flow is:

A->B : "hey, you can send me pic if you want"
B->A : "ok I will"

and I think this is very much like:

A->B : "please send be pic"
B->A : "ok I will"

which is what SIP events is about. In terms of the need to understand 
the semantics of the data, they are identical.

Now, the intended model in TOTE is that there would be two types of 
purpose parameters. Global ones which are standardized, and a vendor 
tree. The global ones require a specification, though it doesnt at the 
moment require standards track. But it does need an RFC. I am happy to 
debate standards track vs. ietf action.

That said, depending on the purpose, I don't think there is that much 
needed in such a spec. For example, for pic, something along the lines 
of "this purpose is meant for picture sharing between users. For 
example, in cases where a user with a cell phone snaps a picture during 
a call and wishes to send it to the other person, or wishes to send an 
existing file on disk. The received picture is normally rendered, 
possibly with user permission, and possibly saved by the recipient. All 
implementations MUST support image/jpg."

I'm not sure that much more is required; we could debate whether 
max-size needs to be dealt with, and that could be done any number of 
ways. The TOTE model would argue that you would do this by having a 
message from recipient to sender, over this TOTE connection, with the 
max size. Indeed, you could also have a message from sender to recipient 
first that indicates an interest in sending a picture right now, 
including picture metadata. This would imply that "pic" is really a 
three way handshake, two of which are some new messages we'd need to 
define (and presumably would be defined by the tote usage). We could 
alternatively send those params through SDP, but that constrains us to 
the O/A 2-way handshake; and as we have seen with things like SRTP, 
having the flexibility of building the protocol without the constraints 
of O/A is highly beneficial. It also means you can add new stuff without 
extending SIP itself.

What TOTE does is it avoids the need for this particular application to 
define how to get connections set up through sip, how to secure them, 
how to do nat traversal for them, how to signal what they are used for, 
how to negotiate them, and so on. It also gives us the ability to share 
connections across applications when it makes sense; this also allows us 
to have very rich multi-app communications in one session without this 
large number of connections.

And so in my mind, it lowers the bar for new applications by providing a 
framework for adding new ones without needing to change SIP, and to have 
the flexibility of engineering the application ideally for its 
particular needs.

-Jonathan R.

[e-mail] wrote:
>    From: Dean Willis <[e-mail]>
> 
>    Ok, I think I agree with you here. Each "purpose" would need to be  
>    very clearly specified, at roughly the same level of detail as is  
>    required for an event package or would be required for an INFO package  
>    if we were to go that way.
> 
> IMHO the purposes need to be specified in *more* detail than an event
> package.  The reason is that an event package is "pull" information,
> the meaning of the information is defined by the event-name, but the
> requestor is presumed to know *why* it wants the information, that is,
> what it intends to do based on that information.  A TOTE object, like
> an INFO, is "push" information, and the attached meta-data must
> specify not only what the information means, but how the recipient is
> expected to act on it.
> 
> Dale
> _______________________________________________
> Sip mailing list  http://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
> 

-- 
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  http://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