Well, you could use SIP to establish a TLS "media session" e2e (using
comedia). Then you could put another SIP session through it.
Paul
Dan Wing wrote:
Dan Wing wrote:
Elwell, John wrote:
Which would be ideal, if we were sure of getting them
through service providers unchanged.
Therein lies the conundrum with intermediate manglers like B2BUA's
and mailing lists managers, etc.
It is the conundrum for the entire Internet -- TCP 'protocol
scrubbers' exist, TCP options get dropped, DSCP bits get changed,
ECN bits are mangled, and Router Alert Option gets dropped.
Yet IPsec and TLS still work most of the time. Sticking a b2bua into
a stream is fundamentally different than routers and
scrubbers, etc. Their
job is to change the very things you want to protect. Either
you get to the
"break it/own it" or tunnel it across manglers. Anything else
is eating
caking and having it to.
Has any one proposed tunneling SIP in SIP? Ie, the manglers get to
set up their rendezvous ("because they simply must") and then the
ends get to set up theirs? This is one way the real world
routes around
damage too.
Yes, http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01. But
that only gives encrypted SIP signaling end-to-end -- it does not
cause a firewall or SBC or B2BUA to open its permission for the
RTP flow. A firewall or SBC will only open permissions for a
flow it knows about: that is their primary purpose.
-d
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
