[Asterisk-Users] chan_sip not 100% RFC3665 compliant - re-REGISTERsfail.

[Whisker, Peter]

There are issues with Asterisk chan_sip. Have a look at bug 0000759 at
bugs.digium.com. Comments in the feature report and source code like
those below probably go a way to explain your problems. I don't know how
much of this test version has been back-ported to chan_sip, however the
chan_sip2.c with a November 2004 CVS seems to work quite well.

Olle Johansson has suspended work on this for now due to workload and it
probably won't compile any more against the latest CVS due to changes
elsewhere.

Peter

"*   Added support for WWW-auth for registrations (according to SIP
RFC). "

 "*  + WARNING: This version changes a lot of functionality in regards
 *    to authentication, we use the digest auth username to check
 *    credentials for INVITES, not the username@ in the From: URI
 *    INVITEs are authenticated this new way, not REGISTER/SUBSCRIBE
 *    yet "

-----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Vahan
Yerkanian
Sent: 07 March 2005 13:55
To: Asterisk Users Mailing List - Non-Commercial Discussion
Cc: steven at addpac.com; jykim at addpac.com
Subject: [Asterisk-Users] chan_sip not 100% RFC3665 compliant -
re-REGISTERsfail.

Greetings,

For the past 2 months I've been struggling with registration problems
with asterisk+external FXS/FXO gateways (www.addpac.com) that use
RFC3665 re-registration procedure.

This problem occured for devices with more than one FXS port with a set
non-empty password.

Those gateway attempt to re-register after the initial register timeout
period expires fully compliant with RFC3665, clause 2.2
(http://www.zvon.org/tmRFC/RFC3665/Output/chapter2.html#sub2), but
asterisk fails to authenticate them.

The 1st FXS port of the device always registers successfuly (although
still uses same RFC3665, clause 2.2 procedure), but the remainder fail
miserably. Using an account/username with an empty password for the
affected ports fixes the problem - so this is something with www-digest
method (?).

I've spent 2 weeks debugging this with addpac development team, and the
same device authenticates flawlessly with Sonus Proxy Server, SNOM Proxy
Server, LongBoard Proxy Server, Nortel Proxy so this seems to be a
problem with chan_sip.

I'm hesitant to post the long sip debug outputs to the mailing list to
conserve the bandwidth. More info and sip debugs are available at
http://bugs.digium.com/bug_view_page.php?bug_id=0003726

Is there anyone else with the same problem?

regards,
Vahan


This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.