Hello Joegen,

I have send you the traces offline. Beside that, I did some more investigations and (hopefully) found the root cause for the problem. The safeChars list in opensipstack/src/ParserTools.cxx does not contain the "%". Therefore, an "%" is escaped everytime the message goes through this function. After adding the "%" to the list of safe chars, the problem disappears and an invite send in the form :

%2343%23@domain.tld is not changed anymore.

I would appreciate if you could check the impact of this change to the remaining code - if there is no impact, it would be great if you would incorporate it.

const char * safeChars = "abcdefghijklmnopqrstuvwxyz"
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"0123456789$-_.!*'(),+#";

changed to

const char * safeChars = "abcdefghijklmnopqrstuvwxyz"
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
"0123456789$-_.!*'(),+#%";

Regards,

Andre

Hello Joegen,

I compiled the SBC from the latest CVS version again - it works now. Many thanks.

But I still have questions. After the code change, the automatic SIPURI escape does not occur anymore and we leave the decision with the implementer- but how can one detect whether escaping is needed or not ? With not escaping the SIPURI anymore, do we create a possible security issue ? I thought about it the whole afternoon but could not find a possible approach. My problem is that there are too many variations and false positives in the pattern.

I referred to the RFC2396 again and read that an "%" character always has the preserved purpose of being the escape indicatior - I concluded therefore that the client application which receives an "%" character in the data part must do the escaping already (2.4.2. When to Escape and Unescape). If we trust it, we would be able to add the "%" to the list of safeChars - but I see a security and likely interoperabilty problem here.

My other idea was to leave the decision what to escape or not with the operator. An operator knows about special patterns which are used in his network - such as:

43 or

#43#.

What if a configuration option is present (even in the sourcecode, the information must be entered before compiling) where the operator can add preserved patterns ? (e.g. %2343%23 ) It can still cause false positives, but I think this chance is relatively low. We could then leave the automatic escape enabled and protect the SBC from being attacked in the SIPStack Code already. We would also solve the double escaping issue because the ParserTools would not touch our preserved pattern anymore.

What do you think ?

Regards,

Andre