Ray Van Dolson wrote:
Posted this to -dev, but it may be more appropriate here as I haven't
released my "patches" for it...
I've run into a couple issues relating to RPID.
I have an Asterisk 1.2.1 installation doing SIP for SPA-2002 and PAP2-NA
ATA's. From the Asterisk box, we then do SIP to a VoIP provider who handles
the SIP to PSTN translation for us. Pretty straight forward.
I decided to try using the RPID features in 1.2.1. Enabled all the
trustrpid directives and sendrpid as well. However, when I dial *81
<number> on my Sipura (*81 makes the call private) I get a fast busy back
from Asterisk.
Upon further investigation, it appears that Asterisk is saying the Sipura is
unauthorized. This only happens when I try and block caller ID from the
Sipura though.
Dug around in the source a bit and it seems that Asterisk uses the contents
of the From header to authenticate the ATA against. Normally (when making a
non-CLID blocked call), the Sipura sends a from header like the following:
From: ROY <sip:[EMAIL PROTECTED]>;tag=cec0ff0080328e51o0
Authentication works fine in this case.
However, when the caller dials *81, the from header looks like this:
From: Anonymous <sip:[EMAIL PROTECTED]>;tag=db61581ae353a8e1o0
I believe this is why authentication is failing.
Now, is this incorrect behavior by my ATA? Seems like it should populate
the From header no matter what. On the other hand, I see that the
5305715503.pw.digitalpath.net username is available in two other places in
the initial INVITE:
* The Contact header:
Contact: Anonymous <sip:[EMAIL PROTECTED]:5060
* The RPID header:
Remote-Party-ID: ROY <sip:[EMAIL
PROTECTED]>;screen=yes;privacy=full;party=calling
So, what I gander is happening is that Asterisk is using the contents of the
From header the first time around to generate the auth challenge stuff
(nonce, etc) which is sent back to the ATA. The ATA then replies with the
Proxy-Authorization field with the *correct* username (the 530571...). This
doesn't match up with what was in the From field (Anonymous) and thus
authentication fails. Correct?
Maybe Asterisk should initially use the username in the Contact field to do
authentication on? Or the RPID header if available?
In any case, my solution was to modify check_user_full() and if an RPID
header is available, I copy the username out of it into the "of" variable and
authentication succeeds and the call works fine with or without *81.
The fix works for me, but I have a feeling there's a more "correct" way to
address this issue. I'd like to know if my Sipura is misbehaving, or if
Asterisk should be looking somewhere other than the From field for
authentication info.
Asterisk should look somewhere else - in the auth header - for
authentication info. However, this is not easy to fix in the current
version of chan_sip. I've tried coding that before (chan_sip2) but it
required too large changes at the time.
We're currently planning a new generation of chan_sip that will have a
different authentication scheme, not based on the from: header unless
it's a local policy to require the From: header to be the same as the
Digest auth user name.
So to summarize: The Sipura is doing the right thing, but Asterisk can
not handle it today, since Asterisk requires a From: user name. You need
to disable the caller ID in Asterisk, not in the Sipura.
/O
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
