Subject: Re: [martini] The IETF versus reality (was: problems with existing SIP trunking solutions)

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 4 Apr 2010 11:45:59 -0700

Richard Shockey said:

"The IMS solution could certainly work for large scale enterprise
deployments served by ATT and massive PTT's but is 

ineffectual and cost prohibitive for small and medium business served
typically by CLEC's. That's the whole business 

and technical model behind implicit registration SMB's and competition."

[BA] To make the argument that the IETF is once again attempting to "gild
the lily", its necessary to demonstrate that an existing solution "only just
works" and is well on its way to achieving widespread deployment in both
SSPs and PBXes.  I don't believe that the IMS solution can make this claim
-- while the IMS approach has been implemented by some SSPs, I am not aware
of widespread implementation on PBXes within any market (enterprise, SMB,
etc.).  Given that the IMS specifications have been available for several
years now, if PBX implementations are either not available or in progress, a
sudden upsurge in interest is unlikely.  

The only approach that *might* meet the  criteria would be the "implicit
registration" functionality now commonly implemented in SMB PBXes (e.g.
Asterisk, Linksys, Grandstream, Response Point, etc.).  As I understand it,
in this approach the packet exchanges look exactly like a conventional RFC
3261 registration (e.g. no option tags, contact routing, etc.).  Since the
registration packets (and code path) are unchanged whether a single line is
being registered or multiple, this approach is relatively trivial to
implement on the PBX side (though more work is required on the SSP side).
Unfortunately, the "magic" that occurs on the SSP side appears to differ
significantly enough between providers that it would be difficult to develop
a specification and or a conformance or interoperability test.  Also, this
approach does not satisfy requirement 8 (explicit indication), and perhaps
requirement 4 (registration of individual AORs is typically not allowed).

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Apr 2010 12:55:23 +0200

Hi,

>Richard Shockey said:
>
>"The IMS solution could certainly work for large scale enterprise deployments served by ATT and massive PTT's but is
>ineffectual and cost prohibitive for small and medium business served typically by CLEC's. That's the whole business
>[BA] To make the argument that the IETF is once again attempting to "gild the lily", its necessary to demonstrate that an existing solution "only just works" and is well on its way to achieving widespread deployment in both SSPs and PBXes.  I don't believe that the
>IMS solution can make this claim -- while the IMS approach has been implemented by some SSPs, I am not aware of widespread implementation on PBXes within any market (enterprise, SMB, etc.).  Given that the IMS specifications have been available for several
>years now, if PBX implementations are either not available or in progress, a sudden upsurge in interest is unlikely.

>From my experience, very few things IETF produces "just work". In many cases it takes clarifications, interop tests, sometimes even bis documents, in order to get it all right... SIP itself, offer/answer etc, are good examples of that...

>The only approach that *might* meet the  criteria would be the "implicit registration" functionality now commonly implemented in SMB PBXes (e.g. Asterisk, Linksys, Grandstream, Response Point, etc.).  As I understand it, in this approach the packet exchanges look
>exactly like a conventional RFC 3261 registration (e.g. no option tags, contact routing, etc.).  Since the registration packets (and code path) are unchanged whether a single line is being registered or multiple, this approach is relatively trivial to implement on the PBX
>side (though more work is required on the SSP side).  Unfortunately, the "magic" that occurs on the SSP side appears to differ significantly enough between providers that it would be difficult to develop a specification and or a conformance or interoperability test.
>Also, this approach does not satisfy requirement 8 (explicit indication), and perhaps requirement 4 (registration of individual AORs is typically not allowed).

As people have indicated, different SSP configurations and assumptions most likely will be needed also for the current GIN solution, based on what the PBX expect etc.

Regards,

Christer