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