[Kamailio-Users] 30x Redirect / Forward, even questions
sml at 720.fr
Tue Jan 26 13:05:23 CET 2010
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 :
xlog("L_INFO", "callee can't be reached, forward to
route(27); # proper accounting for forward
setflag(9); # flag to stamp "forwarded"
# diversion header:
xlog("L_INFO", "append the diversion header");
xlog("L_INFO", "-> 403: diversion header already found, forbidden to
forward one more time");
route(11); # new callee infos searching
xlog("L_INFO", "-> 408: request timeout");
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,
On Thu, Jan 14, 2010 at 11:31 AM, Daniel-Constantin Mierla <
miconda at gmail.com> wrote:
> 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, ...)
> # route to find the new callee
> 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
> 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.
> On Wed, Jan 13, 2010 at 12:44 PM, Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>> 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
>>> #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"
>>> 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");
>>> # flag 3xx status, open a new branch and back to find the
>>> new callee
>>> route(3); # search the new callee
>>> 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.
>> Daniel-Constantin Mierla
>> * http://www.asipto.com/
> Daniel-Constantin Mierla
> * http://www.asipto.com/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sr-users