1 / 20

Using Open Source SIP to provide PBX-equivalent telephony features

Using Open Source SIP to provide PBX-equivalent telephony features. Alan Crosswell < alan@columbia.edu > TIP2008 - 22 January 2008. Couldn't have done any of this without help from our friends (and vendors). University of Pennsylvania Started with their SER cfg and web provisioning tool

Download Presentation

Using Open Source SIP to provide PBX-equivalent telephony features

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Using Open Source SIP to provide PBX-equivalent telephony features Alan Crosswell <alan@columbia.edu> TIP2008 - 22 January 2008

  2. Couldn't have done any of this without help from our friends (and vendors) University of Pennsylvania Started with their SER cfg and web provisioning tool University of North Carolina Chapel Hill MIT OpenSER developers and users special thanks to Anca Vamanu who wrote the PUA_BLA module Voice-System SRL Internet2 PIC, SIP.edu and VoIP working groups First learned about SER and used the SIP.edu cookbook Polycom Cisco

  3. NetPhone Voice over IP service inStudebaker Building First “new” building on new Manhattanville campus First step in replacing 20,000 obsolete ROLM PBX phones at 12 sites 700 users are administrative staff in IT, Finance and HR departments including senior VPs PBX-equivalent phone service with some difficult (for SIP) “business” features: Bridged/Shared Line Appearance Directed/Group Call Pickup Compatibility/interop with existing PBX dial plan

  4. Converged IP Network Applications Physical access control Surveillance cameras Intrusion & fire systems monitoring HVAC monitoring Electric meters NetPhone Voice over IP service

  5. Survivable IP Network L1 Diverse outside fiber routes – ring via Broadway & 12th Ave Diverse in-building vertical riser fiber ring Dual power supplies, dual UPS Diesel generator PoE for phones, cameras, WiFi APs L2/L3 Dual switch uplinks w/HSRP 802.1q voice VLAN (learned via CDP) protected by ACLs (port 5060) POTS lines for emergency backup “just in case” Digital Centrex – same dial plan

  6. CU NetPhone Feature Summary (1/2) Multiple line appearances Bridged lines Privacy Multiple “Stacked” lines per registration Call Waiting Caller & Called number & name display Speaker Headset Cordless Headset Mute Hold Transfer – Consultative & Blind Call Forward Always/Busy/No Answer Do Not Disturb Redial Call Return Call Log Buzz Intercom Intercom groups Hunt groups Call Park/Pickup Directed/Group Call pickup Message Waiting Indicator Conference Speed Dial Distinctive Ring Personal Security Codes DTMF passthru

  7. CU NetPhone Feature Summary (2/2) Anonymous Call Reject Anonymous Calling Restricted Calling Conference Bridge Analog Lines Fax Voicemail as email Voicemail forwarding Voicemail broadcast Voicemail distribution groups Voicemail referral extension Automatic Call Distribution E911 Improvements over current PBX: Call Waiting Multiple Lines per Registration Call Log Redial Voicemail as Email Web settings (my NetPhone)

  8. OpenSER – Open SIP Express Router www.openser.org branch of SER (www.iptel.org) SIP Proxy, Registrar, Location Server, etc. Modular add-ins for features like Presence Automatic tracking of SIP session state Scripting language permits customization to implement, e.g.: dial plans (R-URI rewriting & forwarding) permissions selective editing of SIP requests/response headers, SDP, etc. Does not handle media – use Asterisk.

  9. Easy: Adding Called Name Display w/OpenSERPolycom UA dials x12345 and the display shows name of called party F1: INVITE sip:12345@sip.columbia.edu F2: 180 Ringing Remote-Party-ID: “Jane Doe” <12345@...>

  10. Easy: Adding Called Name Display w/OpenSER route[2] { ... if (is_method(“INVITE”)) { if (avp_db_query(“select name from subscriber where username=$rU”,”$avp(callee)”)) { ...} ... t_on_reply(“2”) } } onreply_route[2] { if (t_check_status("180|183")) { append_hf("Remote-Party-ID: \"$avp(callee)\" <$tu>\r\n","To"); } }

  11. Difficult: Bridged/Shared Line Appearance Two or more phones all with the same “extension” number, like a key system. In-use LED goes on for all phones when one phone is taken “off hook” (before dialing, that is no INVITE or response to INVITE generated yet). Off when phone is hung up (put “on hook”) even if never dialed (BYE, CANCEL or response never generated). Flashing LED on all phones when call is on hold. Can put a call on hold on phone A and pick up from phone B “Sylantro” spec in draft-anil-sipping-bla-02.txt (expired:-( Uses RFC3265 SUBSCRIBE/NOTIFY RFC4235 “dialog” event package RFC3680 “reg” event package

  12. Subscribing to Bridged Line Appearance Presence State Phone REGISTERs with Proxy. Proxy notifies Presence User Agent (PUA) of registration. PUA SUBSCRIBEs to dialog state of Phone's Contact address (sip:12345@1.1.1.1) Phone SUBSCRIBEs to dialog state of Address of Record (AOR) (sip:12345@sip.columbia.edu) repeat for each additional bridged phone. if (is_method(“REGISTER”)) { ... bla_set_flag(); } # causes PUA_BLA module to SUBSCRIBE to phone's dialog state.

  13. Phone A REGISTERs REGISTER 12345@sip... AORSubscriber Proxy PUA SUBSCRIBE 12345@1.1.1.1 12345 1.1.1.1 SUBSCRIBE 12345@sip... 12345 2.2.2.2 . . . . . . SUBSCRIBE 12345@1.1.1.1 REGISTER 12345@sip... SUBSCRIBE 12345@sip... Phone A 12345 1.1.1.1 Phone B 12345 2.2.2.2 Phone C 54321 3.3.3.3

  14. Taking the phone off-hook and lighting all the LEDs Phone A goes off-hook. Lights the LED. Sends NOTIFY to subscriber for sip:12345@1.1.1.1 (PUA) PUA links this NOTIFY to subscriptions for AOR sip:12345@sip.... PUA sends NOTIFY to all subscribers (phone B, C, etc.) Each of phone B, C, etc. turns on the LED. if (is_method("NOTIFY")) { if (bla_handle_notify()) { t_reply("200", "OK"); } else { t_reply("404", "Not found (BLA notify)"); }

  15. Phone A NOTIFYs AORSubscriber Proxy PUA NOTIFY 12345@sip... 12345 1.1.1.1 NOTIFY 12345@2.2.2.2<1.1.1.1> 12345 2.2.2.2 NOTIFY 12345@sip... NOTIFY 12345@2.2.2.2<1.1.1.1> Phone A 12345 1.1.1.1 Phone B 12345 2.2.2.2 Phone C 54321 3.3.3.3

  16. A sample NOTIFY showing an in-process dialog Request-Line: NOTIFY sip:43754@160.39.13.60 SIP/2.0 Message Header To: sip:43754@sip.columbia.edu;tag=CCDC9552-8F1034B3 From: sip:43754@128.59.59.209;tag=10.3248.1200076508.54840 CSeq: 391 NOTIFY Call-ID: 65e4925f-26d9fb68-e2d934f9@160.39.13.60 Content-Type: application/dialog-info+xml Message body <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1965" state="partial” entity="sip:43754@sip.columbia.edu"> <dialog id="id890b80b6" call-id="742ac461-dd947a5e-66e3d467@160.39.13.54" local-tag="7BA0524C-E77B349D" remote-tag="D9C54928-13DD" direction="initiator"> <state>confirmed</state> <local><target uri="sip:43754@sip.columbia.edu"> <param pname="x-line-id" pval="0"/> <param pname="+sip.rendering" pval="yes"/> </target> </local> <remote> <identity>sip:42428@128.59.0.13:5060</identity> <target uri="sip:42428@128.59.0.13:5060"> </target> </remote> </dialog> </dialog-info>

  17. Moving an on-hold call from Phone A to Phone B Phone C calls Phone A and is put on hold. NOTIFY sent to PUA. This includes unique dialog identifier. “hold” SDP sent to Phone C to stop the media. All that other stuff happens to make the LEDs blink on all other phones. Phone B goes off-hook to seize the on-hold call. In addition to all the Presence NOTIFYs, Phone B: Sends a CANCEL to Phone A Sends a re-INVITE with Replaces header to Phone C. This includes all the SDP negotiation to establish the new media path.

  18. A sample Re-INVITE w/Replaces Request-Line: INVITE sip:42428@128.59.0.14:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 160.39.13.60;branch=z9hG4bK4dc4feb71C2C7080 From: "Alan Crosswell" <sip:43754@sip.columbia.edu>;tag=B2E6BFBD-768BFF36 To: <sip:42428@128.59.0.14:5060> CSeq: 2 INVITE Call-ID: 9a763902-fe7901e3-21c9200c@160.39.13.60 Contact: <sip:43754@160.39.13.60> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY, PRACK, UPDATE, REFER User-Agent: PolycomSoundPointIP-SPIP_650-UA/2.2.2.0084 Supported: 100rel,replaces Allow-Events: talk,hold,conference P-Preferred-Identity: <sip:43754@sip.columbia.edu> Replaces: 21b89a66-f40d44f-20ad3294@160.39.13.54;to-tag=10377D0-1E51; from-tag=2868F3C5-BF031C32 Proxy-Authorization: ... Max-Forwards: 70 Content-Type: application/sdp Content-Length: 273 ...

  19. Simple! Iff your UAs implement the Sylantro stuff for BLA At least it's a published spec! Iff your UAs implement Re-INVITE w/Replaces header What happens when Phone C is coming in from the legacy PBX? It happens to work since Cisco media GWs implement Replaces. But BLA can't be implemented across the PBX/SIP boundary (notwithstanding some IOS bugs:-) What happens when Phone C is coming in from an ITSP? Sometimes works... The moral of the story: There are too many ways to do the same thing in SIP and too many optional features to make this stuff work across multi-vendor systems. Hence, recent formation of the IETF BLISS working group.

More Related