Can you re-test this with current svn trunk. I believe this was fixed yesterday. Mike On Feb 19, 2009, at 9:19 AM, Alexandru Nedelcu wrote:
OK, so effective_caller_id_number is the same as origination_caller_id_number set on the B-leg (cool).
Unfortunately origination_caller_id_number on the A-leg overides the origination_caller_id_number on the B-leg (I tried setting it with both effective_caller_id on the A-leg and origination_caller_id on the B-leg). It doesn't work.
If I'm setting caller-id on the B-leg only, then it works.
Has this something to do with my SIP provider maybe?
On Thu, 2009-02-19 at 08:42 -0500, Mathieu Rene wrote:
Clarification on the 2 vars.... you set origination_caller_id_number on the call leg directly. you set effective_caller_id_number on any leg that will get bridged to something else.
Internally, the core will look if effective_caller_id_number is set on the A-leg to see if it can use it.
This said: originate {origination_caller_id_number =12223334444,effective_caller_id_number=13334445555}sofia/gateway/ blah/12345 &bridge(sofia/gateway/blah/54321)
12345 is called and sees 12223334444 as callerid, then the call is bridged to 54321 which sees 13334445555 because bridge looks up the variable in the a-leg.
It would be the same as doing originate {origination_caller_id_number=12223334444}sofia/gateway/blah/12345 &bridge({origination_caller_id_number=13334445555}sofia/gateway/ blah/54321)
Having it as effective_caller_id_number only saves you the extra work of setting it on all B-legs
Mathieu