Hello Daniel,

thanks for your answer.

I'm using route(3) to find the new callee, using a radius request (no DB for this kind of request).
Using t_relay(), I just forward the request without try to know if the new callee is one of my own user, isn't it ?
In an operator way, I've to control the "who's who" ...

I took this part of config in the sipwise tool :

after the get_redirect in the failure_route() :

$avp(s:fwdtmpds) = $ds;
avp_subst("$avp(s:fwdtmpds)", "/.*(sip:.+@[^:;>]+).*$/\1/");
avp_pushto("$ru", "$avp(s:fwdtmpds)");
# flag call fwd (for acc, permissions, rtp proxying, ...)
setflag(17);
append_branch();
t_on_branch("1");
# route to find the new callee
route(3);
exit;
}

It works, but it's not a clean way, and really difficult to replace good avps, determinates rtp proxying (one way audio only when the UAC who forwarded the call is behind nat), delete few double insertion of P-Hints. Accouting is really hard to clean too (who pays the first call pstn -> phone, and who's paying call to redirected number, then consider all of them as only one call for billing system).

With SIP over TCP, it doesn't work (it creates two pinholes, and I've errors on the debug logs). I'm afraid to test all of this stuff with TLS ...

Do you think that a dedicated redirect server is a better way to take in charge call forwards ? so I could use the t_relay() function.
Sure the best practice is to use SBC, IPBX, media servers and/or real class5 softswitch to do all the advanced voice services, but in some case ...

Does someone developped a sip-i module eventually ?
it could be a nice feature for operators who are blocked by the call forwards systems, few parts of ISUP must be taken in charge sometimes, like when you have to forward a call to a PSTN gateway interconnected in SS7 with a tier1-operator.

Cheers,

.Sam.

On Wed, Jan 13, 2010 at 12:44 PM, Daniel-Constantin Mierla <miconda@gmail.com> wrote:

Hello,

On 1/11/10 1:56 PM, Samuel Muller wrote:

Hello all,

I've questions 'bout the redirect/forward with 30x requests.

Actually, it does not work, it seems the uac redirect module doesn' t use the new contact for the new invite.

simple schema : pstn gw -> kamailio -> linksys -> call forward unconditionnal to another pstn number -> kamailio -> gw pstn

the 302 as seen with ngrep tool :

#SIP/2.0 302 Moved Temporarily.
#To: <sip:B@sip_proxy;user=phone>;tag=91515579fff6b8d1i0.
#From: <sip:A@pstn_gw1;user=phone>;tag=16627-UI-00020cf3-54eea92c4.
#Call-ID: 16627-RO-00020cf2-4186e9762@pstn_gw1.
#CSeq: 81990 INVITE.
#Via: SIP/2.0/UDP sip_proxy;branch=z9hG4bK0f0c.22989b87.1.
#Via: SIP/2.0/UDP pstn_gw1:5060;rport=5060;received=ip_pstn_gw1;branch=z9hG4bK-25EA-243F3.
#Record-Route: <sip:sip_proxy;lr=on;ftag=16627-UI-00020cf3-54eea92c4;did=f65.bcc44f06>.
#Contact: <sip:C@sip_proxy>.
#Diversion: "B" <sip:B@sip_proxy>;reason=unconditional.
#Server: Linksys/SPA942-6.1.3(a).

DBG:uac_redirect:shmcontact2dset: adding contact <sip:C@sip_proxy>
dest set : Contact: sip:B@ip_B, <sip:C@sip_proxy>;q=0.01
contact $ct: <sip:pstn_gw1:5060>

the second pstn gateway received a request to B, and not C (so it creates a loop through pstn ...).

in my config :

loadmodule "uac.so"
modparam("uac", "rr_store_param", "vsf")
modparam("uac", "from_restore_mode", "auto")

loadmodule "uac_redirect.so"
modparam("uac_redirect", "default_filter", "accept")
modparam("uac_redirect","bflags", 1)

loadmodule "diversion.so"

failure_route[2]
{
       setdebug(4);

       if (t_check_status("301|302"))
       {
               route(26)     # acc fwd
               $avp(s:acc_status) = "cfu";

               if (!get_redirects("2:1"))
               {
                       xlog("L_NOTICE", "failed to extract contact info from 30x header");
                       route(10);      # stop rtp
                       t_reply("480", "Temporarily Unavailable");
                       exit;
               }

               # flag 3xx status, open a new branch and back to find the new callee
               setflag(28);
               append_branch();
               t_on_branch("1");
               route(3);     # search the new callee
               setdebug();
               exit;
       }

       t_on_branch("1");
       setdebug();
       route(3);       # find callee
       route(12);      # local outbound
       route(10);      # stop rtp
}

I'm using lcr module to route calls, kamailio v. 1.5.3.

I've another question, is the 30x always considered as a failure_route ?

Any help and/or explanations about the tricks would be really appreciated ... thanks,

as I can see from you comments, in failure_route you get the contacts from 30x and append branch then call route(3) which is find callee -- what is that, is it appending another branch? Practically after append branch you should just do relay.

Cheers,
Daniel

--
Daniel-Constantin Mierla
* http://www.asipto.com/

-- 
Daniel-Constantin Mierla
* http://www.asipto.com/