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
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,
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
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
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: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
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,
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
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
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
Apr 10 09:19:22 siprouter-testbed kamailio[20171]: ERROR: script: AVP
CallerID-Name returned Joel's Phone
Apr 10 09:19:22 siprouter-testbed kamailio[20171]: ERROR: script: AVP
CallerID-Ext returned 13032190010
U 2014/04/10 09:32:55.564531 10.111.200.114:5060 - 10.111.200.100:5060
INVITE
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 routing
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
All,
Is there a way I could check if IMS_qos is correctly loaded?
Looking forward to your suggestions.
thanks.
From: Dees motosi...@yahoo.co.uk
To: sr-users@lists.sip-router.org sr-users@lists.sip-router.org
Sent: Sunday, 13 April 2014, 0:03
Subject:
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
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
Thank you Daniel
I will try this tonight.
On 4/14/2014 8:13 AM, Daniel Tryba wrote:
Apr 10 09:19:22 siprouter-testbed kamailio[20171]: ERROR: script: AVP
CallerID-Name returned Joel's Phone
Apr 10 09:19:22 siprouter-testbed kamailio[20171]: ERROR: script: AVP
CallerID-Ext returned 13032190010
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
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
Hi,
Indeed, when we add a telephone number in the authorize file
(default_allow_file) using permission module then we have to restart
Kamailio. It's too bad for life system :(
Is it planned to improve in the next version ?
Thanks
--
Laurent PIERRE
http://www.linkedin.com/in/lpierre
--
On Monday 14 April 2014 16:02:10 Joel E White wrote:
Thank you Daniel
I will try this tonight.
BTW I just thought about the fact that is the username is empty in the from
this doesn't work (there is no @ in those URI). I have 2 cases:
$avp(from)=$fu;
if($fU==$null)
{
Hello Everyone,
Is possible do phone provisioning with kamailio ?
Slava.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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 with
Hello Sirs,
I'm trying to accomplish a rls subscribe but I have some
miss-understandings regarding the multipart publish response that should
come.
I'm using the integrated xcap from the kamailio with all the xml files
added. My problem is that event if I request a multipart
containing
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
Hello,
On 14/04/14 17:00, PIERRE Laurent wrote:
Hi,
Indeed, when we add a telephone number in the authorize file
(default_allow_file) using permission module then we have to restart
Kamailio. It's too bad for life system :(
if you use allow/deny files, then you have to use allow_routing()
Hi,
Why is your client sending so many sequential invites? voice IP and ports
allocation seems ok. You should be taking trace on the client side to see
if it is even sending media or not unless if you have just shared the SIP
traces only.
On Tue, Apr 15, 2014 at 10:32 AM, Ravi
27 matches
Mail list logo
