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