On 6/16/10 9:38 AM, M. Ranganathan wrote:
Well, you can clamp down the codec to a single supported codec such as
G711 ( i.e. filter the request and response SDP to that single
some of our interoperability was in fact when calls go from G.729 to
G.711 (G.711 needed for AA, or moh)
has some strangeness with attended transfers (blind worked), and
forwarding phones from a broadcom based system.
supported codec and never re-invite subsequently ). Asterisk has that
option ( i.e. can re-invite ). We can support that but at the moment
the implementation does not support it. I had started down that path
at one point but the logic got convoluted enough that I had to stop.
Yes I can place the hack back with a
<interoperability>caveat-emptor</interoperability> flag. So sipxbridge
always upward compatibility.
and as one who has for years needed to work with buggy implementations,
BIG vendors who substitute their rules for the RFC's, I can tell you
that sooner or later, you would need to figure out what they are doing
wrong.
Example: spam: Don't want spam? set up a mail gateway that 100%
enforces the RFC's. drop 99.9% of your spam for free.
(a good qmail, postfix, exim, sendmail mta, etc)
Also drop 35% of your legit email.
as an example, the email I am replying to that was sent to this list is
NOT RFC compliant, and if I enforced 100% of the RFC's, I would not have
gotten that post to the list.
(
Received: from nortel01.managed.contegix.com (67-221-235-27.contegix.com
[67.221.235.27]))
FWD and RDNS do not match the FQDN used in the HELO/EHLO
(run this google search
<http://www.google.com/search?q=rfc+helo+fqdn+match+rdns>
So, enforce all the RFC's? SIP standards to all exclusion?
Truly bad idea, however: it IS an open source, GPL system, and anyone
here has access to the source code and can 'fix' it themselves.
will go back to "mostly working" for such ITSPs. It is just true that
all call flows have not been tested for such buggy ITSPs. Unless we
can do that, it is leaving the door open for customer issues in the
field.
PLEASE LIST all the 100%, fully SIP/sipxbridge compliant ITSP's,
However, some of that is only 100% fully SIP/sipxbridge compliant if you
use the right phone/firmware combination.
Saying 'you must be 100% SIP RFC COMPLIANT' is meaningless, since there
are in fact 'conflicting' RFC's, options that the ITSP could pick that
would be RFC complaint, that could break a fragile implementation
I have a HUGE spreadsheet from level3 who is planing on sending us 23
'SIP TRUNKS', fully SIP compliant(tm), but I have a lot of optional
settings.
I am hoping, that it works right out of the box, with the settings we
have cobbled together from the sipx documentation, we might need to
force G.711, we might need to purchase the G.729 codex for freeswitch.
We made a pretty big investment getting level3 to install the 100mb
fiber to the office, and I am assuming that once they turn on the
trunks, they will want us to use them.
Yes, they support 'industry standard' ip/SIP PBX's, but don't seem to
have any knowledge of the avaya/nortel/sipx install.
Maybe once we have it 100% working, we will document it.
--
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
> *| *SECNAP Network Security Corporation
* Certified SNORT Integrator
* 2008-9 Hot Company Award Winner, World Executive Alliance
* Five-Star Partner Program 2009, VARBusiness
* Best Anti-Spam Product 2008, Network Products Guide
* King of Spam Filters, SC Magazine 2008
______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.secnap.com/products/spammertrap/
______________________________________________________________________
_______________________________________________
sipx-users mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
sipXecs IP PBX -- http://www.sipfoundry.org/
