Chav,

We recently / are still going through the same process (in order to route on LRN) vs NPANXX or LATA based routing.  Here was the best way that we came up with to do it:
  -- we use xml_curl exclusively for routing decisions
  -- so in the cgi script that xml_curl hits one of the things it can (and does based on certain parameters) is fire off a url to another LNP server that we built
  -- the LNP server actually does the dip (either from a cache) and returns the info

We felt this was much better for a few reasons:
  -- caching the LNP data for a 24 hour period would save us in excess of $100k a year
  -- having a specialized mechanism to do this was much easier to implement for the cgi process than supporting 302 redirects directly on the FS boxes was much easier (which just wasn't possible with the cgi mechanism)
  -- every LNP provider returns 302's slightly different ... so we didn't want to have to reinvent the wheel on the FS machines if we ever wanted to add redundancy or switch providers

Guess it all depends on your config ... but this was the easiest and most cost-effective means for us to implement.


On Sat, Dec 13, 2008 at 6:38 PM, Chav Paskov <chavpaskov@shaw.ca> wrote:
Brian West wrote:
> Chav,
> Once the 302 is received by FreeSWITCH it will follow it to the
> contact listed in the 302.  What else are you needing to do?
>
> /b
>
> On Dec 13, 2008, at 2:24 PM, Chav Paskov wrote:
>
>> *User-Agent: eXosip/3.1.0^M
>> Content-Length:
>>
>>
>> my question is:
>>
>> Is it possible to send the call to z.z.z.z , receive the SIP 302 ,
>> process the data in Contact field  and redirect to the new destination
>> contained in *Contact: <sip:2145551234@64.112.188.84>;npdi^M
>> *without closing the session.
>> i red something about   <action application="set"
>> data="continue_on_fail=true"/>  but i'm not sure  how to use it.
>>
>> Any ideas on this matter  will be highly appreciated.
>> Best Regards
>> Chav
>>
>
> ------------------------------------------------------------------------
Thanks Brian,

probably i should have explained it in more details.
this whole thing started as an attempt to  implement lata ocn /local
number portability/ instead of  pure per destination routing.
At the moment i have a access to  a service provider  who does
"dipping"  and returns  the  LATA OCN  data associated with  any dialed
destination number. it is returned as Contact:  and Content-length:
fields in 302 message.

in other words:

1. i'm sending to this provider let say - 2025556666  as a destination
number.
2. they do the dipping  and will return to me  either the new dest #  if
2025556666 has been ported or if it was not
in content-length field they'll send  lata, ocn  and state and 10 digits
number.
3. once received i have to  compare the received lata , ocn and state
date with  a compiled  rate deck / blended from 5 different vendors/
and pick the lowest rate - effectively building  LCR based on LATA OCN
STATE info.

Hope this will help to clear the picture.