26 May
2011
26 May
'11
8:13 p.m.
On 5/26/11 6:41 PM, Iñaki Baz Castillo wrote:
If you can tell me when I sad mixing RTP and SIP, it
would be nice.
Otherwise try to re-read what I said -- the whole thing here is about
chatting. 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. Like SIMPLE for
presence, while end-to-end model was simpler and works even now with
kphone (implementation of year 2001) -- missing part there is
upload/download of buddy list to server, but I may want to store it in
dropbox, so not big loss with that.
Hope people will learn from recent experiences, Skype that was pure
end-to-end (im & presence) sold for billions -- simplicity sells very
well. People in SIP specs are trying to solve insignificant problems ...
due to end-to-end nature of presence and IM, how many were concerned
about battery life or bandwidth when running skype on mobile? How much
decreased those things the price? If it would have been SIMPLE + MSRP,
do you think the price would have been double?
I think we should be pragmatic and look at reality. New (useless)
components in network cost money and overhead in HA and scalability --
MSRP does that, period.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
2011/5/26 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
Desktop sharing is
streaming of screenshots taken with frequency like it
is video with images taken with a frequency from camera ...
you are simply on the wrong path in this
discussion, you kind of
misunderstand me.
First, I didn't know that SIP _MUST_ be over UDP only.
Sure not, I meant
sending data (desktop sharing as Jitsi does) via RTP (UDP). 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.
For sure, hopefully SIP _MUST_ be over TCP or TLS ;)
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).
Try to re-think a bit the whole thing. You come
to me with some examples
that are out of the purpose -- you try to demonstrate me that how SIP is
used now to do a voice call does not work for instant messaging session. You
are right, it doesn't, because that is for voice. But you can negotiate a
session that means exchange of MESSAGE requests (or if you like better a new
request type IM) within a dialog.
Yes, I agree. What you suggest could be really
useful for _small_ data
transfer (just small text messages). But, would you send a big AVI
file (50 MB) over SIP signalling? Imagine the user splitts it in 50
fragments of 1 MB and each fragment is carried within a new in-dialog
MESSAGE (as you suggested, and assuming there is some application
protocol to control de order of the chunks).
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). And also note that it supposes
very high network traffic sharing SIP messages. The spirit of separing
signalling and media is broken and, honestly, I don't like it even if
it "solves" or makes NAT handling easier (if so, let's use IAX rather
than SIP+RTP).
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. 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.
RTP is very good for its purpose and should stay the same. But MSRP
really looks like a poor hack to solve with bigger complexity an easier
task.
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),
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?).
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).
Further, you try to tell me that MESSAGE has no
notion of session, trying to
suggest that a new protocol (like MSRP) is a better approach than defining
the session for it (similar concept like for audio call dialog, preserve
call id, follow record routing). MSRP packets have headers like SIP, just a
bit fewer -- it is really bad design thinking of they could have reused sip
to specify IM sessions and file transfer.
Some points here:
1) MSRP is not so new (2007).
2) Your suggested new protocol would be newer than MSRP :) Overall, maybe
we have different understanding of simplicity.
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? :)