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/

Hello Daniel,

sorry to not reply faster, even works to do.

so, I tried other ways to forward : call forward unconditional, backup, busy, and non answer + time pre-defined. I created a route with t_check_status("") for 4xx replies, and use an AVP to rewrite correctly the stuff.

here's a sample :

if (t_check_status("408")) { if (is_avp_set("$avp(s:callee_cfbk)/s")) { xlog("L_INFO", "callee can't be reached, forward to $avp(s:callee_cfbk)"); avp_copy("$avp(s:callee_cli)/s", "$avp(s:callee_fwd)/s"); avp_delete("$avp(s:callee_cli)/g"); avp_copy("$avp(s:callee_cfbk)/s", "$avp(s:callee_cli)/s"); avp_pushto("$ru/username", "$avp(s:callee_cfbk)"); avp_copy("$avp(s:callee_realm)/s", "$avp(s:callee_fwd_realm)/s"); route(27); # proper accounting for forward setflag(9); # flag to stamp "forwarded"

# diversion header: if (!search("Diversion:.*")) { xlog("L_INFO", "append the diversion header"); add_diversion("backup;privacy=none;counter=1"); } else { xlog("L_INFO", "-> 403: diversion header already found, forbidden to forward one more time"); sl_send_reply("403", "Forbidden"); exit; } route(11); # new callee infos searching exit; } else { xlog("L_INFO", "-> 408: request timeout"); sl_send_reply("408","Request Timeout"); exit; } }

I think I can't take in charge all the ways the constructors use forward systems (diversion, rewrite, redirect, forward, ...). I centralized that in my IS directly and told my customers to use a control panel instead of directly in their ip phone - they're not really happy but ... they're a few people in the case where the phones are directly connected to my sip proxies. Others wants a small ipbx, who does the entreprise stuff.

Do you think that for that kind of end-user (no ipbx), a SBC in my voice edge architecture could do the job better ?

thanks a lot,

.Sam.

On Thu, Jan 14, 2010 at 11:31 AM, Daniel-Constantin Mierla < miconda@gmail.com> wrote:

Hello,

On 1/13/10 10:59 PM, Samuel Muller wrote:

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).

Can you grab a sip trace and send it of an entire scenario (from initial invite). Would help to understand what is happening and what is not a clean way.

Cheers, Daniel

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/