SBC ad-hoc meeting notes Tuesday (7:00 - 9:00) Why ? Growing disconnect between IETF and market. SBCs have different behaviors and growing concern about Interworking. Black sheeps of IETF community. To make standards before its too late. Agenda : stay away from bashing SBCs and try to understand the requirements they are trying to solve. What are the problems that SBC solves today ? to create a background - point by Sridhar. Keith : What is a SBC ? Rosen: We will hear from people and its not going to be as simple as a proxy that looks at registration records and route calls. Karan : Good decision to have this meeting. SBC can be in different locations of network. So we have figure out requirements for all possible configurations. Rosen: Several ways to categorise the problem depending upon where they live. NNI Interface and UNI Interface are two places, from my ATM days. Brian has broken it into ...... . We can discuss them Jim@acme: Dealing with Tier 1. SBC is a combination of access control, topology hiding. Parameter control/Access control - ip access list to let voice calls comein/deny them. Hide toplogy using NAT. People won't wanna expose the ip address of resources - softswitches, media controller, proxies. Rosen: we want to get depth-first traversal of domain. Mahy: what's the business reqmt. For topology hiding. Ken Fischer: Even for trusted customer, logistics for sharing 4K - 3K ip addresses is nightmarish. We can narrow down the signaling aspects to a handful but they want media addresses for access list also. SBC is the only way. Its not just DOS attack. BT : We have got millions of customers and these ip address change every day. SBC helps control how much info has to flow upwards. Single address for trust network. Ben: Why do your customers need ip addresses in advace ? Ken : They configure access lists and these things change every day. Sridhar: Out experience, carriers lease services, they have to create trust boundary and Medhavi : Break down what is access control . They want to monitor - call rates, bandwidth, SLA management, .. all this is part of access control. Topology hiding has different meaning to different people. 3GPP has it. Serivce providers are looking deep inside the pkts and discard pkts which don't have right addres in right fields. Mahy: Different WGs have done source based filtering. Can we generalize the problem to a simple filtering problem. Ken: We can come up with some mechanism but that doesn't exist today. Mahy: We need clear picture of what all requirements are. Ken: Serivce providers may have SIP filtering. Cullen: What are the security policies that get executed based on what level in the network you are. BT guy: 3 levels - SLA policy level, Two networks, attic based service provider. Rosen: do you have any specific examples ? Voice: What is being managed ? BT : We are not managing services we are maintaining between networks. Dave: Are we worried about the end-2-middle security. Rosen: we are looking at middle - 2 - middle security. It's a board sense of security on application level something that two businesses agree upon. Ben: There are tiers and peers and I think we can generalize this to most of the things we talk about here. Authentication can be easily done for signaling. I am thinking tey are talking about media security. Rosen: TLS for security for signaling but media (RTP) does not have authentication scheme. Ken. AGREE. Karan: SBCs are implementing both signaling and media in same box. Someothers are implementing signaling and media in distributed. Can we have a standardized protocol. Rosen: out of scope. Karan: TE, TRanscoding, toplogy hiding, regulatory issues, security, billing and acct, Service delivery and performance monitoring. Rosen: out of scope. Medhavi: Different kind of policies SBCs execute - Via or From .. QoS - topology hiding - basic topology hiding. Full packet inspection for SLA for bw policing, CALEA. Woman: question to service providers. What is a session and why packet inspection for session based. Ken: RTP stream is valid between 2 endpoint only during session. Woman: May be there is a more general inspection you want to do. Ken: That may be a more general problem than we need to solve. Henry MCI: SBC is purely economic. Instead of putting in expenses... Cullen: Can we get more information about NAT Traversal. Medhavi: It's a short term solution. E.g. ICE, STUN. This is a stepping stone. Spencer: What is the scope of this converstation - is B2B UA part of this. Rosen: This is a sip technique. This is not a requirement for this and not in scope. Ricardo: What we are listening are excuses .. !!! Just because people want to have administrative control - RTP stream, signaling. SBC provide this control. We can come up the standards for these excuses for having the control. It's a waste . Francoise: We have similar requirements on Enterprise side. Get through Firewall with out breaking the security.I call it a funnel for getting the information to appropriate place. Issues with people who don't sippirt the protocol right. SBC provides a homogenous interface. Voice: Application routing toplogy different from ip routing technology. This is forcing topology. Roni: NAT Traversal can be hosted solution on network edge or CPE. Network hosted environment is much better it gives more policy control on service provider side. It causes problem - e.g. man in the middle, changing rtp payload. Bob: NaT Traversal can be deployed in 2 scenarios: SBC acting as NAT eg. In cable broadband network where the entire network is private address space. This allows for providing qos, bandwidth management. The ip routing can be done simply based on source of this SBC for DiffServ. Jim: Well trusted source for Layer 3 devices - service providers block out everybody except trusted addresses. Andrew: Medhavi: B2B UA. Only reason B2B UAs are used is for toplogy hiding. Kagoor: Parameter of a CO is a SIP aware firewall. SBCs can enforce CAC. Allen @Jasomi: SBCs sometimes have to do things which seem at odds with layer3 functionality. Layer 7 policy is enforced by SBCs. Roni : Media fusing for endpoints in the same private address space. Ben: Agree with Andrew comments of interacting with IT deptt for Firewall. Ed@Newport: Troubleshoot calls e.g. the call has oneway audio. Everything else other than SBC has no notion of call. Session admission control - SP want a capab of controlling how many and how much calls are coming from different networks and enterprises. Policing per session Rosen: 2833 are in teh application domain.Are you saying SBCs are providing applications. Ed: Don't want to limit how 2833 is being used. Sridhar: Service normalixation : older IADs send can not send 2833. Bob: Clarification of what Ed said Ed: UA sends digit (old) sends packets in RTP stream. SBC picks it up Voice: Why SBCs is trying to get these digits mucking with RTP stream. Bob: when 2 endpoints are IVR and endpoint. Rosen: SBS is not listening to media in the stream. Bob: yes. Woman: SBCs are controlling router. Bob: We are controlling routers but not installing BGP like information into Routers rther a policy fir preferential treatment. Medhavi: PAul: division of human responsibility problem .. more of a management of network is partitioned. Voice: there is a policy enforcement requirement and it can't be end to end because of peering relationship. Voice: Why are we ignoring RSVP. Rohan : Noi comments Medhavi: two parts of problem. RSVP is ok. AvShalom : SBC can be an imp tool for biling the call. It has control over media and signaling. Alan@Jasomi: Per session rate limiting - policing per session. Andrew: no trust for endpoints inside and points outside. Ben: Francoise: Is there anything that broken for SIP that we need to fix. Rosen: We understand the requirements, then we look at available solutions, what do we need to fix , what do we need to address from start, what tools and techniques are at dispocal. We have problems because - GRUU, identity. Andrew: QoS, NAT traversal, policing are some basic issues - can we summarize these Rosen: we won't be summarizing Mark: Things boil down to money. Field deployment makes sense with all these - normalization. The fact that these boxes exist, mean there is a demand. May be we should try to fix what they break Henry: There is not trust between service providers and SBC fill this gap. There are boxes that provide- web traffic, email filtering, SBC functionality. Woman: trying to understand what a SBC is and what is a tryst and what is point of control. Ken: Not just enforcement. Its customers that need CDRs to prove loss of service. Jim: QoS and reporting taling, CALEA, codec normalization - codec stripping. Codec based routing. Medhavi: Layer7 controlling Layer 2 CAC. Brian: Controller in SBC is really a monitor e.g. calling 4 days laters and bitch about service. Cullen: DTMF thing is a 3pcc type of thing that you can use with this SBC. Spence: Are we going to discuss problems people face because of B2B UA. Roni: SBC is like an end relay. Everything is hidden and relaying information from outside to inside. Voice: There is a grp that has handled how to monitor session. We should be looking into control aspects. Voice: Monitoring is a valid topic. Even when things are flying very well. Because you don't know until you get a sense of it. I am not sure if SBC is a part of solution. It introduces latency. Sridhar: People think SBCs are excuses and little check-off things. The problem we solve are normalization services, service availability. Voice: I have not understood what SBC is . Spanning multiple layers may not be a good idea in large networks. Rosen: out of scope. Ed@newport: VLAN-tagging is a key requirements. VPLS instead of point to point VPN and then try to inject SIP services into it. SBCs can do mapping etween DSCP bits and VLAN id. This is a hot requirement by service providers. Roni: SBC with endpoint behind a Firewall then SBC has to wait for the first packet Medhavi: No. of SBCs that Service Providers provide is per 1000 subscribers. Rosen: There are lot of things that happen at boundary - trust, control which are not yet covered in IETF and we need to collect requirements for that. Ben: Can we decide about future meetings. Rosen: we must. Henry: we do a lot of peering. At IP level you don't need cash exchange, trust. Etc. Internet already has a peering model. Voice does not have a peering model and that what we need. Rosen: let's touch upon Protocol repair. Cillen: Converting unecrypted signaling and unencrypted media into encrypted signaling and encrypted medua wll that be a protocol repair. Ben: Every vendor come up with proprietary solutions because they are following arcane drafts or revs. Alan: You do endup with these islands of single vendor boxes that don't interop. Mike: Is there signaling flow control built in the protocol. Rosen: its not and I don't think its just a parameter problem. Proposals: Let continue. Hone the documents into requirements. Input that to SIPPING. Analyze these requirements - do we have solutions, do we need something new, what we break - identity, GRUU. Dean: Lets do a survey of how people use SBC and how they help them. Requirements may be a premature step . Rosen: Fair point. Camarillo: we will announce the new home for these requirements. Karan@sprint: Can we have a voice over IP peering group like this one also. It will be helpful for us a service provider. Spencer: we need to freeze the terminology. A lots of terms have been coming in. Topology hiding. Doing CAC on border.