adding In-Reply-To in sip header not working
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. Mario G <action application="set" data="sip_rh_In-Reply-To=${caller_id_number}"/> <action application="set"><![CDATA[sip_h_In-Reply-To=<sip:${caller_id_number}>]]></action>
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
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
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@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@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
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@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@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@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
_________________________________________________________________________ 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
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@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@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@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@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
_________________________________________________________________________ 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
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@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@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@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@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
_________________________________________________________________________ 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
_________________________________________________________________________ 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
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@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@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@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@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
Hey Mario Thanks for sharing the solution.
notice it was close to Richards idea but uses _h_ instead of _rh_
I was definitely recommending _h_ not _rh_ but glad you got there in the end! Richard On 18 February 2013 18:05, Mario G <mario_fs@mgtech.com> wrote:
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"/>
participants (2)
-
Mario G
-
Richard Brady