THE TYRANNY OF SIP INTEROP. Mark R Lindsey ECG.co

Transcription

1 THE TYRANNY OF SIP INTEROP Mark R Lindsey ECG.co

2 ACTIVE MONTHLY USERS 1.44 BILLION MAJOR SOFTWARE UPDATES 730 PER YEAR

3 20% OF USERS RUNNING OS WITH NO BUG FIXES AVAILABLE

4 VOICE IS OUT OF STEP WITH THE INTERNET WAY OF DOING THINGS

5 THE ORIGIN OF SIP IDEALS INVITE ing device negotiates capabilities with the receiving device during session setup.

6

7 1970s-grade Audio: YES! Ringback: YES! o Caller ID: NO o DTMF: NO BUT WHO CARES! VoIP = TALK FOR FREE!

8

9

10 END TO END A TECHNOLOGY IDEAL THAT ACTUALLY WORKS Requires Supported Event Packages Codec Negotiation

11 CUSTOMERS DON T EXPECT A DYNAMIC EXPERIENCE

12

13 CUSTOMERS DEMAND CONSISTENT FEATURES

14 CONSISTENT FEATURES + END-TO-END NEGOTIATION = HEAVY INTEROP TESTING N*(N-1) BILATERAL INTEROP POSSIBILITIES, N DISTINCT ENDPOINT TYPES OR SOFTWARE REVISIONS

15

16

17

18 YOU CAN T GUARANTEE INTEROPERABILITY WITH THE UNIVERSE

19 SO WE BUILD WALLED- GARDENS WITH DEFINED INTERFACES

20

21 PLANTING NEW FLOWERS IN THE GARDEN IS STILL TOO HARD

22 DRUMBEAT OF INTEROP MARCHING ON 3GPP (IMS) Standards give very broad latitude, little detail, 2011 No operator-tooperator test plans, 2011 Lots of ways of doing encrypted VoIP, but no consensus, 2012 RFC3261 splitting into dialects called profiles, 2011 Interoperability is a database of SBC configuration hacks, 2011 Compliance Testing focused on MUST requirements, 2012 SHOULD vs MUST a source of problems, 2013 Certification Testing, digitally signed reports, 2014

23 THE SOFTWARE PRODUCT MANAGER GETTING A PRODUCT TO MARKET HARD DEADLINES HAS ONE TARGET TO TEST AGAINST WE MUST MAKE IT EASY TO BUILD AN INTEROPERABLE PRODUCT

24 SHOULD & MAY MUST BE STOPPED

25 THE TELECOM PURCHASER NEEDS A NEW VOIP GADGET COMPATIBLE WITH ONE EXISTING PLATFORM HAS GOOD EXPERIENCE WITH A CERTAIN VENDOR MAKE IT EASY TO SPECIFY BROADLY-INTEROPERABLE PURCHASES

26 CLEAR STANDARDS MUST BE FAMOUS

27 THE INTEROP TESTER NEEDS A TEST PLAN BETTER THAN MOST ORGANIZATIONS CAN PRODUCE

28 GIVE US STANDARDS WHERE COMPLIANCE GUARANTEES INTEROPERABILITY

29 IETF STANDARDS AREN T DESIGNED FOR SERVICE PROVIDER GUARANTEES

30 1. INVEST TIME MAKING COMPLIANCE=INTEROP STANDARDS AND TESTING 2. PERSUADE DEVELOPERS TO BUILD TO COMPLIANCE=INTEROP STANDARDS. 3. EDUCATE TELECOM BUYERS ABOUT COMPLIANCE=INTEROP STANDARDS.

31 LET S MAKE COMPLIANCE=INTEROP Mark R Lindsey, mark@ecg.co

32 Supplementary slides

33 SIP over TCP is required in RFC3261 RFC3261 has been out for a while EXAMPLE 1: SIP OVER TCP...but a modern SIP SBC doesn t support it.

34 EXAMPLE 2: UPDATE Devices A and B wish to do SIP Device A advertises UPDATE support in Allows: header Device B sends a SIP UPDATE to Device A but it turns out Device A only supports UPDATE in a different circumstance. Sorry!

35 EXAMPLE 3: CODEC RENEGOTIATION Devices C and D wish to exchange calls C and D support all the same codecs But once Device C starts a call, it cannot renegotiate to any other codec.

36 Device E and F wish to exchange traffic Both support call transfer! Device E uses REFER for call transfer EXAMPLE 4: CALL TRANSFER Device F uses the old-fashioned Third Party Call Control (3PCC)

37 GENERAL WISDOM WITH SIP INTEROP Having experienced so many cases of brokenness, the industry has developed wisdom: On every new device, And on every new software version, And on every feature and every function: It only works if you prove it!

38 THE PROBLEM WITH THAT KIND OF TESTING Crazy Expensive, primarily in labor and opportunity costs Time Consuming Prone to Human Error Widely Repeated across the industry

39 It wasn t always so WHY ISN T IT SO HARD TO INTEROP WITH AN ISDN PBX? The two major switch manufacturers, Northern Telecom (now known as Nortel Networks), and AT&T (whose switch business is now owned by Lucent Technologies), selected different ways to implement the CCITT standards. These standards didn't always interoperate. This situation has been likened to that of earlier 19th century railroading. "People had different gauges, different tracks... nothing worked well. ISDN defined in 1984, consensus around 1999 with NI-2

40 WHAT MAKES VOIP INTEROP SO TRICKY? OPTIONAL & NEGOTIATED FEATURES Reliable ringback (PRACK) Session Timers Caller Privacy G.722 support (or any other specific codec) SIP Registration. UPDATE support OPTIONS support T.38 support

41 WHAT MAKES VOIP INTEROP SO TRICKY? NUMEROUS WAYS TO DO THE SAME THING Calling Party ID Calling Party Privacy (Block Caller ID, or not) Call Hold Domain name that appears in the SIP Headers Re-INVITE vs UPDATE for session changes Re-INVITE vs REFER for call transfers Diversion vs History-Info

42 WHAT MAKES VOIP INTEROP SO TRICKY? VAGUENESS IN STANDARDS: EVERYBODY SHOULD DO IT CORRECTLY. Inevitable imprecision of standards processes IETF approach of loose consensus and running code seems to work worse further up the protocol stack. (Or is it worse the further we get from 1980?) Examples: Exact structure of RFC2833 (DTMF transfer) messages, and when and how often to send them? What SHOULD the domain name be in From/To and other headers? What Payload type should be used for RFC2833? (Not every programmer knows about dynamic PTs.) Differing types of calling ID delivery or privacy (Remote-Party-ID vs P-Preferred- Identity) How exactly should telephone numbers be formatted?

43 WHAT MAKES VOIP INTEROP SO TRICKY? PARTIAL SUPPORT Is media renegotiation really required? If it Allows: UPDATE does that mean it really does UPDATE in every scenario? Is Remote-Party-ID, P-Preferred-Identity, P-Asserted- Identity really required?

44 HOW ARE WE SOLVING THIS MESS? Per-Network Certification Each service provider does their own testing Once a specific version of software and config file are tested, the interop is allowed SIPConnect Documented set of standards Very narrow definitions Others?

45 END-TO-END ARGUMENT DOESN T ANTICIPATE SERVICE PROVIDERS Service Provider is a Man In The Middle of the End-To-End Argument Could you live only with the device in your pocket, plus the Internet? No: Service Providers actually do have real value for VoIP, compared to endpoint agents at the edge of networks Tracking user location (think: SIP REGISTER and roaming between IP networks) Convenient User Addressing (think: telephone numbers, or addresses) Always on with quality network, hardware, data centers Backup and failover Services for users that endpoints cannot do themselves (think: Voic . Call Forward No Answer.)

46 THE TESTING PROBLEM GROWS WITH THE NUMBER OF SOFTWARE VERSIONS TO BE SUPPORTED. Each node represents a distinct SIP device or software version used for VoIP traffic anywhere in the world. The full-mesh of testing grows with each new software version that must be supported A defect in support of one software version on another device affects callers on every other platform in the VoIP network. My caller ID doesn t work! could be caused when a different device fails to populate headers properly.

47 We need to limit our interconnectedness to a few specific points of interop. E.g., we shouldn t have to interop test codec negotiation between Device A and all devices, B-Z. In practice, these are the walled gardens: we have a full mesh of interop testing inside the circle, but use our SBCs to define the limits between the two circles. This problem discussed in Alexander s Notes on the Synthesis of Form. FULL MESH INTEROP DOESN T WORK, SO WE DON T DO IT.

48 SO OUR WALLED GARDENS HAVE MADE VOIP POSSIBLE Even within the Walls, the SIP Interop problem is expensive and hard. Shouldn t SIP s famous Auto-Negotiation be working for us?

49 ENDING THE TYRANNY: MORE SIPIT PARTICIPATION Do we need lots more inter-vendor cooperation? But you d still have vendors who lack a basic feature that you depend upon, and their sales guy is never going to tell you that.

50 ENDING THE TYRANNY: BUILDING TEST HARNESSES INTO DEVICES Can we make our devices to be more testable? E.g., maybe for SIP phones, there s an out-of-band framework for simulating the buttons, LCD, and other non-voip parts of the endpoint This would work to reduce the cost of the testing at each vendor

51 ENDING THE TYRANNY: CRYPTO-SIGNED CERTIFICATIONS Can a third party award signed certificates of functionality? E.g., a SIPForum-signed certificate for each requirement of SIPConnect A device provides its certifications in response to a SUBSCRIBE, or in an OPTIONS response Other devices can automatically detect the capabilities available

52 OR MAYBE WE SHOULD LET THE OLD SCHOOL JUST SUFFER Facebook doesn t do extensive QA before each new release. Apple s not afraid to drop an old feature, or even release features that only works in a few scenarioes (E.g.: Video chat in Apple ichat.) Maybe the future belongs to the non-testers, who don t try to prove that the same features work the same way every time.