For SIP to SIP traffic, we have a customised module to partially handle the anonymous caller-id thing. It does not require any modification on the UA. I mention "partially" because it does provide a small amount of support on RFC 3323, but not all. Note that it's not a B2BUA!
I can't share with you the code right now (company property) but can share the concept with you.
What we did is we authenticate all register request. Instead of picking the username part from To header, we use the username inside the Authorization header and save it as the username in location table.
Consider this message:
REGISTER sip:sip.example.domain SIP/2.0 Via: SIP/2.0/UDP1 92.168.21.101:5070;rport;branch=123ABC From: Anonymous sip:anonymous@example.domain;tag=2375368245 To: Anonymous sip:anonymous@example.domain Contact: "Anonymous" sip:anonymous@192.168.21.101:5070 Call-ID: D1C301E284C54BE7A20137061CF8387B@example.domain CSeq: 38044 REGISTER Expires: 1800 Authorization: Digest username="zeusng",realm="example.domain",nonce="..."
With stock SER module:
The AOR is anonymous@example.domain from the To header. Thus "anonymous" will be used as the username in the location table.
mysql> select username, domain, contact from location; +------------+--------------------+-----------------------------------+ | username | domain | contact | +------------+--------------------+-----------------------------------+ | anonymous | example.domain | sip:anonymous@192.168.21.101:5070 | +------------+--------------------+-----------------------------------+
With our customerized SER module:
The AOR is still anonymous@example.domain. Additionally, the "username" is zeusng in the Authorization Header. So, we use that as the username in location table.
mysql> select username, domain, contact from location; +----------+--------------------+-----------------------------------+ | username | domain | contact | +----------+--------------------+-----------------------------------+ | zeusng | example.domain | sip:anonymous@192.168.21.101:5070 | +----------+--------------------+-----------------------------------+
The UA can configure it's address as anything, provided it has the right username and password.
When this UA initial a call to another UA, it's identity is still anonymous@example.domain as shown in the From header, thus concealing caller-id.
When a 3rd party try to call this UA (sip:zeusng@example.domain), our location server can find it, because it's address is in location.
One thing we haven't figure out is how to do accounting, as the ACC module use From header for that purpose.
Of course, this solution does not conceal information in other headers that may reveal the identity of the caller. The elegant way would be follow RFC3323 and RFC3325. In that case, a B2BUA is better.
Zeus
-----Original Message----- From: serusers-bounces@lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Wednesday, 23 February 2005 11:20 PM To: Klaus Darilion Cc: serusers@lists.iptel.org Subject: Re: [Serusers] Manipulate from_uri
Klaus,
I realize that RFC3261 says do not modify the From header, however, my question is this;
When making SIP-to-SIP calls between two subscribers on the same SIP proxy, how can one implement Caller ID Block when RPID is not usually honored by SIP UAs - since this is really for PSTN gateways?
It seems that altering the From header in this case is the only option. Have I missed something?
Regards, Paul
On Wed, 23 Feb 2005 12:00:14 +0100, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Hi Mik!
Do not modify the From: or To: URI - this is not allowed (RFC 3261) and will cause problems.
regards, klaus
Mik Cheez wrote:
Since I'm able to modify the URI for relaying, I would
assume there
would be a way to modify the FROM_URI as well. Has
anyone managed
to do this with SER acting as a proxy? Any other
possible avenues
to modify the CALLID?
Best regards
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers