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

Discussion:

Mario G

2013-01-20 00:06:57 UTC

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>

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

Richard Brady

2013-01-20 01:13:42 UTC

Permalink

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/20130120/9fa7e6c2/attachment.html

Mario G

2013-01-21 19:54:30 UTC

Permalink

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.

Post by Mario G
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.
<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
_________________________________________________________________________
consulting at 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 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/20130121/69977ff0/attachment.html

Richard Brady

2013-01-27 23:02:25 UTC

Permalink

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

Post by Mario G
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=
${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.

In-Reply-To should contain a Call-ID not a caller ID. They are very different.
<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
_________________________________________________________________________
consulting at 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 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
_________________________________________________________________________
consulting at 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 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

Mario G

2013-01-29 19:31:43 UTC

Permalink

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

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.
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.
Hope this helps.
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
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.

_________________________________________________________________________
consulting at 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 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
_________________________________________________________________________
consulting at 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 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/20130129/d569fa9c/attachment-0001.html

Richard Brady

2013-02-04 18:08:22 UTC

Permalink

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

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
sip_h_In-Reply-To=3912345-9123456295-612341 at msw1.telengy.net, could that
be an issue with ATT not liking it?
Mario G
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*.
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.
<action application="bridge" data="{originate_timeout=45,
leg_delay_start=20,leg_timeout=23,*sip_h_In-Reply-To**=${sip_call_id}*]
sofia/gateway/${dial_gateway}/19161234567"/>
Hope this helps.
Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130204/1a822862/attachment-0001.html

Mario G

2013-02-04 20:44:44 UTC

Permalink

Yes, in and out are the same provider, although in/out may be different accounts, could that be the ticket?
Mario G

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
sip_h_In-Reply-To=3912345-9123456295-612341 at msw1.telengy.net, could that be an issue with ATT not liking it?
Mario G

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.
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.
Hope this helps.
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
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130204/b2898dab/attachment-0001.html

Mario G

2013-02-18 18:05:47 UTC

Permalink

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}"/>

Post by Mario G
Yes, in and out are the same provider, although in/out may be different accounts, could that be the ticket?
Mario G

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.
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.
Hope this helps.
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
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.

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

Richard Brady

2013-04-08 14:45:34 UTC

Permalink

Hey Mario

Thanks for sharing the solution.

Post by Mario G
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

Post by Mario G
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}"/>