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

[Mario G]

Finally! Sharing with anyone else wanting to pass the calling party ID from an external SIP account into FS then back to the standard PSTN on some ITSPs (Callcentric in this case), this is what works:

Anytime before the bridge: (notice it was close to Richards idea but uses _h_ instead of _rh_)
<action application="set" data="sip_h_In-Reply-To=${sip_call_id}"/>

In my bridge below remove the effective caller id number like this:

<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]sofia/gateway/${dial_gateway}/19161234567"/>



On Feb 4, 2013, at 12:44 PM, Mario G wrote:

> Yes, in and out are the same provider, although in/out may be different accounts, could that be the ticket?
> Mario G
> 
> On Feb 4, 2013, at 10:08 AM, Richard Brady wrote:
> 
>> That Call-ID looks fine. Just to be clear, you are sending this back to the same provider it came from right?
>> 
>> You'll need to post a trace (anonymised) in order for me to help further.
>> 
>> Richard
>> 
>> On 29 January 2013 19:31, Mario G <mario_fs at mgtech.com> wrote:
>> Thanks, I tried both suggestions but no love. When I used sip_h_In-Reply-To=${sip_call_id} used as below, the trace showed all normal but the cell phone does not ring at all. When I removed everything the cell rang but the original number was not passed. BTW, the sip_call_id was translated to (#s altered):
>> sip_h_In-Reply-To=3912345-9123456295-612341 at msw1.telengy.net, could that be an issue with ATT not liking it?
>> 
>> Mario G
>> 
>> 
>> On Jan 27, 2013, at 3:02 PM, Richard Brady wrote:
>> 
>>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130218/7df29b82/attachment.html