Ok, nifty. They are letting you present a number you do not own as Caller ID on an outbound call if that outbound call is a forwarded leg of an inbound call.
Thanks, apparently I had it wrong, the doc below states that the PBX must support it incoming, they pointed me to using effective_caller_id which I added to the bridge but it still does not work. Would love to fix this since the cell phones currently have no idea who is calling.Mario G<action application="bridge" data="{originate_timeout=45,alert_info=n=${lua_ringtone}}${group_call(bria@${domain_name}+A)},${group_call(deskphone@${domain_name}+A)},[leg_delay_start=20,leg_timeout=23,effective_caller_id_number=${caller_id_number}]sofia/gateway/${dial_gateway}/19161234567"/>
Please note that this feature is ONLY AVAILABLE for customers using a SIP PBX that either supports (or allows the configuring of) the "in-reply-to" header (defined by RFC 3261) for incoming calls which are forwarded to an outbound trunk. In these instances Callcentric will "Pass-Through" the CallerID from the original call which was received to the outbound bridged/forwarded call.
On Jan 19, 2013, at 5:13 PM, Richard Brady wrote:_________________________________________________________________________On 20 January 2013 00:06, Mario G <mario_fs@mgtech.com> wrote:I never did this so I must be missing something, I tried both below but the bridge then fails. Can anyone shed some light on what I am doing wrong. My ITSP now supports in-reply-to so I can pass the caller ID to a forwarded call from FS.In-Reply-To should contain a Call-ID not a caller ID. They are very different.The following would make a bit more sense, but still not a lot:<action application="set" data="sip_rh_In-Reply-To=${sip_call_id}"/>
Using In-Reply-To in a response doesn't seem right to me. I would expect it to appear in an INVITE. For for example, you get a missed call and you call the person back, then the INVITE for the callback would have a new Call-ID but the original Call-ID in the In-Reply-To header. That said, I have no idea what your ITSPs intended use for the header is.Richard
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org