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

[Iñaki Baz Castillo]

2011/5/27 Daniel-Constantin Mierla <miconda at gmail.com>:
>> 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.

Perhaps I didn't explain well. I mean that, in the case of
audio/video, the proxy does not add constrain to the media
negotiation, neither it imposes limitations in the data size (as the
data is carried over a different transport, in this case RTP).

But what you are suggesting is that other kind of media (as IM or file
transfer) could share signalling stream. In the example of file
transfer carried within chunks in MESSAGE body, you said that the
proxy could mandate a minimum/maximun data size. So in this case the
proxy takes active part in such media transmission.

Below I reply yo your suggestion of non using record-routing.




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

So you propose pure SIP transport for carrying data arguing that is
makes NAT/firewall scenarios easy, and now you suggest not using
record-routing which is, in fact, the reason SIP (signalling) can work
even if both endpoints are behind NAT. IMHO we all know that
record-routing is a MUST in any real scenario.


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

NAT. And STUN/ICE doesn't help here as TCP/TLS is supossed to be used
to carry big data in SIP message bodies.



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

Right, I agree. But I still think that media (I don't mean audio/video
now) should take a different path than the signalling. Name me radical
:)


> 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 can agree that there is too much stuff in MSRP protocol, but IMHO
people defining it has learnt the leasson of RFC 3261 (too much
flexibility). MSRP is much more specific, it mandates TLS (yes or yes)
and covers NAT scenarios from the beggining. Of course, non
implementing MSRP is still easier than implementing it :)




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

I like discussions as they are the best way to learn from other people :)

Obviously we don't agree but I will have in mind your opinion.


Cheers.

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