[asterisk-bugs] [Asterisk 0014668]: register: '/' in username not supported

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14668 
====================================================================== 
Reported By:                Netview
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14668
Category:                   Channels/chan_sip/Registration
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     confirmed
Target Version:             1.6.3.0
Asterisk Version:           SVN 
Regression:                 Yes 
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.1 
SVN Revision (number only!): 182123 
Request Review:              
====================================================================== 
Date Submitted:             2009-03-15 05:02 CDT
Last Modified:              2009-04-09 12:19 CDT
====================================================================== 
Summary:                    register: '/' in username not supported
Description: 
My VoIP-Provider 'bluesip.net' needs a username in the following way:
'bluesip/name'

sip.conf:
...
register => bluesip/name:secret at bluesip.net/bluesip 

But the register attempt is rejected with:
chan_sip.c:6542 sip_register: Format for registration is
[transport://]user[:secret[:authuser]]@domain[:port][/extension][~expiry]
at line 69

====================================================================== 

---------------------------------------------------------------------- 
 (0103019) oej (manager) - 2009-04-09 12:19
 http://bugs.digium.com/view.php?id=14668#c103019 
---------------------------------------------------------------------- 
We should be able to handle this character in the username field, if it's
allowed by the RFC. You should not have to enter it encoded, but we are
forced to encode it when sending it in the username, but *not* in the
authentication part or when calculating MD5.

One should propably try with encoded part in username and unencoded in
auth user to get a real idea about what to fix. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-09 12:19 oej            Note Added: 0103019                          
======================================================================