[Asterisk-Users] Formatting in sip.conf...can you have 2 @ signs for register?

[Greg Hill]

On Mon, 16 Aug 2004, Olle E. Johansson wrote:

> James Freire wrote:
>
> > Hi All,
> > I am trying to setup another sip trunk in addition to what I am already
> > using.  The sip provider we are using right now gives you your username
> > as your email address. So IE. If my email is james at james.com.... that is
> > my username . Now... When I put this in the sip.conf file I have found
> > that Asterisk is not able to parse it correctly and instantly goes to
> > the email server to authenticate the sip user upon registration
> >
> > Here is the line below in my sip.conf file
> >
> > register => username at theiremailhost.com:password at sipprovider.com
> >
> > THe error is below
> >
> > Aug 16 11:30:05 NOTICE[114695]: chan_sip.c:3922 sip_reg_timeout:
> > Registration for 'john at useremail.com@sip.voipamericas.com' timed
> > out, trying again
> > Aug 16 11:30:06 NOTICE[114695]: chan_sip.c:6575 handle_response: Failed
> > to authenticate on REGISTER to
> > '<sip:john at useremail.com>;tag=as1c528b93'
> >
>
> That's obviously an error. Please add it to the bug tracker and we'll solve it.


I disagree.. although the sip rfc (I'm looking at 3261, June 2002) doesn't
specifically state that the user field cannot have the @ character in it,
the language there suggests that '@' is supposed to be the separator
between the user string and the host string. In addition, it is stated
that the sip URI scheme follows RFC 2396, which states that all of
[;/?:@&=+$,] are reserved characters. See section 2.2:
   The "reserved" syntax class above refers to those characters that are
   allowed within a URI, but which may not be allowed within a
   particular component of the generic URI syntax; they are used as
   delimiters of the components described in Section 3.

I think Asterisk's behavior is correct and the syntax
'john at useremail.com@sip.voipamericas.com' is debateable at best. It's
possible that replacing the @ in the intended user portion with %40 may
allow it to slip through Asterisk and get un-escaped by the server on the
far end.. Anyway, the issue may warrant some more dialogue before
declaring it a defect.

Greg