Re: [Speermint] Problem: SIP Interoperability between Peers

[Hadriel Kaplan <HKaplan at acmepacket.com>]

> -----Original Message-----
> From: speermint-bounces at ietf.org [mailto:speermint-bounces at ietf.org] On
> Behalf Of Richard Shockey
>
> SIPit is still the principal mechanism to test SIP interoperability but
> SSP
> have not been strong participants there either, nor have they used their
> 'power of the wallet' to force their vendors to comply with many of the
> relevant and important RFC's that would ease the interoperability issues.
> There has been a everlasting discussion within the SIPforum on formalized
> SIP compliance testing ( much like ASCII in RFC's) with no consensus among
> the participant members. Cost to the vendor community is the core problem.

Sipit is a great event to test product implementations for specific RFC mechanisms, but it does nothing to validate interoperability of multiple SIP domains' worth of deployed equipment with each other. (nor is that it's goal, obviously)  Part of the problem is the large installed base of legacy equipment, part of it is the large installed base of vendors who don't go to sipit.  But the real biggie is most equipment can be provisioned to do different things when deployed, which has nothing to do with what gets tested in an interop event, and you can't tell the other peer to change how their equipment is provisioned inside their network.

For example take just one of the myriad of common interop issues: PRACK.  PRACK itself causes interop issues due to SDP offer/answer complexity, but the major issue is when one operator requires PRACK because they believe it provides a superior user experience, while another operator will not allow PRACK because it causes them internal interop issues (ie, calls fail).  The current solution is to have a middlebox "interwork" the two policies, which is just a horrible protocol solution.  And I don't mean just from a protocol purism perspective - it actually means the middlebox has to create an SDP answer out of thin air for some calls, choosing codecs/media/etc. on behalf of the ultimate UAS, which is seriously bad mojo.  It gets even worse than that, but you get the gist.

I think a profile will help, if for no other reason than to provide a common set of rules for the interconnection, and put the onus of "interworking" or "fixing" them on whichever side does not follow them, such that they are the ones motivated to (eventually) address and correct them internally if the fixing causes issues.  But it will also help in reducing the provisioning of the peering connection, which is a good thing. (it won't be 100%, but even 50% reduction would be good, or even having several profiles)

-hadriel