On Sun, 4 Jan 2009, Iñaki Baz Castillo wrote:
2009/1/4 Juha Heinanen jh@tutpro.com: 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@aliax.net _______________________________________________ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users