[#XCF-1106] "regular expression" characters in dialing rules should be escaped when generating .xml files

sipXconfig

"regular expression" characters in dialing rules should be escaped when generating .xml files

Created: 2006-06-28 18:10 Updated: 2008-01-09 15:55

Component/s:

dial plan

Affects Version/s:

None

Fix Version/s:

None

Original Estimate:

Unknown

Remaining Estimate:

Unknown

Time Spent:

Unknown

Description

« Hide

registrar is using a non-standard regular expression language to allow for wildcard matching
I could not find any documentation but it looks like it's translated into Perl expression in UrlMapping::convertRegularExpression method (sipXcommserverLib/src/digitmaps)
Looks like if user enters names containg "x" or "." it might translated into regular expression matching different set of uris that intended.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Damian Krzeminski - 2006-06-28 18:11

Scott - could you comment on that.
Is this the real issue? If it is what characters in user part of the URI should be escaped.

[ Permlink | « Hide ]

Scott Lawrence - 2006-08-01 15:54

Confirmed that this doesn't translate at least the sequence '\*' correctly.
This will mess up several things, so I've raised the priority.

[ Permlink | « Hide ]

Scott Lawrence - 2006-08-02 09:20

the underlying dial string syntax is not well documented, and the translation has bugs.
this is tracked as XCS-69; the fix for that issue will include better documenation that should clarify what is needed from sipXconfig

[ Permlink | « Hide ]

Scott Lawrence - 2006-08-02 14:25

I've fixed the underlying problems in the xml parsing and the message construction.
See me if the documentation in the schema file is not clear.

[ Permlink | « Hide ]

Damian Krzeminski - 2006-08-03 10:58

Update after fix for XCS-69
The special characters used in (mapping|fallback)rules.xml matching are
. (dot)
x (letter x)
[ (open bracket)

They are not escaped by sipXconfig (in other words if you enter prefix "x12" it will match "023" but not "x12".

They probably should be escaped at some point, but only if there is a option to disable escaping (something like: "use regular expression matching") per rule in UI

The workaround: use "\" to escape special characters (any of: x . [ ) explicitely in UI.