My opinion is that the ITSP needs to send the call according to a useable standard. After briefly reading up on the cirpack switch, it's evident their income is not derived from "sip" based solutions, and the offering is secondary to IPTV and Internet (triple play), but that they do have several million lines installed and using the service.
I had a similar issue with a POTS line not giving me the caller ID number (just name) from my local telco. After MUCH troubleshooting, I was astounded to see the issue was with my local TELCO sending the data out of sequence. My options: 1. Get another gateway 2. Get another provider 3. Get my provider to fix it 4. Get me gateway provider to fix it I had a lot of options, but ultimately my gateway worked with the solution, because I called the TELCO and eventually got in touch with someone who was able to resolve it by changing my CallerID options to remove DDI (Canadian DDI caller ID), and thats not what they sold me. Fortunately it was a Nortel switch, and it had the proper capability, but was implemented wrong. Since the switch was under control of an entity who could guarantee the standard could be met, it was resolved, but not before I had to paint the picture for them several times for them to look into the options to find the problem. Later on my gateway provider provided a firmware update to accept the data and reorder it if it was sent improperly, but I've never used it, even though they wrote the function in at my request, because they want to be able to support Canadian DDI stuff too (I'm not in Canada though, but my gateway manufacturer markets worldwide). My only reason in pointing this out is that it is similar to your situation. Your provider is not giving you the data properly, and the fact that they interoperate with several other PBX brands means the developers of those PBX's decided to support a "non-standards" environment. Personally I don't think that's a good idea, because mayhem soon ensues. I'm not going to debate what's better, that's what choice is about. I doubt the issue is with Cirpack's switch, it is more likely how one provider is buying (or reselling) space on someone else's switch (aggregating) and resulting in this. It sounds like a bigger problem waiting to happen. I am very confident the sipx solution would work on a competently deployed instance of a cirpack switch too. SIP should be SIP no matter what country it is in. It took my 3 ITSP's to get me to the point where I found one that delivered what they marketed. Get thee to a real ITSP, and beware, not all are equal. Just my 2 cents. Tony >>> J Coatline <[email protected]> 02/19/09 1:58 PM >>>We have 20 DDI/DID >>> numbers, and our ITSP (Digital Realm/Quantum Voice) sends our primary >>> subscriber number in the SIP URI, and the actual DDI/DID number dialed in >>> the sip To: field. I see this has been discussed in XECS-2204, and that it was decided that because the ITSP behavior is incorrect, routing based on DDI numbers in the To: field will not be supported. I'm not going to be able to get our ITSP to change their behavior, so is there some kind of hack I can do to get sipXecs to route based on the To: field? If there's no way I can do a hack, then either I have to get my ITSP to change the way they work (almost impossible), beg the sipXecs developers to add a check box or some more flexible options to support this faulty behavior, or go back to 3CX (which allows lots of flexibility in how to interpret sip fields, presumably to allow it to work with all the broken SIP implementations out there, which I think is ultimately a good thing for an IP PBX operating in the real world). I know our ITSP are doing it wrong, but there's not a great deal I can do about this. I would really prefer not to go to all the trouble of changing ITSP (porting numbers, renegotiating price-plans etc), so does anyone have any other suggestions other than going back to 3CX? </[email protected]>
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
