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

[Daniel-Constantin Mierla]

Inaki,

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.

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. That is session 
negotiation and that is the purpose of SIP. Btw, you can force TCP if 
you answer 200ok with a TCP address, moreover, TCP is mandatory in SIP 
2.0 - bad implementations does not mean bad protocol.

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.

Overall, maybe we have different understanding of simplicity.

Cheers,
Daniel

On 5/26/11 2:39 PM, Iñaki Baz Castillo wrote:
> 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.
>
>

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