[Freeswitch-users] adding In-Reply-To in sip header not working

[Richard Brady]

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.

They do this by looking the In-Reply-To header of the INVITE for the
forwarded leg, which should contain the Call-ID of the orignal leg.

So you need to copy the *Call-ID* in order to authorize the *Caller ID*.

A couple things:

1. From the docs: *effective_caller_id_name Sets the effective callerid
name. This is automatically exported to the B-leg; however, it is not valid
in an origination string. In other words, set this before calling bridge,
otherwise use origination_caller_id_name*

2. You shouldn't care about 1 above as it should be copied across from the
A leg by default and you are not modifying it, so
remove effective_caller_id_name and don't bother
with origination_caller_id_name either.

3. You should use sip_h_ not sip_rh_ because you want the header in the new
INVITE going out.

Perhaps try:

<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,*sip_h_In-Reply-To**=${sip_call_id}*]
sofia/gateway/${dial_gateway}/19161234567"/>

Hope this helps.

Richard


On 21 January 2013 19:54, Mario G <mario_fs at mgtech.com> wrote:

> 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 at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at 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 at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130127/bdd55db8/attachment.html