How to pass varibles from sip.conf during blind transfer?

Similar to I am seeking a way to take variables applied a SIP peer performing a blind transfer and apply them to the newly opened channel.

The variables of importance are stored using setvar for each peer inside sip.conf. Adding a _ or __ prefix to each variable doesn’t seem to provide any satisfaction. Of course, like it says in the issue tracker an attended transfer works just fine because it seems the outbound call is treated like any other call generated from that sip peer. It’s just the blind transfer that plays funny because it appears to simply toss it into my outbound context without allowing me to set any variables prior.

Running the latest stable 1.8 but am more than willing to explore 10 betas if needed. At this point the only simple fix to this appears to be stashing the needed information within a database using a predictable id to retrieve it. Then upon every outbound call check the database for the record to retrieve and set the needed variables. But really, there must be a more streamlined way to do this… right?

Any and all advice greatly appreciated. Thank you in advance :smile:

I’m not sure I know of a technique either way, but there are two types of transfer in Asterisk, when using SIP, and there are quite a lot of differences in their behaviour. One is a true SIP transfer, and the other a features.conf transfer.

Also, it is conceivable that, with SIP transfers, some transferring user agents actually use the attended transfer procedure, and set up the outgoing call before disposing of the incoming one, which would mean that the dial plan had been run for the destination before Asterisk was even aware that there was a transfer in progress.

You got it. This is where I am running into trouble because I need to detect which SIP peer is initiating the blind transfer so the correct minutes can be deducted from the right account. As of now it’s a free ride for anyone who initiates a blind transfer.

Some app dev’s use the CNAM field to pass app-specific data through the callflow (e.g. callerid(name)=""). This may (or may not) be an option for your application.