Subject: [Speermint] Problem: SIP Interoperability between Peers

From: "Daryl Malas" <[email-masked]>
Date: Tue, 3 Feb 2009 10:10:40 -0700

All,

I regularly hear the biggest problem facing SSPs attempting to peer is
SIP interoperability.  There are simply too many optional uses of SIP
today.  My questions are how do we solve this problem, and should it be
solved in Speermint?  In the past few months, I have spoke with
different service providers, and each of them have their own
*spreadsheet* describing what SIP extensions and variables you must
conform to in order to peer with them.  In addition to the other
capabilities an SBC provides, it is also becoming a peer SIP profile
manager.  Operational teams are screaming they spend most of their time
trying to figure out what profile to use for what peer.

How do we solve this problem?  At Minneapolis, during the RAI open
meeting, there was a discussion that the IETF does not support
implementers with real problems.  Here is a real problem plaguing the
industry.  How do we solve it?

Thoughts and feedback is appreciated.

Regards,

Daryl  

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:[email-masked]
_______________________________________________
Speermint mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/speermint

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 3 Feb 2009 13:19:52 -0500

This is exactly what the SIPforum is trying to do with initiatives like
SIPit and SIPconnect.

I don't have much confidence that the IETF is the place to solve SIP
interoperability problems.

If there are lessons learned certainly they need to be reincorporated into
the relevant RFC's but IMHO the structure of the IETF does not lend itself
well to solving operational problems you describe.

>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]]
>  On Behalf Of Daryl Malas
>  Sent: Tuesday, February 03, 2009 12:11 PM
>  To: [email-masked]
>  Subject: [Speermint] Problem: SIP Interoperability between Peers
>  
>  All,
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 04 Feb 2009 08:40:43 +0000

Daryl,

I would endorse what Richard says. In my opinion we are making great
progress with SIPconnect 1.1, but of course the proof will be when we
get it published (hopefully in the next few months) and when it gets
adopted in the market. It seems the SP-SP problem could be addressed by
a similar approach.

John 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Richard Shockey
> Sent: 03 February 2009 18:20
> To: 'Daryl Malas'; [email-masked]
> Subject: Re: [Speermint] Problem: SIP Interoperability between Peers
> 
> >  today.  My questions are how do we solve this problem, and 
> should it
> >  be

---

From: "Daryl Malas" <[email-masked]>
Date: Wed, 4 Feb 2009 09:02:11 -0700

John and Richard,

I do not have a preference as to where the task is taken up.  My biggest
concern is that SSPs do not seem to be very involved in the SIPForum.
How do we make sure there is the right level of visibility on this work
in order to assure adoption across the industry?

To some extent, I think this issue should go back to SIP or SIPPING.
For a number of reasons, SIP has a huge menu of options.  The issue
facing any group on deciding what is important and what is not wrt to
SIP has been a very challenging one.

When is SIP 3.0 coming out again?  While I joke, the interoperability
issues of SIP are the one issue that seems to plague this protocol.

Regards,

Daryl

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Wednesday, February 04, 2009 1:41 AM
> To: Richard Shockey; Daryl Malas; [email-masked]
> Subject: RE: [Speermint] Problem: SIP Interoperability between Peers
> 
> Daryl,
> 
> I would endorse what Richard says. In my opinion we are 
> making great progress with SIPconnect 1.1, but of course the 
> proof will be when we get it published (hopefully in the next 
> few months) and when it gets adopted in the market. It seems 
> the SP-SP problem could be addressed by a similar approach.
> 
> John 
> 
> > This is exactly what the SIPforum is trying to do with initiatives 
> > like SIPit and SIPconnect.
> > 
> > If there are lessons learned certainly they need to be 
> reincorporated 
> > into the relevant RFC's but IMHO the structure of the IETF does not 
> > lend itself well to solving operational problems you describe.
> > 
> > [mailto:[email-masked]]
> > >  On Behalf Of Daryl Malas
> > >  manager.  Operational teams are screaming they spend 
> most of their  
> > > time  trying to figure out what profile to use for what peer.
> > >

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 4 Feb 2009 12:28:57 -0500

>  From: Daryl Malas [mailto:[email-masked]]
>  Sent: Wednesday, February 04, 2009 11:02 AM
>  To: Elwell, John; Richard Shockey; [email-masked]

Well if I recall CableLabs is a member of the SIPforum  :-) as are several
MSO's.

http://www.sipforum.org/component/option,com_fullmember/Itemid,195/

Your point however is well taken however. Speaking as a Member of the BOD of
the SIPforum,  we have been lacking in gathering sufficient SSP support, but
that is changing.

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.

>  SIP has been a very challenging one.

Again I would strongly recommend against that. Its pretty obvious that the
RAI area in general and the core SIP WG are grossly overloaded.  

The current IETF structure does not lend it to solving interoperability or
operations related issues. The IETF does not like "profiles". Been there
done that.

Discussions like these need very different formats and venues than is
traditional in the IETF.  IMHO need real face to face meetings lasting over
several days and many more specialized Design teams to draft and debate
documents.  Not a scatter shot of 2 hour meetings we have in the IETF.
Perhaps something more like how CableLabs operates  :-) 

Perhaps its time again for one of our RAI SIPforum Lunch meetings in SF or a
long 2 hour min RAI general area meeting where this could be discussed.

Daryl, you were right to raise the issue and indeed there is a problem.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 05 Feb 2009 14:03:31 +0000

Daryl,

Have you seen Jon Peterson's proposal on the RAI mailing list for
restructuring (message posted yesterday)? It might be worth making your
concerns known on that thread. However, I still tend to agree that the
SIP Forum would be a better venue.

John 

> From: Richard Shockey [mailto:[email-masked]] 
> Sent: 04 February 2009 17:29
> To: 'Daryl Malas'; Elwell, John; [email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 14 Feb 2009 13:04:52 -0500

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Shockey
>

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 14 Feb 2009 13:16:31 -0500

> Behalf Of Elwell, John
> Sent: Thursday, February 05, 2009 9:04 AM
>

Isn't this actually within the scope of Speermint?  I can't quite tell.  I mean an interconnection profile would essentially be a BCP for peering, but the charter makes it sound potentially out of scope.  Can the chairs chime in on that?

But anyway SIP Forum has many IETF folks in it, but few service providers.  SIP Forum has Cablelabs' and a few others, but my sense is a broader base go to the IETF, including many more from outside the US.

-hadriel