200 likes | 293 Views
Integrating SIP and Legacy PBXs. Henning Schulzrinne Dept. of Computer Science Columbia University. Overview. Motivation Migration strategy Challenges Example: Columbia Dept. of CS Scaling Emergency calls. Motivation. Allow migration of enterprises to IP multimedia communication
E N D
Integrating SIP and Legacy PBXs Henning Schulzrinne Dept. of Computer Science Columbia University
Overview • Motivation • Migration strategy • Challenges • Example: Columbia Dept. of CS • Scaling • Emergency calls
Motivation • Allow migration of enterprises to IP multimedia communication • Add capacity to existing PBX, without upgrade • Allow both • IP centrex: hosted by carrier • “PBX”-style: locally hosted • Unlike classical centrex, transition can be done transparently
Motivation • Not cheaper phone calls • Single number, follow-me – even for analog phone users • Integration of presence • person already busy – better than callback • physical environment (IR sensors) • Integration of IM • no need to look up IM address • missed calls become IMs • move immediately to voice if IM too tedious
Motivation • Cheaper wiring • with Ethernet power, no need for power brick • Flexible allotment of ports, without fixed RJ-11/RJ-45 boundary • No growth steps
Motivation • CTI never really worked • Used only for call centers, now for everyone • Integrate phone and PC: • PC shows web page and photo of caller • PC shows call history • No more: “And what’s your email address?”
Migration strategy • Add IP phones to existing PBX or Centrex system – PBX as gateway • Initial investment: $2k for gateway • Add multimedia capabilities: PCs, dedicated video servers • “Reverse” PBX: replace PSTN connection with SIP/IP connection to carrier • Retire PSTN phones
Implementation difficulties • Integration with PBX • typically, treat as adjunct • T1 PRI (much better!) or CAS • T1’s have dozens of configuration combinations • AMI or B8ZS, SF or ESF, DID or TIE, voice/data, … • two-stage dialing vs. DID • caller ID typically doesn’t work • peculiar notions of privileges (caller + callee) • arcane commands, undocumented • Voicemail integration • message deposit and retrieval • message-waiting light
Example: Columbia Dept. of CS • About 100 analog phones on small PBX • DID • no voicemail • T1 to local carrier • Added small gateway and T1 trunk • Call to 7134 becomes sip:7134@cs • Ethernet phones, soft phones and conference room • CINEMA set of servers, running on 1U rackmount server
CINEMA components Cisco 7960 MySQL sipconf rtspd user database LDAP server plug'n'sip RTSP conferencing media server server (MCU) wireless sipd 802.11b RTSP proxy/redirect server unified messaging server Pingtel sipum Nortel Cisco Meridian 2600 VoiceXML PBX server T1 T1 SIP sipvxml PhoneJack interface sipc SIP-H.323 converter sip-h323
Experiences • Need flexible name mapping • Alice.Cueba@cs alice@cs • sources: database, LDAP, sendmail aliases, … • Automatic import of user accounts: • In university, thousands each September • /etc/passwd • LDAP, ActiveDirectory, … • much easier than most closed PBXs • Integrate with Ethernet phone configuration • often, bunch of tftp files • Integrate with RADIUS accounting
Experiences • Password integration difficult • Digest needs plain-text, not hashed • Different user classes: students, faculty, admin, guests, … • Who pays if call is forwarded/proxied? • authentication and billing behavior of PBX and SIP system may differ • but much better real-time rating
Dialplans • Can be implemented in phone or proxy • timeout or explicit termination • canonicalize first, then find route • some may go PSTN, some IP • may depend on who’s making the call • map to tel URLs or SIP URLs • tel: translate at first proxy • tel:212-939-7040 • sip: provide translation entity • sip:212-939-7040@sip-provider.biz 7[01]?? tel:+1212939$ (011)* tel:+$ ??????? tel:+1212$ (8)1?????????? tel:+1$ (8)(011)* tel:+$
Likely problems elsewhere • NATs • prevent inbound calls • make outbound UDP iffy • Low access bandwidth • need voice (UDP) prioritization • most IP phones support DSCP • possibly smaller MTU needed
Small gateways are dumb • No notion of users, passwords or authentication, accounting, … • Thus, proxy needs to provide this • But: avoid bypass – users could talk to gateway directly and bypass pesky billing and authentication • Use built-in firewall and IP restrictions
Emergency calls common emergency identifier: sos@domain EPAD REGISTER sip:sos Location: 07605 302 Moved Contact: sip:sos@psap.leonia.nj.us Contact: tel:+1-201-911-1234 SIP proxy INVITE sip:sos Location: 07605 INVITE sip:sos@psap.leonia.nj.us Location: 07605
Scaling and redundancy • Single host can handle 10-100 calls + registrations/second 18,000-180,000 users • 1 call, 1 registration/hour • Conference server: about 50 small conferences or large conference with 100 users • For larger system and redundancy, replicate proxy server
Scaling and redundancy • DNS SRV records allow static load balancing and fail-over • but failed systems increase call setup delay • can also use IP address “stealing” to mask failed systems, as long as load < 50% • Still need common database • can separate REGISTER • make rest read-only
Large system stateless proxies sip1.example.com a1.example.com a2.example.com sip2.example.com sip:bob@example.com b1.example.com sip:bob@b.example.com sip3.example.com b2.example.com _sip._udp SRV 0 0 b1.example.com 0 0 b2.example.com _sip._udp SRV 0 0 sip1.example.com 0 0 sip2.example.com 0 0 sip3.example.com
Conclusions • VoIP with SIP attractive for upgrading PBXs • Add-on functions benefit even analog users • No feature difference between large and small installations • Adding gateway to PBX painful • PBX IP interfaces likely easier • Complete integration is difficult (voicemail)