On 06/15/2011 08:09 PM, Herve Couplet wrote:
Kamailio is replying with a SIP/2.0 478 Unresolvable destination
(478/TM). I got the error from t_relay_to but the drop() didn't
prevent the 478 to be sent.
Oh, I see. This is an internally-generated error from TM.
There is probably not much you c
Already tried that.
Documentation on t_relay from 1.5 says :
*0x02* - do not internally send a negative reply in case of forward failure
(due internal error, bad RURI, bad message, etc). When a forward failure
occurs, no SIP request is relayed and therefore no negative reply or timeout
will show u
You can catch and drop replies in an an onreply_route or failure_route.
if(t_check_status("478"))
exit;
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
On Jun 15,
Hi,
I had a setup with an old version where I used the function
t_relay_to("0x02").
Following the 3.1 documentation, flag :
* 0x02* - do not generate reply on internal error (NOTE: has no effect
anymore)
I used that function as a workaround with a pbx that stop to register when
it receive an
Hi
After reading the modules pike, pipelimit, etc. I wanted to know what
measures can be used in the proxy, because like me, there will be more
people interested ;-).
We see that the module pike is a good security measure, but for users
with many channels, we used the configuration of users
sight ! :-(
thank you Klaus, We just start testing the 3.1.4 but until the Labs releases
will take some time
O
On Jun 15, 2011, at 12:19 PM, Klaus Darilion wrote:
> I tried it in normale route and failure route, it works (at least in Kamailio
> 3.1)
>
> regards
> klaus
>
> On 15.06.2011 1
I tried it in normale route and failure route, it works (at least in
Kamailio 3.1)
regards
klaus
On 15.06.2011 15:14, Omar wrote:
BEFORE VAR
A#===__IN
FAILURE_ROUTE :::==> RURI=+1404345
VAR A
###
Hi Daniel,
Thanks.. Is there any side effects if we increase the wt_timer to 32secs to
match with the INVITE transaction timer?
regards,
Jijo
On Wed, Jun 15, 2011 at 3:52 AM, Daniel-Constantin Mierla wrote:
> Hello,
>
>
> On 6/15/11 6:16 AM, Jijo wrote:
>
>
>
> Hi All,
>
> In an INVITE transac
2011/6/15 Iñaki Baz Castillo :
>> Unfortunately this wasn't possible with Kamailio <=1.5. Have you tried 3.x
>> with equal 'Order' but different 'Preference' or just with different 'Order'?
>
> Not yet, but I'll do it and comment here :)
Kamailio just takes one of the NAPTR records, even if the fi
Hi,
Kamailio is just a SIP-Proxy, so it has no support for mixing Audio.
Carsten
2011/6/15 Mino Haluz :
> Hi,
>
> does kamailio support conference calls or it has to be implemented in
> some B2BUA ?
> If it is supported, what are the requirements (modules etc.).
>
> Thanks,
> Mino
>
> __
Hi,
does kamailio support conference calls or it has to be implemented in
some B2BUA ?
If it is supported, what are the requirements (modules etc.).
Thanks,
Mino
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists
2011/6/15 Alex Hermann :
>> However I've seen other SIP stacks also performing failover by taking
>> next NAPTR records. But indeed, RFC 2915 does not mandate it, instead
>> it says MUST NOT. So you are right.
>
> I forgot about a discussion i had about this issue a few years ago with a
> customer
BEFORE VAR
A#===__IN
FAILURE_ROUTE :::==> RURI=+1404345
VAR A
#===__IN
FAILURE_ROUTE :::==> rU = +1404345 VAR A = 8 VAR B = 0
AFTER VAR
On Wednesday 15 June 2011, Iñaki Baz Castillo wrote:
> 2011/6/9 Iñaki Baz Castillo :
> > 2011/6/9 Alex Hermann :
> > 2) About your quoted text, indeed RFC 2915 says that. But that just
> > means that, an application (in this case a SIP client) must take
> > *first* the valid NAPTR record with bette
2011/6/9 Iñaki Baz Castillo :
> 2011/6/9 Alex Hermann :
>> The way I read rfc2915, there is no failover mechanism. The application pick
>> the first target that it supports and uses that. There is no mention of
>> trying
>> other records afterwards. Matching/finding NAPTR records stops once the fi
Hello,
On 6/13/11 7:05 AM, Omar wrote:
In Kamailio 1.4.3
I have the following scenario:
$var(a) = 0
$var(b) = 0
$var(a) = $(tU{s.len});
$var(b) = $var(a) - 5;
xlog(" $var(b)");
the result $var(b) is always the same as $var(a)
should i check if some specific module is loaded?
the debugs do
On Wed, 2011-06-15 at 09:47 +0200, Daniel-Constantin Mierla wrote:
>
> On 6/14/11 1:06 PM, Evgeniy Spinov wrote:
> > On Mon, 2011-06-13 at 12:12 +0200, Daniel-Constantin Mierla wrote:
> >
> > Ok, still unsolved problem.
> >
> > I've changed failover part of the script to use ds_next_dst(). It does
2011/6/15 Daniel-Constantin Mierla :
> One more question here, since I remembered about it -- have you played with
> dns-based load balancing done by proxy so far? This was new for kamailio in
> 3.x...
I started playing a bit and got good results, but want to make further tests.
--
Iñaki Baz Cas
Hello,
On 6/15/11 6:16 AM, Jijo wrote:
Hi All,
In an INVITE transaction, no ACK from A party and B party continue
retransmission of 200 OK. I have observed that kamailio is not passing
the retransmitted 200 OK message from B party to the
Application(script) after 3 seconds. Instead kamaili
One more question here, since I remembered about it -- have you played
with dns-based load balancing done by proxy so far? This was new for
kamailio in 3.x...
Thanks,
Daniel
On 6/13/11 3:55 PM, Daniel-Constantine Mierla wrote:
On Jun 13, 2011, at 2:48 PM, Iñaki Baz Castillo wrote:
2011/6/
On 6/14/11 1:06 PM, Evgeniy Spinov wrote:
On Mon, 2011-06-13 at 12:12 +0200, Daniel-Constantin Mierla wrote:
Ok, still unsolved problem.
I've changed failover part of the script to use ds_next_dst(). It does
what it should and signalization works fine - calls are being connected.
However I've
21 matches
Mail list logo
