Hi Sebastian,
thanks for reporting back the results. On a second thought I updated the
patch a bit to use a local variable for backup in order to allow nested
execution of event_route[tm:local-request] which can be triggered by
sending local generated requests. The commit was:
http://git.sip
Hi Daniel,
thanks for looking into it again.
On Mon, Aug 1, 2011 at 2:51 PM, Daniel-Constantin Mierla
wrote:
> thanks for further investigation. Indeed, the avps were not backed
up/restored when sending self-generated request.
>
> I just committed a patch to tm module in master branch. If you ca
Hi Sebastian,
thanks for further investigation. Indeed, the avps were not backed
up/restored when sending self-generated request.
I just committed a patch to tm module in master branch. If you can give
it a try and report if it works ok, then I will backport to 3.1.
Cheers,
Daniel
On 7/28/
Am 28.07.2011 16:57, schrieb Sebastian Damm:
> We try to to measure Post Dial Delay when sending calls out to the
> carrier, and we monitor the time differences for one call each time
> Kamaiio is passed. That's all the other process does. So we send
> handcrafted SIP packages with the needed inf
Hi Daniel, Hi Klaus,
after hours of searching I think we found the problem. This is what our
route that actually sends out the packets looks like:
route[2] {
xlog("... START OF ROUTE
2\n");
xlog("AVP LEG_
Hi Sebastian,
On 7/15/11 11:42 AM, Sebastian Damm wrote:
Hi,
On Fri, Jul 15, 2011 at 9:02 AM, Klaus Darilion
wrote:
The named reply routes are only executed if t_on_reply() was called for
the request. This reply route will be executed after the default
reply-route. It is triggered by tm modu
Hi,
On Fri, Jul 15, 2011 at 9:02 AM, Klaus Darilion
wrote:
> The named reply routes are only executed if t_on_reply() was called for
> the request. This reply route will be executed after the default
> reply-route. It is triggered by tm module.
I just inserted a new reply_route, which just print
Am 14.07.2011 20:10, schrieb Daniel-Constantin Mierla:
> In 1.5 there was an option in the tm module to control AVP behavior in
> replies, but that doesn't exist anymore, I even found a mailing list
> post from Daniel where he explained that all AVPs I set in route are
> also available in onreply
Hi Sebastian,
On 7/14/11 7:01 PM, Sebastian Damm wrote:
Hi,
I'm still fighting problems in our Kamailio 1.5 to 3.1 migration.
Right now I'm stuck with a strange behavior of AVPs in my dialplan.
I set a lot of AVPs for accounting in the route directive, and I just
inserted an avp_print() s
Hi,
I'm still fighting problems in our Kamailio 1.5 to 3.1 migration. Right now
I'm stuck with a strange behavior of AVPs in my dialplan.
I set a lot of AVPs for accounting in the route directive, and I just
inserted an avp_print() statement right before t_relay() is called, all
values are set. T
10 matches
Mail list logo
