VoIP Mailing List Archives

[sicfslist at gmail.com]

Hello:

I asked this on IRC yesterday and I think I confused everyone involved.  So I apologize in advance here for reposting the question and if I wasted anyone's time.

So here is the issue I'm having.  I'm trying to use FS as a redirect server (specifically to serve up LNP queries via 302 redirects).  But I'm having an issue where based on the string in the dialplan FS will respond with a 500 internal error message instead of a 300 redirect.

The call flow should be this:
   -- remote party sends an Invite to my FS instance
   -- FS should respond with a 302

The following works as expected (FS will send a 302 when it receives an Invite):

<action application="redirect" data="sip:${destination_number}@${network_addr};rn=${rn};npdi=yes"/>

However if I do this (which is the way the response should look) FS will respond with a 500 internal server error:

<action application="redirect" data="sip:${destination_number};rn=${rn};npdi=yes@${network_addr}"/>

So the issue is the placement of the user params .... if they are before the @ FS will send a 500 internal server error ... if they are after the @ FS will send a 302.  Unfortunately placing the user params after the @ doesn't quite conform to the way other devices expect to receive the 302 for this application.

Any help would be greatly appreciated.

Shelby

PS ... hats off to the author of mod_memcache ... that is extremely useful!

[brian at freeswitch.org]

On Oct 1, 2009, at 9:27 AM, Shelby Ramsey wrote:

[anthony.minessale at g...]

you left too fast.

1) I told you if you put <> around the sip uri it will work.
2) I told you I added a patch in tree to add one for you if it's not supplied so update to trunk.


On Thu, Oct 1, 2009 at 9:27 AM, Shelby Ramsey <sicfslist@gmail.com (sicfslist@gmail.com)> wrote:

[sicfslist at gmail.com]

Tony,

Once again ... you are the man!

I'll try this right now.

SDR

[sicfslist at gmail.com]

Brian,

Thanks for the info.  I guess I'll go read section 19.1 of RFC3261 again.  I do think the above has a valid host portion (I don't think the port is required).

I'm not so sure that putting params in the user portion of the uri is valid (from the RFC it states sip:user:password@host:port;uri-parameters?headers).

The issue is that in the real world this is done all the time .... SIP is fantastic

Shelby


On Thu, Oct 1, 2009 at 9:42 AM, Brian West <brian@freeswitch.org (brian@freeswitch.org)> wrote:

[brian at freeswitch.org]

I wouldn't go that far! You might be able to get away with it on
the patch tony wrote but not sure.

/b

On Oct 1, 2009, at 10:59 AM, Shelby Ramsey wrote:

[sicfslist at gmail.com]

Just to confirm ... works like a champ.

Thanks again!!!

[tculjaga at gmail.com]

anyhow, this is how it works for me!




<include>
  <context name="public">

      <extension name="LNP">
                <condition field="destination_number" expression="(^300000)(.*)">
                      <action application="lnp_getprefix" data="in $2, out reroutingalias"/>
                        <action application="redirect" data="sip:${[url=http://reroutingalias}@10.4.13.11:5060]reroutingalias}@10.4.13.11:5060[/url]"/>
                </condition>
        </extension>


        <extension name="LBS">
                <condition field="destination_number" expression="(^300010)(.*)">
                        <action application="lbs_getpublicphone" data="in ${caller_id_number}, in $2, out reroutingalias"/>
                        <action application="redirect" data="sip:${[url=http://reroutingalias}@10.4.13.11:5060]reroutingalias}@10.4.13.11:5060[/url]"/>
              </condition>
        </extension>

        <extension name="CPS">
                <condition field="destination_number" expression="(^300020)(.*)">
                        <action application="cps_verifyphone" data="in ${caller_id_number}, in $2, out radiusacc"/>
                 </condition>
              <condition field="radiusacc" expression="1">
                            <action application="redirect" data="sip:${[url=http://caller_id_number}@10.4.13.11:5060]caller_id_number}@10.4.13.11:5060[/url]"/>
                            <anti-action application="respond" data="403 Forbidden"/>
                </condition>
        </extension>



   <extension name="ServiceLookup">
      <condition field="destination_number" expression="(^300030)(.*)">
         <action application="lookup_service_destination" data="in ${caller_id_number:6:16}, in ${caller_id_number:0:6}, in $2, in $
1, in ${network_addr}:5060, out red_contact, out authResult"/>
         <action application="log" data="INFO ######################## ServiceLookup ########################\n"/>
         <action application="log" data="INFO ######################## contact = '${red_contact}' ##############\n"/>
         <action application="log" data="INFO ######################## CallerNum = '${caller_id_number:6:16}' ##########\n"/>
         <action application="log" data="INFO ######################## RADIUS auth = '${authResult}' ##########\n"/>

         <action application="execute_extension" data="doRedirect XML public"/>
        </condition>
   </extension>


   <extension name="doRedirect">
      <condition field="destination_number" expression="^doRedirect$"/>
      <condition field="${authResult}" expression="^0$|^60$">
         <action application="log" data="INFO ######################## RADIUS auth OK!!!' ##########\n"/>
         <action application="redirect" data="${red_contact}"/>
         <anti-action application="log" data="INFO ######################## RADIUS auth NOK!! ##########\n"/>
         <anti-action application="respond" data="403 Forbidden"/>
      </condition>

   </extension>


  </context>
</include>

On Thu, Oct 1, 2009 at 6:18 PM, Shelby Ramsey <sicfslist@gmail.com (sicfslist@gmail.com)> wrote: