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

Mon Feb 4 23:44:44 MSK 2013

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
>>> _________________________________________________________________________
>>> 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
>> 
>> 
>> _________________________________________________________________________
>> 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
> 
> 
> _________________________________________________________________________
> 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/20130204/b2898dab/attachment-0001.html 