-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, I found that the reason for this is maybe function send_display inf code file switch_ivr_bridge.c. At Line around 115 I replaced this: name = caller_profile->caller_id_name; number = caller_profile->caller_id_number; with this: if (!(name = switch_channel_get_variable(caller_channel, "effective_caller_id_name"))) { name = caller_profile->caller_id_name; } if (!(number = switch_channel_get_variable(caller_channel, "effective_caller_id_number"))) { number = caller_profile->caller_id_number; } Just for testing ... and it works as I wanted as long as I set effective_caller_id_name and -number to the value I need. Makes this sense to you? Or should openzap resp mod_openzap be enhanced to detect "type of number" and add a 0 resp 00 to caller_id_number? regards helmut On 14.04.2010 16:54, Helmut Kuper wrote:
Hello,
I have the following problem. A call comes in the following way: ISDN PRI->Sangoma->wanpipe->openzap->mod_openzap->freeswitch->B-Party
I use a national numbering plan, so caller's number e.g 044112345 is transmitted as 4412345 on isdn level. My dialplan adds two zeros to the effective_caller_id_name and -number. So it is now 0044112345. The B-Party displays this correctly. But as soon as B-Party picks up the caller's name switched back to 44112345 which is quite bad.
I tried to set caller's name and number via effective_caller_id_... , via origination_caller_id_... and via origination_callee_id_... but nothing worked.
It looks like the sip info process after connecting two sessions is not effected by those channel variables mentioned above.
I use FS tunk (17073M)
Any ideas what is wrong here?
kind regards helmut -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32)
iD8DBQFLxe7w4tZeNddg3dwRAiPYAJ9t4hyOF0kukgFfnUzHsLHbas0QfACfR2zN EalE5W+o345Wc5n8LkW+BtY= =e3G6 -----END PGP SIGNATURE-----