[sr-dev] RFC 5626 (Outbound) planned?

Jon Bonilla (Manwe) manwe at aholab.ehu.es
Tue Oct 11 14:55:08 CEST 2011


El Tue, 11 Oct 2011 14:30:49 +0200
Iñaki Baz Castillo <ibc at aliax.net> escribió:

> 
> SBCs exist because they offer "some services" like for example... hum?
> and due the fact that no vendor implements SIP security at all.
>

b2buas are not really defined so they can be intrusive and bad or a good thing
depending on what you need. In my experience, my company's product could not
provide some cool features to our customers without a b2bua as sems.

For me, it offers topoh hiding, response mapping, codec filtering, session
timers, some accounting stuff, session duration limit and some sbc
capabilities. I agree that I would like to see the inteligence at endpoint
level but that's not true life. So yes, b2buas are necesary for me at this
point. 

You're talking about SIP on the web, where it does not exist at the moment.
Nowadays, SIP exists in telcos' wallet gardens and in companies' PBX systems. If
SIP will expand to the internet at some point, it will/should do from where
it's now (telcos) and not from scratch.

 
> We need cool features in clients and proxies:
> 

Agree but some comments out here:

> - ICE (RFC 5245): The best solution for NAT, validation of the peer
> (who is sending RTP to me?) and IPv4/IPv6 transition.
> 

As Ole mentioned and I discussed with him last week, ICE may break LI (lawful
interception) requirements for some vendors. It needs some switch to be able to
disable it when LI is required.


> - Outbound (RFC 5626): The ellegant solution for TCP/TLS clients
> behind NAT. No hacks.
> 
> - GRUU (RFC 5627): Required for setting in your "Contact" something
> really reachable by others (rather than your private IP). Problems
> sending a REFER? GRUU is the solution.
> 
> - SRTP (RFC 3711): Why are we so happy with unencrypted audio/video media??
> 

Because we're in closed networks. This is becoming more important each day as
federation, internet users and mobile device users come to the SIP world. The
TLS and SRTP/ZRTP requirements from my customers has increased this year 1000%

> - SIP over TLS: But it needs to be reworked as the current spec sucks!
> 
> 
> Let's open SIP to Internet, but for that it must work and it must be *safe*.
> 

Open SIP to the internet. Yes. Open which is already in place. SIP in internet
from scratch is a no go. Google talk, Skype and Facebook (with Skype
integration or whatever) have thousands of millions of users in advantage. But
if you start opening the wallet gardens, you'll start with millions of users
that don't know they already use SIP and corporate customers which means money
behind the protocol. You need to play poker with the cards you've been given. 

Must work: yes. I would drop the whole SIMPLE specification (all the RFCs) to
have some really functional. As it is now we won't have any compatible
federated presence mechanism ever.

Must be safe: Agree. No doubts here.


btw: This is becoming a mayor OT for this list, isn't it?




cheers,

Jon




More information about the sr-dev mailing list