[Kamailio-Users] 30x Redirect / Forward, even questions

Samuel Muller sml at 720.fr
Tue Jan 26 13:05:23 CET 2010


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 at 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 at 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 at sip_proxy;user=phone>;tag=91515579fff6b8d1i0.
>>> #From: <sip:A at pstn_gw1;user=phone>;tag=16627-UI-00020cf3-54eea92c4.
>>> #Call-ID: 16627-RO-00020cf2-4186e9762 at 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 at sip_proxy>.
>>> #Diversion: "B" <sip:B at sip_proxy>;reason=unconditional.
>>> #Server: Linksys/SPA942-6.1.3(a).
>>>
>>> DBG:uac_redirect:shmcontact2dset: adding contact <sip:C at sip_proxy>
>>> dest set : Contact: sip:B at ip_B, <sip:C at 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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/users/attachments/20100126/c50d26f9/attachment.htm>


More information about the Users mailing list