[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Comments to the TOTE draft
Inline as well.
Jonathan Rosenberg wrote:
> Ah, so there are two parts of this discussion:
>
> 1. whether MSRP is to be used as a general transport of stuff between
> agents, which is not strictly instant messaging (like camera controls)
>
> 2. regardless of MSRP vs. something else, when would one use the file
> transfer mechanism and when not
Right, that is correct. Besides, I think the general willingness of
making implementor's life easy, so that if we end up having several
orthogonal mechanisms that share some sort of commonality, all these
mechanism should be able to coexist in an implementation.
>
> Frankly I don't think you'd ever use the file transfer mechanism for
> camera controls, even a one-shot. Most of the file selector attributes
> don't make sense here - size, filename, hashes - these are useful
> primarily for transfering an existing stored file, not for carrying
> arbitrary protocols.
I think I concluded the same, but with different reasons. I think camera
control is probably a stream of actions, so you move the camera up, pan,
tilt, zoom, etc. Let's assume that you model each action in an XML
document. I wouldn't use the O/A described in the file transfer draft,
because you would need to re-INVITE prior to sending each action, get
acceptance from the remote party (the camera), and then do the action.
It will be annoying, with a tremendous overhead (re-INVITE), and far
from real-time.
However, you can easily create a regular MSRP channel where you
transport those MIME objects. MSRP can carry any MIME object of any
arbitrary length, so, it meets the needs. The discussion of MSRP/not
MSRP is below.
>
> So then the question is, is MSRP a general purpose UA to UA transport
> mechanism, or not. Frankly I think it is not. Its designed around
> instant messaging which is a particular application. ITs having
> extensions for things like nicknames and conferencing which are specific
> to IM. The reporting feature is also IMHO very much an IM-specific thing.
I disagree here. You said:
- It is designed around instant messaging: I would say MSRP is designed
around real-time transfer of objects. The MSRP draft provides examples
and provisions for transferring, for example, large video files.
- It's having extensions for things like nicknames and conferencing
which are specific to conferencing: I don't see the point here. It is
like if you tell me that SIP is not good for voice because there are
extensions for presence, instant messaging and alike. MSRP is generic
enough to carry objects between two points. Extensions try to improve
the user experience for specific applications.
>
> File transfer is arguably very close to IM and can benefit from much of
> what MSRP provides; chunking and interruption all make sense because
> these are big objects.
>
Agreed.
> TOTE proposes a much more lightweight transfer mechanism for general UA
> to UA protocols/applications.
And I don't object it. As I indicated earlier, the use case for the file
transfer is: I have an instant messaging application that implements
MSRP. Now you are probably saying: does it mean I need to implement MSRP
for a trivial file sending. The answer is no, and I don't have any
problem with the simple trivial protocol that the TOTE draft describes.
>>
>>> 2. the file transfer spec very much couples the negotiation of the
>>> file transfer itself (parameters of the file along with an indication
>>> of willingness) with O/A. We have been burned by this before, when
>>> we've tried to take negotiation things and couple them to the O/A
>>> exchange. Security key negotiation is an example. We found, in the
>>> end, by doing it in the media path we had more flexibility and were
>>> not limited to a two-way handshake. So another way to think of it, is
>>> this, would you benefit from separating the file transfer negotiation
>>> from O/A itself? Would you benefit from more round trips or more
>>> complex objects that are hard to place in SDP? I for one always
>>> thought file trnasfer is best done as a 4-way:
>>>
>>> A->B want to send file, here are characteristics
>>> B->A yes, please send
>>> A->B ok here is the file
>>> B->A got it
>>>
>>> basically the file transfer is doing the first two in O/A and the
>>> last two in MSRP, so it kind of works. But I wonder if you had more
>>> flexibility would we get a feature or capability that would be
>>> impossible otherwise. For example, the ability of the recipient to
>>> cancel mid-transaction, or to tell the sender to pause and resume. If
>>> we went this route, you'd basically take your existing SDP
>>> attributes, take them out into a standalone protocol message and send
>>> e2e over this connection instead.
>>
>> Yes, the background for the file transfer draft. It tries to emulate
>> the file transfer feature that we have in many instant messaging
>> systems. So, the coupling of the file description with the O/A works
>> well in that case. Any of both ends can also abort the file transfer.
>> Both ends can also pause and resume the file transfer.
>
> How do you do pause with MSRP? Specifically, how does the receiver tell
> the sender to pause? How does the receiver cancel?
Pause from receiver to sender: re-INVITE with SDP offer with the MSRP
media stream set to inactive.
Cancel from receiver: re-INVITE with SDP offer setting the MSRP media
stream to port 0.
>
>>
>>>
>>> 3. file transfer is for file transfer and tote is for other things
>>> that don't include file transfer; i.e., these look similar but file
>>> transfer has some special needs and that is why we have a specific
>>> spec for it. And so both proceed independently.
>>>
>>
>> I think the OTE draft should reuse the file transfer draft as much as
>> it could. Dealing with files or MIME objects is a subtle difference.
>> Perhaps the biggest difference is that TOTE tries to create a media
>> stream for transferring a MIME object, while the file transfer draft
>> assume a given protocol (so far MSRP) and a given purpose (a file).
>> But it should be possible for me to offer you a file with either MSRP
>> or the simple TCP connection that TOTE uses without much changes to
>> the SDP.
>
> That last sentence I agree with. However What I don't agree with, is if
> I am not transferring a file, just doing a camera control or somethign,
> that I have to use the file transfer SDP attributes.
I said "as much as it could", meaning that re-using or adapting already
defined SDP parameters.
/Miguel
>
>
> -Jonathan R.
>
>
>
--
Miguel A. Garcia tel:+358-50-4804586
Nokia Siemens Networks Espoo, Finland
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip