[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>:

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

INVITE exists for negotiating a session. Which session is being negociated here?
Even within the ÏNVITE dialog, how do you correlate received MESSAGE's? i.e:

I send 4 MESSAGE's:

1) Hello
2) Daniel
3) How
4) are you?

Message 3 is lost in some UDP path, so you receive:

  "Hello Daniel are you?"

and later (retransmissions):

  "How"

If you want to solve it, you would add ugly contrains to SIP
signalling protocol.


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

UDP is good for audio/video transmission. I don't think any other kind
of information is reliably sent via UDP/RTP. But maybe I'm wrong. I
would like to know how a big file is transferred via RTP.


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

As explained before, using CSeq for that is wrong. If I send you 4
in-dialog request (having my initial INVITE CSeq 1) these requests can
have:

1) CSeq: 2
2) CSeq: 33
3) CSeq: 1000
4) CSeq: 999999

And they are valid. If you (UAS) receive the third in-dialog request
with CSeq 1000 you have no way to know if the network has lost any
previous message(s) (after second request with CSeq 33) or not. CSeq
cannot be used to sync application data on top of the signalling
within a dialog.


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

No, but XMPP has the concept of IM session. SIP MESSAGE has not.



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

Already justified that it is not suitable (IMHO).



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

Of course. 99% of existing SIP implementations just speak SIP and have
done mostly nothing for IM. Does it mean that they deserve a good IM
system without implementing nothing?



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

The very same as a RtpProxy server.



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

You cannot expect that during a dialog any kind of in-dialog request
should not be sent. If the UA implements SessionTimers it must
periodically send re-INVITE or UPDATE. If you put on-hold the peer,
you send an INVITE, maybe an INFO for DTMF (even if it's not a
standard). You cannot add such a constrain in the CSeq value. CSeq
value belongs to SIP signalling layer, while a IM session (as a RTP
session) belongs to core/application layer.



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

If you have 100 000 000 customers you could also need 10 000 RtpProxy
servers. Different kind of media sessions (RTP is UDP while MSRP is
TLS) so different kind of relay servers. I don't see the difference.


Cheers.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>