#114 uri_db: check_to() should allow hex escaped username

ver devel
open
nobody
modules (93)
5
2008-08-06
2008-05-22
No

To be RFC3261 compliant a SIP proxy should accept hex encoded username in any URI, this is:

sip:alice@domain == sip:%61l%69ce@domain

For allowing this we must use, explicitely, the trnasformation $(rU{s.unescape.user}). Unfortunatelly RFC3261 allows this hex escaping in any URI (From uri, To uri, Contact uri...).

But, is OpenSer ready to allow this escaped system globally? I don't think so. For example I send a REGISTER:

-------------------
REGISTER sip:openser.org SIP/2.0
From: sip:%3800@openser.org;tag=18349ed0
To: sip:%3800@openser.org
Contact: sip:800@90.90.90.90
-------------------

NOTE that "%3800" == "800".

When OpenSer requires me authentication I send:

-------------------
REGISTER sip:openser.org SIP/2.0
From: sip:%3800@openser.org;tag=18349ed0
To: sip:%3800@openser.org
Contact: sip:800@90.90.90.90
Authorization: Digest username="800", uri="sip:openser.org", algorithm=MD5, realm="openser.org", nonce="45353832c42ccf694d4f4aad19e3da236a84dd4d", qop=auth, nc=00000001, cnonce="76fe7385", response="6f19337d47752e6bc60b689d2688793f"�
-------------------

NOTE that Digest username is "800" (it cannot be escaped).

But in OpenSer I use "check_to()" to verify if Digest username is equal to username in "To" header, so "check_to()" will try to match "%3800" against "800" and it fails (it decides they are not equivalent while they do be).

The only way to allow it is by modifying "check_to" C code.

This is: the valid escenario described above (REGISTER with hex escaped "To" username) is not valid in OpenSer.

Discussion

    • summary: "check_to" should allow hex escaped username --> uri_db: check_to() should allow hex escaped username
     
  • Logged In: YES
    user_id=1246013
    Originator: NO

    I am almost sure are solutions for all above, via transformations and other script features that allow you to get same functionality as check_to().

    Like: if($au == $(fU{s.escape.user}))

    I agree this should be considered in the future as a global escaping system. I move this as a feature request, to be considered for the next release.

     
    • labels: 780602 --> modules
    • milestone: 537593 --> ver devel