On Thu, 2008-06-19 at 09:58 -0300, Tony Graziano wrote: > 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?
The proxy can certainly handle that - whether or not there is an issue with getting it configured so that it works and displays correctly is still to be determined. > 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. We don't need to wait for a solution to file an issue - the issue is the problem statement, so let's get back to figuring that part out. Please file the issue and put into it the answers to these questions: Can you enter '+' as an optional prefix digit in your dial plan w/ sipXconfig, and if so does it then propogate to the fallbackrules.xml file? If you can, does that correctly make the call? If not, please attach a snapshot taken after making the attempt, with logging on all components set to INFO. Identify the call by called and calling number and approximate time (or even better, call-id). The '%2B' you're seeing in some places is probably an artifact of some overly-aggresive character translation somewhere (we'll have to track that down), but it should work - that is the SIP-standard hex-escaped version of '+', and _should_ be treated exactly the same as '+' in the user part of a URL (but "should" is a bad word in interoperability discussions). -- 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
