There's no tracker issue yet - It was suggested to create one since the CDR record "showed" when active, but is not visible under historic. This may have o do with the error code received back when it failed and whether sipx could properly interpret the code and write the record?
In either case the call failed, but the bigger issue is that it "probably" failed since the dialplan is executing a prefix that is stated to be numeric only, since I can enter "9+" instead of "9". One would suspect sipxconfig should not allow this to be entered if it is not setup to address it properly. I'm not sure I can enter a tracker issue right now since I don't totally understand how I got in this mess to begin with and have had to revert from our production system to a standby PBX (analog) system in order to dial out right now. I'm curious to know if there is a way to manually modify the prefix to allow a character other than numeric only and see if sipx will properly strip the character. If it cannot, then the issue would be? If the number dialed is "+19195551212", How come sipx can't execute it it it's a valid E164 number? Or, why is a "+" not allowable in the preifx if its a valid character for E164? Once I understand how to "workaround" this, or not, I can file a tracker issue that more thoroughly explains the problem as a whole so it can be addressed one time, instead of two. Thanks, Tony >>> "Martin Steinmann" <[EMAIL PROTECTED]> 06/19/08 08:09AM >>> Tony Is there already a tracker issue on this or are we still in the process of finding out what is going on? --martin -----Original Message----- From: [EMAIL PROTECTED] on behalf of Tony Graziano Sent: Thu 6/19/2008 7:56 AM To: Scott Lawrence Cc: [email protected] Subject: Re: [sipx-users] From: <sip:+1(10digit [EMAIL PROTECTED]> Is there a way to change the dialplan prefix to allow characters besides integers; "Prefixes Prefixes can be integers (e.g. 2), ranges (e.g. 1-5),or lists (e.g. 2,3,4)" without transforming the characters into something unpassable (i.e. from + to %2B) or strip them before sending to the gateway? >>> Tony Graziano 06/18/08 22:16 PM >>> In the dial plan, it says the prefix MUST be a number. If this is the case, it is actually accepting a non-numeric input, but the transform is "very" unpredictable, but perhaps not a CDR bug as much as a sipxconfig/dialplan bug in that it accepts it and transforms it to something "unpassable". How does anyone get around the issue of sending a "+" since it can't be stripped, and is not strip-able or sendable by sipx via a dial rule? >>> "Tony Graziano" <[EMAIL PROTECTED]> 06/18/08 11:38 AM >>> I'm still trying to understand the issue. It displays to CDR that way when I use a + as the PSTN prefix. I can find no other way for the call to even get through the dialplan. Even when it gets throughs it sends %2B1 to the gateway (ingate, which can't interpret this either. I've tried many variations to "strip" that with a custom dialplan too. Nothing seems to work. Am I the only one hitting this? >>> Scott Lawrence <[EMAIL PROTECTED]> 06/18/08 09:31AM >>> On Wed, 2008-06-18 at 06:36 -0300, Tony Graziano wrote: > I tried to add "+" as the prefix, it now shows up in the CDR as > %2B1(10digit) number when I dial, so the calls fail but at least get > through the dialing plan and show up in the CDR. > > Starting to hate Bandtel. It may be that there are good reasons to hate Bandtel - I take no position on that at this time - but this is probably not one of them. Using a fully qualified E.164 number is probably the least ambiguous way to do PSTN addressing between administrative entities. Having the '+' not display correctly in a CDR is a bug - please file an issue. -- Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED] sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.com/ http://www.pingtel.com/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
