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 <
mico...@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 <
> mico...@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-4186e9...@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/
>
>
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
