Setting host in refer-to on REDIRECT TCL transfer

[nate.koenig]

I'm doing a SIP REFER transfer in TCL using the following:

set callInfo(originationNum) 1112223333

set callInfo(mode) "REDIRECT"

leg setup $dnisValue callInfo $incoming

Assuming dnisValue is 2223334444 for illustration purposes.

This works, in that the gateway sends a REFER message, with the REFER-to field being the dnis in the $dnisValue variable.

024410: May  3 11:25:09.360 EDT: //0/000000000000/SIP/Msg/ccsipDisplayMsg:

Sent:

REFER sip:2223334444@x.x.x.x:5060 SIP/2.0

<snip>

Refer-To: sip:2223334444@x.x.x.x

The problem is that the "x.x.x.x" (host portion of the refer-to) is the egress interface of the same gateway, instead of the carrier IP. The carrier is receiving the REFER, accepting it, then sending the call back to the gateway (since the x.x.x.x IP is the gateway.)

Is there a way to specify the host portion of the refer-to when doing the transfer via TCL? I would think it would be in callInfo if it is able to be set..

Thanks!

[Raghavendra G V]

Hi,

You can get refer-to dest as below, modify and set the new destination.
set XferTo   [infotag get evt_transfer_info transferDest]

leg setup $XferTo callInfo $OutgoingLeg

Thanks,
Raghavendra

[nate.koenig]

With the suggested code, I'm getting:

051424: May 16 09:42:52.763 EDT: //2802//TCL :/tcl_InfotagGetObjCmd: infotag get evt_transfer_info transferDest

051425: May 16 09:42:52.763 EDT: //2802//AFW_:/vtr_ev_transfer_info: argc 3 argindex 2

051426: May 16 09:42:52.763 EDT: //2802//AFW_:/vtr_ev_transfer_info: no transfer request info in event scope

051427: May 16 09:42:52.763 EDT: %VOICE_IEC-3-GW: TCL_IVR: Internal Error (Get infotag failed): IEC=1.1.180.2.31.0 on callID 2802 GUID=5FDFEC6F397411E79DCB9C709CC2C26B

on the line:

   set XferTo   [infotag get evt_transfer_info transferDest]

Looking at the documentation, it is because the scope for the above command is ev_transfer_request, but, I need this information prior to starting the transfer (so I can modify the destination host of the refer-to.)

[nate.koenig]

I was thinking perhaps of specifying a sip uri with the host on the leg setup, something like:

set TakebackDnis [format {sip:%s@%s} $TakebackDnis $hostHere]

set callInfo(originationNum) 1112223333

set callInfo(mode) "REDIRECT"

leg setup $TakebackDnis callInfo $incoming

However, if I do that, I see:

071324: May 16 10:37:07.041 EDT: //2851/F387BD7D9E59/SIP/Error/sipSPISaveReferParams:

No dialpeer passed from application for xfer

(it should use the existing ingress dial-peer for a REFER instead of using the gateway's dialplan. It does this correctly when it is not a sip uri.)

[yawming]

When you do the call setup just need number, not the the entire sip url

[nate.koenig]

yawchen: If I use just the number, I get the issue mentioned in the first post. It works, but, the refer-to field has the IP of the gateway itself for the domain/host (instead of the carrier IP), so the carrier routes the call back to the gateway. Basically, I need a way to change the domain/host for the REFER, per the first message above.

[yawming]

I haven't worked on script for a while but don't we setup this in session target in the dialpeer ?

[nate.koenig]

It's a redirect on an existing call, so, I'd expect it would use the dial-peer that the call ingressed through. If I don't use the sip URI, it sends it out to the carrier as expected.

Either way though, there are matching dial-peers on the gateway (pointing to the applicable IP.)

[yawming]

I think the key is to find out "The problem is that the "x.x.x.x" (host portion of the refer-to) is the egress interface of the same gateway, instead of the carrier IP" like you indicated. Who instructs putting refer-to target ip ? Tcl script ? IOS config ? Other device ?

Can you use separate dialpeer fot the transfer call ?

[nate.koenig]

It appears to be automatically populated. The TCL script is what initiates the refer using the code in my original post. If you specify a destination that is just a phone number, the REFER is sent/accepted, but, egress IP is populated as the refer-to host (which seems to be improper.)

If you specify a sip URI (sip:1112223333@x.x.x.x) as a destination (tried as a workaround), the REFER never gets sent out.

[yawming]

who initiates transfer ? How is the call flow from end to end ?

[nate.koenig]

TCL script initiates the transfer after receiving DTMF from the caller.

The following code initiates the REFER transfer (the "redirect" part is what causes the transfer vs. just setting up another leg) :

set callInfo(originationNum) 1112223333

set callInfo(mode) "REDIRECT"

leg setup $dnisValue callInfo $incoming

After doing that, we see the following in the refer:

024410: May  3 11:25:09.360 EDT: //0/000000000000/SIP/Msg/ccsipDisplayMsg:

Sent:

REFER sip:2223334444@x.x.x.x:5060 SIP/2.0

<snip>

Refer-To: sip:2223334444@x.x.x.x

The problem is that the "x.x.x.x" (host portion of the refer-to) is the egress interface of the same gateway, instead of the carrier IP. The carrier is receiving the REFER, accepting it, then sending the call back to the gateway (since the x.x.x.x IP is the gateway.)

Since the TCL script is the one initiating the transfer, I need a way to specify the host/domain IP in the Refer-To when I setup the new leg above.

[yawming]

Can you manually hard code in the following format to test it out ?

set TakebackDnis “sip:1234567@abc.com”

[nate.koenig]

I tried that, but, the REFER isn't sent out and in the logs I see:

071324: May 16 10:37:07.041 EDT: //2851/F387BD7D9E59/SIP/Error/sipSPISaveReferParams:

No dialpeer passed from application for xfer

I created a uri list matching that pattern and applied it to a dial-peer as well... but... I believe it should be using the same dial-peer as without specifying the host since it is just REFER'ing it.

[yawming]

A simple question we we have destination 1234567@abcd.com then we are expecting the call to go to abcd.con right ?

And the number 1234567 should be in abcd.com

you said:

"The problem is that the "x.x.x.x" (host portion of the refer-to) is the egress interface of the same gateway, instead of the carrier IP. The carrier is receiving the REFER, accepting it, then sending the call back to the gateway (since the x.x.x.x IP is the gateway.)"

Which number is right but domain in the your VG that doesn't make sense to me. In my opinion we should have a dialpeer only handle the egress number/