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(a)pernau.at> wrote:

The answer is B2BUA There actually two ways, First is b2bua which is nice (for me ok.. I like it :) Second if you assign the CallerID number to device.. the real callerid, (for example in my network we use some fake numbers into devices and then change it do real callerid (did) in b2bua), then some devices, for example SIPURA, can send Anonymous as name in From and Contact and some GWs, will use it and hide callerid on outgoing call. And third: And there are also Remote-Party-Id: field in SIP that partially supported by SER and supported by most of GW and carriers, and that is probably RIGHT way to do that. When PSTN GW sends call to outside of ur network, it no just skip callerid, u can do it but it is wrong, it make it private, so usual ppl will not see it but for example 911 and some toll free subscriber will see. That right way and that how everybody should do cli blocking. What is wrong in this method is that if you call goes from SIP to SIP and you use as me fake CLI on devices, customers will see fake numbers because as far as I know SIP devices does not support RPID (please correct me if I am wrong) so in my case I will have to use combination of N1 and N3.. -----Original Message----- From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: Wednesday, February 23, 2005 7:20 AM To: Klaus Darilion Cc: serusers(a)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(a)pernau.at> wrote: _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

I must admit, when I modified the To or From headers in the past, the message got sent, but any return messages from the gateway were ignored by the sip server because the nonce didn't match anymore. So I don't think it is just a simple case of modifying the headers. Simon -----Original Message----- From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Java Rockx Sent: 23 February 2005 15:33 To: Vitaly Nikolaev Cc: serusers(a)lists.iptel.org Subject: Re: [Serusers] Manipulate from_uri Vitaly, I believe you are correct that RPID is only helpful during SIP->PSTN calls. I'm not real familiar with B2BUA, but if I were to introduce one in to my system, does that mean I need to have all the RTP traffic pass through my network as well, or does the B2BUA only deal with SIP messaging? Regards, Paul On Wed, 23 Feb 2005 10:14:18 -0500, Vitaly Nikolaev <vitaly(a)voipsonic.com> wrote: _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

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(a)example.domain CSeq: 38044 REGISTER Expires: 1800 Authorization: Digest username="zeusng",realm="example.domain",nonce="..." With stock SER module: The AOR is anonymous(a)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(a)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(a)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