On Sun, 4 Jan 2009, Iñaki Baz Castillo wrote:
2009/1/4 Juha
Heinanen <jh(a)tutpro.com>om>:
Iñaki Baz Castillo writes:
- Forcing RTP through a media proxy which
involves SDP rewritting by
the SIP proxy (so SDP cannot be encrypted).
forcing sip through proxies means that headers cannot be encrypted. i
fail to see a big difference.
Well, it shouldn't be required that a SIP proxy inspects the message
*body* in order communication to work.
Also, just a few headers needs to be readable by proxies. If I
remember well, SIP tunnelling with S/MIME usage allows encrypting some
headers and the entire body while the proxy still can read the
required headers (anyway, I hate concepts as "S/MIME" in SIP even if
it appears in lots of RFC's and drafts since it's obvious it doesn't
success).
My 2 cents to the discussion:
The obvious advantage are that if you have an encrypted copy
of SDP and To/From header AND a readable copy of To/From header
in the same message:
* the target endpoint is the only one to decrypt the SDP
* the target endpoint can be sure no proxy have modified the
To/From identity of the caller.
I agree S/MIME is not well accepted -same for mail- but
this feature will be possible with other technology.
However, what I mean is that rewritting the SDP is
something "dirty",
don't you agree?
I do! ;)
Good to hear that...
Unfortunatelly all of us are used to SIP scenarios in
which the
proxies rewrite the "Contact" header and the SDP. I consider it as a
needed hack, but nothing ellegant. If ICE and Turn can offer here an
ellegant and clean solution then they are really welcome.
It will!
Elegant & clean and when deployed on behave-compliant IP network, you
don't even need TURN... and ICE becomes fairly simple.
- The only case in which the media proxy can be
avoided is that in
which both the caller and callee use STUN (no symmetric NAT) or are
behind same public IP.
the above is not true.
Ok, I simplified too much. Other cases:
- One of the endpoints has public IP and supports Comedia mode.
- One of the endpoints has public IP and the other is behind non
symmetric NAT using STUN.
AFAIK there are no more cases in which the caller and/or callee are
behind NAT but a media proxy is not required, are there?
The problem with this is that the decision about endpoints are not
100% true:
* what about redirection?
* what about case where you have several proxy?
* What if the endpoint is detected as a non-symmetric NAT (most
probably, you detect this on SIP signalling port.) but becomes
symmetric on the RTP port?
ICE don't need to know where you are on the internet: it just work.
It's also capable of doing TCP/TLS connection to the TURN server
to tunnel UDP data for NAT configured to block UDP...
Aymeric
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
_______________________________________________
Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users