Hi Alex,
This works fine, undoubtedly it's a better solution.
Thank you very much!
Julia.
On Tue, Sep 20, 2016 at 11:28 AM, Alex Hermann wrote:
> On maandag 19 september 2016 13:34:07 CEST Julia Boudniatsky wrote:
> > I send INVITE via uac_send_req() and receive "183" and "200"responses.
> > On
Hello,
thank you for reply.
I need to set some variable with sdp from 183.
I solved it with sending uac request to different kamailio local port
(before sending to destination)
and specifying onreply_route for INVITEs, received in this port.
On Tue, Sep 20, 2016 at 10:38 AM, Daniel-Constantin Mie
On maandag 19 september 2016 13:34:07 CEST Julia Boudniatsky wrote:
> I send INVITE via uac_send_req() and receive "183" and "200"responses.
> Only "200" appears in the log of event_route[uac:reply].
>
> Is event_route[uac:reply] executed only for final responses?
You should be able to set an onr
Indeed, only the final response gets to the even_route, this is because
of the callback used from tm module.
Maybe, if you can offer more details about what you need from 183, we
can provide some hints if it's possible and how.
Cheers,
Daniel
On 20/09/16 07:27, Julia Boudniatsky wrote:
> I foun
I found in the module uac documentation:
"6.1. event_route[uac:reply]
Event route executed for the* final* reply to the request set with
uac_req_send().
Thanks,
Julia
On Mon, Sep 19, 2016 at 1:34 PM, Julia Boudniatsky
wrote:
> I send INVITE via uac_send_req() and receive "183" and "200"respon
I send INVITE via uac_send_req() and receive "183" and "200"responses.
Only "200" appears in the log of event_route[uac:reply].
Is event_route[uac:reply] executed only for final responses?
Thank you,
Julia
___
SIP Express Router (SER) and Kamailio (Open
Hello,
event_route should be compatible with request_route in most of the
cases, if not stated otherwise. However, there is usually a faked
request processed, generated internally by kamailio, without a purpose
to be routed out, but only to be safe in running various functions.
You can eventually
Hello,
With respect to *_route blocks in kamailio configs, I gather that
event_route is the newest type of route in the config vocabulary. However,
many modules have functions that specifically state that they work within
certain routes, like REQUEST_ROUTE and FAILURE_ROUTE, with the implication
On 01/10/14 15:23, Julia Boudniatsky wrote:
I understand my mistake.
It's working when message is broken.
I wanted to use it for bad SDP.
We have a problem with SDP from some users.
In error of parsing SDP on log printed only wrong part of SDP
and correlation to call is very difficult.
I see
I understand my mistake.
It's working when message is broken.
I wanted to use it for bad SDP.
We have a problem with SDP from some users.
In error of parsing SDP on log printed only wrong part of SDP
and correlation to call is very difficult.
Thank you,
Julia
On Wed, Oct 1, 2014 at 3:54 PM, Da
Hello,
iirc, the event route is executed only when the sip request is so broken
not to make it till config file execution.
In your previous email on this topic that I had in mind to reply but got
forgotten, you refer to From. That is not part of the basic parsing
(again, iirc), you should ca
Hello,
I try to use event_route[core:receive-parse-error] in 4.1.6
event_route[core:receive-parse-error] {
xlog("L_WARN", "Event-parse-error: $rm from
$avp(inc_carrier)/n$mb/n");
}
When core parse error occurs , *log message is not printed*.
What is wrong?
Thank you,
Julia
_
Hello,
I try to use an
event_route[core:receive-parse-error] {
xlog("L_WARN", "Event-parse-error:
$rm from $avp(inc_carrier)/n$mb/n");
}
corelog=1
debug=0
kamailio 4.1.6 from source
Wrong header "From" is simulated by SIPP.
In log I recei
Hello,
I try to use an
event_route[core:receive-parse-error] {
xlog("L_WARN", "Parse-error: $rm from
$avp(inc_carrier)/n$mb/n");
}
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users ma
t: Re: [SR-Users] event_route xhttp:request
Hello,
can you check to be sure that event_route is not in a disable part of
config by #!ifdef conditions?
Cheers,
Daniel
On 16/08/14 02:33, Kamrul Khan wrote:
i am trying to connect to my kamailio through websocket. I added
the below code
Hi, Found the issue. I needed to configure, tcp_accept_no_cl=yes. Working fine
now.
From: do...@live.com
To: mico...@gmail.com; sr-users@lists.sip-router.org
Subject: RE: [SR-Users] event_route xhttp:request
Date: Mon, 18 Aug 2014 21:38:18 +0600
Hey, thanks for your reply. Do I need
@lists.sip-router.org
Subject: Re: [SR-Users] event_route xhttp:request
Hello,
can you check to be sure that event_route is not in a disable part
of config by #!ifdef conditions?
Cheers,
Daniel
On 16/08/14 02:33, Kamrul Khan wrote
Hello,
can you check to be sure that event_route is not in a disable part of
config by #!ifdef conditions?
Cheers,
Daniel
On 16/08/14 02:33, Kamrul Khan wrote:
i am trying to connect to my kamailio through websocket. I added the
below code in my config file:
event_route[xhttp:request] {
i am trying to connect to my kamailio through websocket. I added the below code
in my config file:
event_route[xhttp:request] { xlog("websocket connection request");
set_reply_close(); set_reply_no_connect(); if (ws_handle_handshake())
{ exit;
Daniel-Constantin Mierla writes:
> well, $branch is actually not dealing with r-uri branch in
> request_route. branch_route deals with current branch in tm, which can
> be an additional branch to the r-uri and $branch() with proper index
> should work to retrieve the details. But it might not b
On 18/04/14 18:03, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
The $branch(...) var might need to be extended for instance. Also, not
sure it gets the right values in branch_route... but it is a way to try
if you haven't done it already.
according to wiki, $branch only deals with add
Daniel-Constantin Mierla writes:
> The $branch(...) var might need to be extended for instance. Also, not
> sure it gets the right values in branch_route... but it is a way to try
> if you haven't done it already.
according to wiki, $branch only deals with additional branches, not the
main bran
On 18/04/14 17:37, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
As an option to implement now, try using hash table to store attributes
using keys like:
$sht(t=>$T(id_label)::$T(id_index)::$T(branch_index)::ru) = $ru;
$sht(t=>$T(id_label)::$T(id_index)::$T(branch_index)::du) = $du;
.
Daniel-Constantin Mierla writes:
> As an option to implement now, try using hash table to store attributes
> using keys like:
>
> $sht(t=>$T(id_label)::$T(id_index)::$T(branch_index)::ru) = $ru;
> $sht(t=>$T(id_label)::$T(id_index)::$T(branch_index)::du) = $du;
> ...
>
> Then use them to create
Daniel-Constantin Mierla writes:
> I pushed a patch to mater, can you try it? If ok, you can backport it
> as you need.
i tried and now $T(branch_index) is ok also in branch-failure route.
thanks,
-- juha
___
SIP Express Router (SER) and Kamailio (Op
I pushed a patch to mater, can you try it? If ok, you can backport it as you
need.
Cheers,
Daniel
Daniel-Constantin Mierla
http://www.asipto.com
> On 17 Apr 2014, at 16:07, Juha Heinanen wrote:
>
> Daniel-Constantin Mierla writes:
>
>> Can you print also the htable key to see which of its va
Daniel-Constantin Mierla writes:
> Can you print also the htable key to see which of its values are not
> set? Like:
>
> xlog("key is: t=>$T(id_label)::$T(id_index)::$T(branch_index)::ru\n");
>
> in both places.
Apr 17 17:06:23 siika /usr/sbin/sip-proxy[5957]: INFO: Key in branch route is:
t=
On 17/04/14 08:31, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
It would require C coding to get it nicely, I see three options:
- try to get the values as in branch_route -- seems complex at first look
- try to get the values via $T_branch(attr) -- sounds simpler now
- try to get a f
Daniel-Constantin Mierla writes:
> It would require C coding to get it nicely, I see three options:
> - try to get the values as in branch_route -- seems complex at first look
> - try to get the values via $T_branch(attr) -- sounds simpler now
> - try to get a function t_reuse_branch() -- create a
On 16/04/14 18:46, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Why would you need all attributes of the branch that just failed, do you
want to send the request to the same destination again?
that is exactly the requirement. the idea is to assign some avps/branch
flags differently
Daniel-Constantin Mierla writes:
> Why would you need all attributes of the branch that just failed, do you
> want to send the request to the same destination again?
that is exactly the requirement. the idea is to assign some avps/branch
flags differently so that mediaproxy-offer in branch rout
On 16/04/14 18:29, Juha Heinanen wrote:
Hugh Waite writes:
As you and Daniel saw from the code, I replicated the behaviour of the
'failure-route' but with the current branch index. I didn't deliberately
choose the behaviour of $ru etc. so I'm happy with it being classed as a bug
if that's what
: 14 April 2014 22:56
To: Juha Heinanen
Cc: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] event_route[tm:branch-failure] question
On 14/04/14 21:15, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
To get the branch attributes, the code should be similar to execution
of failur
Hugh Waite writes:
> As you and Daniel saw from the code, I replicated the behaviour of the
> 'failure-route' but with the current branch index. I didn't deliberately
> choose the behaviour of $ru etc. so I'm happy with it being classed as a bug
> if that's what's expected in this situation.
>
>
ve something different in this situation?
Regards,
Hugh
-Original Message-
From: sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of
Daniel-Constantin Mierla
Sent: 14 April 2014 22:56
To: Juha Heinanen
Cc: Kamailio (SER) - Users Mailing List
Subje
On 14/04/14 21:15, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
To get the branch attributes, the code should be similar to execution of
failure_route. In failure_route, the attributes are taken from winning
branch. In branch-failure, the attributes should be taken from current
branch
Daniel-Constantin Mierla writes:
> To get the branch attributes, the code should be similar to execution of
> failure_route. In failure_route, the attributes are taken from winning
> branch. In branch-failure, the attributes should be taken from current
> branch. But in both cases is dealing wi
On 14/04/14 15:18, Juha Heinanen wrote:
daniel,
what would it take to make append_branch() call in branch-failure route
to re-create the branch of the corresponding branch route? is that
currently possible by any means? if not, what new stuff would need to
be introduced?
I haven't had time to
On 14/04/14 15:11, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Flags needs to be re-sync'ed on the other hand:
http://kamailio.org/docs/modules/stable/modules/tmx.html#idp24432
could that function be used as a model to re-sync also other transaction
attributes?
If someone needs some
daniel,
what would it take to make append_branch() call in branch-failure route
to re-create the branch of the corresponding branch route? is that
currently possible by any means? if not, what new stuff would need to
be introduced?
-- juha
___
SIP Ex
Daniel-Constantin Mierla writes:
> Flags needs to be re-sync'ed on the other hand:
> http://kamailio.org/docs/modules/stable/modules/tmx.html#idp24432
could that function be used as a model to re-sync also other transaction
attributes?
on the other hand, we have been discussing here branch attri
On 14/04/14 14:43, Alex Hermann wrote:
On Monday 14 April 2014, Daniel-Constantin Mierla wrote:
Incoming request is stored in transaction with all the changes done in
request_route until the transaction is created. A matter of what was the
r-uri at the moment of creating transaction, you will r
On Monday 14 April 2014, Daniel-Constantin Mierla wrote:
> Incoming request is stored in transaction with all the changes done in
> request_route until the transaction is created. A matter of what was the
> r-uri at the moment of creating transaction, you will retrieve it in the
> tm specific routi
Daniel-Constantin Mierla writes:
> The fix (or a new option to run if the current behavior was wanted by
> developer) is to run branch-failure with the attributes from outgoing
> request of the branch (not the incoming request, as it is now).
i got it now. in my opinion, attributes of branch-f
On 14/04/14 11:59, Juha Heinanen wrote:
i called t_newtran() also when request came from proxy itself and after
that $ru was aor, not contact uri, in branch-failure route also during
the second iteration.
so somehow calling t_newtran() before t_relay() breaks branch-failure
route. it would be n
i called t_newtran() also when request came from proxy itself and after
that $ru was aor, not contact uri, in branch-failure route also during
the second iteration.
so somehow calling t_newtran() before t_relay() breaks branch-failure
route. it would be nice to get it fixed.
-- juha
___
Daniel-Constantin Mierla writes:
> Print $ru before the function that creates the transaction (t_relay() or
> t_newtran() in config) and see if they are the same for the two cases.
> If yes, then you have to look inside tm code for this event route -- I
> am not the developer of this features,
On 14/04/14 10:50, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Incoming request is stored in transaction with all the changes done in
request_route until the transaction is created. A matter of what was the
r-uri at the moment of creating transaction, you will retrieve it in the
tm s
Daniel-Constantin Mierla writes:
> Incoming request is stored in transaction with all the changes done in
> request_route until the transaction is created. A matter of what was the
> r-uri at the moment of creating transaction, you will retrieve it in the
> tm specific routing blocks when such
On 14/04/14 10:35, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I guess the event route is executed with the incoming request. I would
expect to have there the branch attributes, but I haven't developed the
feature.
it would be important to get access to branch attributes in
branch-fa
Daniel-Constantin Mierla writes:
> I guess the event route is executed with the incoming request. I would
> expect to have there the branch attributes, but I haven't developed the
> feature.
it would be important to get access to branch attributes in
branch-failure event route so that when appe
I guess the event route is executed with the incoming request. I would
expect to have there the branch attributes, but I haven't developed the
feature.
Perhaps you should look inside tm module at execution of branch
route/failure route to see how they take the branch attributes and
compare, t
i did some more tests and got very puzzling result. this time i tested
with 488 response, but response code does not matter.
sip proxy forwards invite based on location lookup to contact of
registered local user:
Apr 14 09:13:33 siika /usr/sbin/sip-proxy[8001]: INFO: INVITE
is to local user
A
in branch route i execute:
t_on_branch_failure("contact");
xlog("L_INFO", "Routing $rm <$ru> to contact\n");
and in branch_failure route i have:
event_route [tm:branch-failure:contact] {
if (t_check_status("486")) {
xlog("L_INFO", "Got 486 response to <$ru>\n");
Thank you for attention and help Daniel...
for while I will leave the rtpproxy destroy the session by itself in short
time it is not confirmed or by timeout if didn't received the delete of
session.
I think be better to start a new discussion thread about the new problem
too...
Best Regards
201
Hello,
On 5/15/13 3:00 PM, Bruno Bresciani wrote:
Hi Daniel,
Sure Daniel, I can process 487 on onreply route... I was trying to
handle 487 in failure_route block, I didn't know it can be processed
in onreply_route!
failure route is executed when all branches fail, on reply route is
executed
Hi Daniel,
Sure Daniel, I can process 487 on onreply route... I was trying to handle
487 in failure_route block, I didn't know it can be processed in
onreply_route!
I know that rtpproxy destroys the session by itself in short time it is not
confirmed, but I'm trying to force it the most amount of
Hello,
On 5/14/13 7:15 PM, Bruno Bresciani wrote:
Thank's Daniel,
I need process cancel requests to delete sessions on rtp proxy... In a
call forking, when I need forking to multiple destinations on
different network segments, requiring different rtpproxy parameters, I
use the “extra_id_pv”
Thank's Daniel,
I need process cancel requests to delete sessions on rtp proxy... In a call
forking, when I need forking to multiple destinations on different network
segments, requiring different rtpproxy parameters, I use the “extra_id_pv”
and "b" parameter in the rtpproxy_offer() function to cr
Hello,
why do you need to process cancel requests? They have special routing
requirements related to associated invite and sent from tm directly. The
event route is for the requests sent by modules via tm.
Haven't tried, but maybe onsend_route will capture it.
Cheers,
Daniel
On 5/14/13 12:3
Hi All,
in a call forking, after one branch answer the call (200 OK reply), a
CANCEL SIP message has been sending to other/another branch(es) and I need
to process this/these cancellations in configuration file. After reading
some documentations, I discovered there is event_route[tm:local-request]
Hi,
I think that it is more than likely not implemented, but is there any
event-route that is triggered just before event_route[dialog:start] ? I
need to check some security flags before the dialog is created. But it is
too early too check them in relay route..
Mino
__
Hello,
the warning is harmless. I can't say right now what is exact relation
between the dialog event route and it, I will have to look at sources --
dialog module registers some callbacks. But at the end, everything
should go fine.
I would create the dialog only when it is pretty much clear
Hi,
I started using testing the event_route[dialog:failed].
On my scenario, I receive an INVITE, use t_newtran(), check some stuff and
send a failure reply like 3XX or 4XX.
I use send_reply() and can see that the TM sends the reply.
Now, if I use event_route[dialog:failed], I keep on getting th
thanks.
On Wed, Sep 5, 2012 at 9:42 AM, Daniel-Constantin Mierla
wrote:
> Hello,
>
> the readme is wrong regarding the name of the event route, it should be:
>
> event_route[dialog:failed]
>
> I will fix the docs.
>
> Cheers,
> Daniel
>
>
> On 9/3/12 11:00 AM, Uri Shacked wrote:
>
> Hi,
>
> i s
Hello,
the readme is wrong regarding the name of the event route, it should be:
event_route[dialog:failed]
I will fix the docs.
Cheers,
Daniel
On 9/3/12 11:00 AM, Uri Shacked wrote:
Hi,
i seems to me that the "event_route[dialog:failure]" does not
recognize dialog failures.
i use dlg_manage
Hi,
i seems to me that the "event_route[dialog:failure]" does not recognize
dialog failures.
i use dlg_manage when i recieve the INVITE. i get 301, 302, 402 or
send_reply with some +300 responses.
on the manage_failure i print the responses, on the
event_route[dialog:start] and [dialog:end] i get
Hello,
On 3/17/11 5:45 PM, Alexandre Abreu wrote:
Hello.
Why acc_db_request() doesn't work on event_route?
I will take a look.
Is the BYE generated by dialog timeout or you trigger it by kamctl/xmlrpc?
Cheers,
Daniel
Mar 17 13:15:44 devel kamailio[25209]: INFO:
Hello.
Why acc_db_request() doesn't work on event_route?
Mar 17 13:15:44 devel kamailio[25209]: INFO:
69 matches
Mail list logo
