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

[Daniel-Constantin Mierla]

Hello,

On 5/26/11 12:19 PM, Iñaki Baz Castillo wrote:
> 2011/5/26 Daniel-Constantin Mierla<miconda at gmail.com>:
>> on the other hand, I think MSRP didn't bring much value, just another type
>> of stream out of signaling channel. I am not that familiar with MSRP to know
>> really if there are real benefits, but sending instant messaging over SIP
>> was there from beginning and rather simple without other components that
>> introduce new points of failure.
> Daniel, I strongly don't agree here. If  you state that SIP MESSAGE is
> a good way of instant messaging I must say that SIP MESSAGE is as
> limited as a mobile SMS and a complete hack if we try to use it as
> real IM. If I send a MESSAGE to bob, he will receive it in every
> device it holds (parallel forking), regardless which device he uses to
> reply my messages. There is no "session of messages" (as there is in
> MSRP, XMPP, MSN, Skype or whatever decent IM protocol).
for veterans here, we know it was a proposal (maybe is a rfc now) where 
INVITE was used to establish the IM session and them MESSAGE requests to 
carry the IMs. At least M$ Windows Messenger implemented it in some 
versions.

I think that is far more better approach, as it solves firewall issues 
with yet another port and relaying. Just straightforward and simply 
works, no new nodes in the core network to care about HA, scalability & 
stuff.
>
> Also, don't forget that MSRP also allows file transfer along with
> future extensions (desktop sharing?).
Desktop sharing works now with RTP (jitsi has it) -- you can think of 
image/video transmission. For file transfer I expressed my opinion as a 
potential easy mechanism: invite-200ok-ack then what-so-ever SIPr equest 
carrying the chunks, synchronized by cseq, then bye.

Since you named some protocols, does XMPP use out of band channels for IM?

A SIP network got too heavy, too many entities in the core network, the 
sip router, the rtp relay, the IM relay a.s.o... while it is not really 
needed more than 2.
>
> MSRP is the normal procedure for message sessions in SIP. SIP uses a
> media stream for audio and video, using a new media stream for IM (and
> file transfer) is the correct aproach (IMHO) and fits very well with
> SIP protocol concept and existing deployments.
It fits with the concept of making SIP network heavy and hard to manage, 
it simply adds complexity for no real benefit. SIP has the capability to 
carry payloads -- like IM is. If you don't want pager mode for IM, start 
a session with INVITE, then send MESSAGEs and you are set.

>
> I do know about MSRP implementations and they work very well. The
> protocol itself (which I'm implementing right now

Here is a problem: you are implementing it -- that means time and money, 
for the SIP in-band the implementation requirements does not exist in 
the core network and the endpoints have all the components already in 
place, so it will be quite trivial (e.g.,session management with invite, 
sending sip requests).
> ) is quite easy (just
> 3 RFC's), it assumes NAT exists so defines MSRP relays (RFC 4976). I'm
> also coding a MSRP relay server.
>
> MSRP is the only good added value to SIP (IMHO).
Another point of failure is not good at all, is very bad.

>   Even if it's designed
> by SIMPLE WG, I strongly would like to separate it from SIMPLE
> PRESENCE (a full pain). It's much simpler and it's well designed.
>
>
>> Reducing the number of optional headers will make the messages also quite
>> small. As for path optimization, initial request creating the dialog could
>> get only record-routes from the SIP hops that are intended to stay in the
>> path (like the relay).
> There is no SIP dialog for MESSAGE request, so record-route doesn't
> apply. If it was exist, there should be needed a way to finish the
> dialog (a BYE?, a MESSAGE with a custom header "Terminate-IM: yes"?).
> MESSAGE requests are like individual SMS's in mobile world.
>
>
>> For file transfer,  clunking the content and sending over several requests
>> (again with minimum number of headers) with proper cseq incrementation will
>> be a straightforward implementation.
> I don't agree. You are mixing signalling indicators (CSeq) que
> application data indicators (message offset). Any CSeq greater than a
> previous one is valid (even if it's 100 times greater).

So you look to define a new protocol instead of setting a constraint for 
a specific case?

Have in mind that what I said is not specified, but it is (IMO) a much 
simpler approach for everyone. So don't argue against me with what is 
potentially valid in SIP right now. I know them, they can just be more 
specific for particular case.

>   The UAS could
> never know wheter some other requests have been lost so it has no
> information enough to reconstruct the whole message.
>
> Also, you would send the file to all the UAS's in which the
> destination user is registered.
>
> In MSRP I send an INVITE with SDP containing MSRP to bob. He receives
> the INVITE in his computer and mobile. He decides to answer/accept it
> in his computer. Then I have a real IM session with him jsut between
> my device and his computer.
>
>
>> SIP can be used in very simple ways, without new types of protocols and
>> communication channels...
> You know I agree with this statement for other kind of communications,
> but not in case of IM. MSRP is the way to go, it's cool, it's already
> defined (you are propossing a new specification in your mail) and it
> works ok.
>
>
> Best regards.
>
>
> PS: It's sad that just a very few softphones/UA's implement MSRP,
That's because it does not worth the time. The model is not really 
bringing benefits, is just another fantasy.

Honestly I could think of just few restrictions/amendments/additions to 
the base SIP RFC3261 and the next 10 following it to have very good and 
simple model for im, presence, file transfer, desktop sharing a.s.o.

Think about 100 000 000 customers where you need 10 000 media relays, i 
should add 10 000 IM relays? Good for vendors, they sell, bad for 
operations and quality of service. Really, that's it, period.

>   but
> that doesn't mean that using MESSAGE is the way to go.
>

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda