27 May
2011
27 May
'11
1:25 a.m.
On 5/26/11 11:41 PM, Iñaki Baz Castillo wrote:
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.
2011/5/26 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
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 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. 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). 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