[SR-Users] [OT] IETF SIMPLE WG will destroy MSRP with the new draft-ietf-simple-msrp-sessmatch-11

[Daniel-Constantin Mierla]

On 5/26/11 6:41 PM, Iñaki Baz Castillo wrote:
> 2011/5/26 Daniel-Constantin Mierla<miconda at gmail.com>:
>> 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).
Desktop sharing is streaming of screenshots taken with frequency like it 
is video with images taken with a frequency from camera ...
> 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 ;)
>
>
>> 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).
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).


>   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).
>
>
>> 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 :)
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).

>> 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? :)
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