2011/5/26 Daniel-Constantin Mierla miconda@gmail.com:
I would not like to send a ISO image using RTP ;)
That can be done with payload in sip messages. Again, you look only at a side of the coin, the one that is wrong, but gives you some reason to continue this debate -- I haven't said everything has to be RTP, so for example I mentioned TCP.
Just to confirm: when you say TCP, do you mean SIP over TCP/TLS and message data of file data within SIP messages body? Or do you mean something like "RTP over TCP" for binary data transmission? (I'm 90% sure you mean the first option, just want to confirm it).
I really wonder how good is for kamailio having to deal with message bodies of 1MB (being kamailio a SIP proxy, so theorically something ready for handling small messages).
This is your assumption. Besides that we talk about negotiation of a communication session, where parameter as agreed. The proxy can say in some cases when something is too big or too low (see registration time).
When an audio/video session is negotiated, the SIP proxy does not validate/constrain the "size" of the media. By passing the media (as you suggest) through the signaling, such traffic is not end-to-end anymore and intermediary proxies with no very good bandwitch (or messages size constrains) would stand in the media traffic.
Honestly I like the concept of "signalling through intermediaries and media sessions end-to-end".
- MSRP is not so new (2007).
- Your suggested new protocol would be newer than MSRP :)
I suggested a new protocol? I have the impression that you read different content -- it is SIP, nothing else, just properly applied for particular cases.
Ok, let me replace "new protocol" with "new spacefication" :)
Can you answer why presence is not on a different protocol (communication channel)? A presence document will all tags and extensions can easily go to quite significant size.
Well, if we take into consideration XCAP stuff then SIP presence is indeed a new protocol. But anyway you already know what I think about SIMPLE presence specs. They are an IETF bug in all the terms (design, scalability...).
You provide arguments I can't follow, jumping randomly -- so xmpp does IM in 'signaling', it is good because has session idea defined there (which is a simple concept as a 'string token' representing session id),
Ok, I don't think XMPP is the very best protocol in the world. It comes from many years ago (Jabber and so). I don't consider XMPP the example to follow.
Maybe SIP is the first protocol separating signalling and IM in different streams. Maybe this is not the easiest approach to deal with NAT/firewalls issues, but I like this radical concept.
while same concept in SIP (which exists for voice dialogs) will create a completely new protocol if applied for MESSAGE (let's not use MESSAGE, let's use UPDATE since it has the notion of session an can carry any kind body, is it better?).
Right. I don't say that your approach is incorrect. In fact it seems very suitable (but IMHO just for short text messages within a session, not for file transfer).
You don't think that is bad in xmpp, but is bad in sip, because you _believe_ kamailio is able to work with small buffers only (would it be hard to increase them if needed? it will just relay, no understanding of content).
Doesn't XMPP use gateways for file transfer?:
XEP-0095: Stream Initiation ------------------------------------------ http://xmpp.org/extensions/xep-0095.html
As the Jabber protocols are extended beyond basic messaging and presence, the need has arisen for a generic protocol that can be used to negotiate content streams between any two entities. Such streams might be in-band, but more likely will be out-of-band, binary streams used in applications such as file transfer, voice chat, and video conferencing. This document provides a method for negotiating such streams, including meta-information about the intended usage of the stream.
XEP-0096: SI File Transfer --------------------------------------- http://xmpp.org/extensions/xep-0096.html
This specification defines a profile of the XMPP stream initiation extension for transferring files between two entities. The protocol provides a modular framework that enables the exchange of information about the file to be transferred as well as the negotiation of parameters such as the transport to be used.
If we take XMPP as an example, I think the above two XEP's seem more similar to what MSRP defines.
Well, IAX is much simpler than SIP, and IAX is basically the same you are propossing (mixing signalling and media in the same stream). Do you prefer IAX over SIP? :)
And you cannot convince me in ages that MSRP is something bringing any benefits -- just another ugly hack for something that could have been solved very nicely with existing specs.
Daniel, I could agree that using SIP message bodies for carrying IM pure text/chat sessions could make sense, sure. But I don't think that is also suitable for file transfer or any other kind of data. Even less if we take into account that other IM protocols also use separate streams for file transfer.
MSRP just unifies IM sessions and file transfer in a separate stream.
Cheers.