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

[Daniel-Constantin Mierla]

On 5/26/11 11:41 PM, Iñaki Baz Castillo wrote:
> 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).
SIP over TCP with payload.


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

Amazing, you found an example and it is again about voice/video! You 
believe that SIP is only for those kind of communications. Btw, maybe 
you know that rtp proxy can do re-sampling to avoid congestion.


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

By initial design, sip is an end-to-end communication model. Forget 
about record routing and see how the requests are flowing within dialog.

> Honestly I like the concept of "signalling through intermediaries and
> media sessions end-to-end".

What keeps me to have a session negotiation of MESSAGE requests to be 
sent from point A to point B?

Again, I think you haven't understood my point. MSRP defines a new 
protocol, that is barely different than SIP. From MSRP RFC, here is the 
very basic example:

    MSRP a786hjs2 SEND
    To-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
    From-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
    Message-ID: 87652491
    Byte-Range: 1-25/25
    Content-Type: text/plain

    Hey Bob, are you there?
    -------a786hjs2$

    MSRP a786hjs2 200 OK
    To-Path: msrp://atlanta.example.com:7654/jshA7weztas;tcp
    From-Path: msrp://biloxi.example.com:12763/kjhd37s2s20w2a;tcp
    -------a786hjs2$


What is the benefit over all, just a bit fewer headers, but more or less the same format as SIP messages.
Maybe it saves a bit of bandwidth (hey there is SIP compession for that :-) ), but then new points of failure
are added in the core network unnecessary. Such nodes need to keep states, if they crash communication drops
(like with rtp relays). It is not the case with pure sip.

I just looked quickly to some of msrp rfcs, it is practically yet 
another sip-like protocol: they defiles paths set for the case of
many msrp relays (would that be like record-routing mechanism -- don't 
take it literally and come back to me saying r-r has
a different purpose for audio sessions), authentication with digest, 
a.s.o. Really funny!!

I am more sure now that is really poor solution, no benefits, no 
effective gain.

It is time to stop here with the discussion, you loop back with out of 
the context examples and I don't think you got my idea: session is 
negotiated with invite-200ok-ack. The content is carried via SIP 
(end-to-end or relayed through intermediate node when necessary) and 
session terminated with bye-200ok. Simple as that -- when relay is 
necessary, a sip proxy can do really good job in terms of performances, 
no need to reinvent the wheel and have different applications in the 
network.

Cheers,
Daniel

[...]

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