Thanks but sipusers, sippeers, sipregs and voicemail is from mysql database.
callerid, fromuser and username is correct set in the table.
below is the table from sipusers for 101 & 102,
As you have set fromuser, to 101, it is behaving as intended.
If you need to set fromuser, you may still be able to send caller ID by enabling sendrpid, but that is subject to the downstream system accepting Remote-Part-ID headers.
You will have to ask whoever operates the downstream. Note that responsible SIP service providers will be very selective in what caller ID they accept because it would otherwise be very easy spoof caller ID for fraudulent purposes. I would expect them ony to accept caller IDs for numbers that you can prove you own.
Where the downstream requires the from user to be set so as to identify the client, there are four tactics I’m aware of:
Do not allow caller ID to be supplied;
Use RPID;
Use asserted identites;
Use the user friendly part of the from header.
You say (2) doesn’t work for you. You are already using (4) by accident, and it doesn’t work.
Asterisk doesn’t support (3), although it may be possible using AddHeader.
Alternatively, you are forcing the value of fromuser in error, in which case you want to null it in the database.
actually there is no other provider.
it just a simple setup like below.
UA101 <—> ASTERISK <—> UA102
when 101 make a call to 102. 102 client receive the call it appear on screen from callerid=101 and fromuser=102@xxxxxx
i also tried set fromuser to null and set dialplan callerid(num)=101 but getting same result.
i also tested on asterisknow
using the same setup on the callee side the screen appear callerid=101 and fromuser=101@xxxxxx which is correct.
already null it in database still the same.
when i set 1)callerid=paul, fromuser=101/null, username=101 2)callerid=frank, fromuser=102/null, username=102
example on invite
101 invite 102, 102 on screen display Paul and 101@xxxxxx
when call ended 102 go to his call log saw Paul. and it try to call Paul he unable to identify Paul extension number.
No. The solution to the problem is not to set fromuser. That will not change for 1.8, as far as I know.
Are you using some GUI that you haven’t mentioned, which is limiting your ability to control the setting of fromuser? I can’t imagine one of the common GUIs doing that, as the way that setting it breaks CLID would be too obvious. fromuser is generally only needed when the peer is a PABX and expecting a simple phone.
The reason that you should be using 1.8 is that you will not get any bugs in 1.6.2.x fixed, and as it is a new install, you should not have any legacy constraints that prevent your updating.