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

[Iñaki Baz Castillo]

2011/5/26 Daniel-Constantin Mierla <miconda at 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".



>> 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 at aliax.net>