2011/5/26 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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".
1) MSRP is not
so new (2007).
2) 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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>