[Freeswitch-users] SIP REFER - URI Parameters

[Phil Dunks]

Hi Anthony

I have not been able to get the URI params from the the REFER message (Refer-To header), copied into the request URI of the INVITE.

However, I have solved my problem a different way.

I have written the parameters to a custom header, and then modified the dial plan on the conference nodes to look there instead.

I achieved this by adding the following code to sofia.c :: sofia_handle_sip_i_refer

            if (refer_to->r_url->url_params) {
                switch_channel_set_variable(b_channel, "sip_h_X-FS-Refer-Params", refer_to->r_url->url_params);
            }

I put this at line 7702 (current master 09d66c7ae2c970f922226dfb72e66c0eb33c7d02), just before :

switch_ivr_session_transfer(b_session, exten, NULL, NULL);

Do you think this is an acceptable solution and would you consider committing it, or have you got a better idea?

Thanks

Phil



Begin forwarded message:

> From: Phil Dunks <phil.dunks at netdev.co.uk>
> Subject: Re: SIP REFER - URI Parameters
> Date: 3 March 2014 12:53:55 GMT
> To: freeswitch-users at lists.freeswitch.org
> 
> Hi Anthony.
> 
> Thanks for looking at this and exposing the sip_refer_to_params variable.
> 
> I’ve updated to head, and can see the change in sofia.c.
> 
> Sorry for being dense, but I’ve not had much luck getting the uri params from the REFER to the INVITE.
> 
> My dial plan is very simple.
> 
> <include>
>  <extension name="public_did">
>   <condition field="destination_number" expression="(\d+)">
>     <action application="set" data="proxy_media=true"/>    		
>     <action application="bridge" data="sofia/gateway/${distributor(load-balance ${sofia(profile external gwlist down)})}/$1"/>
>    </condition>
>  </extension>
> </include>
> 
> I tried appending ${sip_refer_to_params} to the bridge uri, but no luck. 
> 
> It seems the REFER is handled by sofia_handle_sip_i_refer in sofia.c which sets up a blind transfer.
> 
> I’ve been staring at sofia.c all morning - but not worked out what I need to do.
> 
> Please could you shed some light on how to proceed.
> 
> Thanks again,
> Phil
> 
> 
> From: Anthony Minessale <anthony.minessale at gmail.com>
> Subject: Re: [Freeswitch-users] SIP REFER - URI Parameters
> Date: 28 February 2014 19:15:11 GMT
> To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
> Reply-To: FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
> 
> 
> Added a patch to expose sip_refer_to_params vars.  See latest HEAD.
> 
> 
> On Fri, Feb 28, 2014 at 11:17 AM, Phil Dunks <phil.dunks at netdev.co.uk> wrote:
> Hi Guys
> 
> I’m trying to use FS (1.5.8b from last week) as an SBC and load-balancer (using mod_distributor).
> 
> It is load balancing between several FS conference nodes.
> 
> It’s working a treat, apart from one scenario :
> 
> Say conference xyz is already running on conf-node-1.
> 
> Next incoming call is sent to conf-node-2, pin is collected, and conference xyz is identified as the required conference.
> 
> Conf-node-2 checks presence, and sees the conference is already running on conf-node-1, and does a deflect.
> 
> We add some query params to the refer-to URI to tell conf-node-1 not to collect the pin, but put the caller straight into the conference.
> 
> e.g <action application="deflect" data=“sip:1234 at 10.1.1.2;conf=xyz" />
> 
> In the REFER I can see the params :
> 
> Refer-To: <sip:1234 at 10.1.1.2;conf=xyz>
> 
> But they are not present on the request URI or To header in the INVITE to conf-node-1.
> 
> So conf-node-1 requests the PIN again.
> 
> Is there any way I can pass this info to the other conference node by using the REFER?
> 
> Thanks for your help.
> 
> Phil
> 



Phil Dunks
Principal Engineer
NetDev Ltd  & Drum Web Meetings 
Office : +44 1273 936105   
Mobile : +44 7515 385465
www.netdev.co.uk
www.thisisdrum.com
Registered in England and Wales 
Company Number 04741258
 

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