8 Feb
2007
8 Feb
'07
5:35 p.m.
Hi!
I hav the following questions about branch handling in openser 1.1.1:
In route[1] I use the dispatcher to forward to the gateway 11.22.33.46.
Thus, the DURI will be set. Further I use port 6060 to send calls to the
GW. So far everything is ok.
... setting fr_timer to 2 seconds
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
route[1]: request's uri: $ru=sip:123456789@foobar.net
route[1]: request's destination uri: $du=sip:11.22.33.46:5060
route[1]: request's force_send_sock: $fs=udp:11.22.33.44:6060
route[1]: request's first branch: $br=<null>
route[1]: request's all branches: $bR=
route[1]: request's destination set: $ds=Contact: sip:123456789@foobar.net
... t_relay
Then, if the GW does not reply within 2 seconds the failure route triggers:
First question: Why is the DURI set to NULL now?
... entering failure route
ERROR: no response from gateway or clients a1.net ...
branches before ds_next_dst: $ru=sip:123456789@foobar.net, $du=, $bR=
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
failure_route[1]: request's uri: $ru=sip:123456789@foobar.net
failure_route[1]: request's destination uri: $du=
failure_route[1]: request's force_send_sock: $fs=udp:11.22.33.44:6060
failure_route[1]: request's first branch: $br=<null>
failure_route[1]: request's all branches: $bR=
failure_route[1]: request's destination set: $ds=Contact:
sip:123456789@foobar.net
... ds_next_dst
branches after ds_next_dst: $ru=sip:123456789@foobar.net, $du=,
$bR=sip:123456789@foobar.net
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
failure_route[1]: request's uri: $ru=sip:123456789@foobar.net
failure_route[1]: request's destination uri: $du=
failure_route[1]: request's force_send_sock: $fs=udp:11.22.33.44:6060
failure_route[1]: request's first branch: $br=sip:123456789@foobar.net
failure_route[1]: request's all branches: $bR=sip:123456789@foobar.net
failure_route[1]: request's destination set: $ds=Contact:
sip:123456789@foobar.net, sip:979004369911
... activating branch_route
... t_relay
Second question: In the branch route the send_socket is reported as NULL.
AFAIK it will be copied from branches[0] to the new branch during
ds_next_dst. Also the request is sent from port 6060 - thus it looks like
the $fs is wrong in branch_route.
====================================================
branch_route[1]: request's uri: $ru=sip:123456789@foobar.net
branch_route[1]: request's destination uri: $du=sip:11.22.33.45:5060
branch_route[1]: request's force_send_sock: $fs=<null>
branch_route[1]: request's first branch: $br=sip:123456789@foobar.net
branch_route[1]: request's all branches: $bR=sip:123456789@foobar.net
branch_route[1]: request's destination set: $ds=Contact:
sip:123456789@foobar.net, sip:9790043699111
thanks
klaus
8 Feb
8 Feb
7:48 p.m.
Hi Klaus,
from the beginning I say it is a bug in dispatcher module :)
the module tries to do both - processing ruri/duri and handling the
forking (appending branches). The problem is when doing append_branch-
it uses the internal function for replicating the branch[0] as a new
branch (changing only duri)...and this does not trigger the new logic
about appending branches.
so, I see 2 possible fixups:
1) the module will do only uri processing and you do append_branch()
from script, if necessary (in failure route). This will be coherent with
the current model that you need to do an append_branch in failure route
if you want to continue processing. Also it gives you more liberty in
processing the duri and ruri after being set by the module (if they are
directly pushed into branches they cannot be modified anymore). The big
disadvantage will be of course that we change something people got used
with - they need an extra append_branch().
2) make the module to do append_branch via do_action() instead of
doing it directly.
regards,
bogdan
Klaus Darilion wrote:
Hi!
I hav the following questions about branch handling in openser 1.1.1:
In route[1] I use the dispatcher to forward to the gateway 11.22.33.46.
Thus, the DURI will be set. Further I use port 6060 to send calls to the
GW. So far everything is ok.
... setting fr_timer to 2 seconds
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
route[1]: request's uri: $ru=sip:123456789@foobar.net
route[1]: request's destination uri: $du=sip:11.22.33.46:5060
route[1]: request's force_send_sock: $fs=udp:11.22.33.44:6060
route[1]: request's first branch: $br=<null>
route[1]: request's all branches: $bR=
route[1]: request's destination set: $ds=Contact: sip:123456789@foobar.net
... t_relay
Then, if the GW does not reply within 2 seconds the failure route triggers:
First question: Why is the DURI set to NULL now?
... entering failure route
ERROR: no response from gateway or clients a1.net ...
branches before ds_next_dst: $ru=sip:123456789@foobar.net, $du=, $bR=
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
failure_route[1]: request's uri: $ru=sip:123456789@foobar.net
failure_route[1]: request's destination uri: $du=
failure_route[1]: request's force_send_sock: $fs=udp:11.22.33.44:6060
failure_route[1]: request's first branch: $br=<null>
failure_route[1]: request's all branches: $bR=
failure_route[1]: request's destination set: $ds=Contact:
sip:123456789@foobar.net
... ds_next_dst
branches after ds_next_dst: $ru=sip:123456789@foobar.net, $du=,
$bR=sip:123456789@foobar.net
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
failure_route[1]: request's uri: $ru=sip:123456789@foobar.net
failure_route[1]: request's destination uri: $du=
failure_route[1]: request's force_send_sock: $fs=udp:11.22.33.44:6060
failure_route[1]: request's first branch: $br=sip:123456789@foobar.net
failure_route[1]: request's all branches: $bR=sip:123456789@foobar.net
failure_route[1]: request's destination set: $ds=Contact:
sip:123456789@foobar.net, sip:979004369911
... activating branch_route
... t_relay
Second question: In the branch route the send_socket is reported as NULL.
AFAIK it will be copied from branches[0] to the new branch during
ds_next_dst. Also the request is sent from port 6060 - thus it looks like
the $fs is wrong in branch_route.
====================================================
branch_route[1]: request's uri: $ru=sip:123456789@foobar.net
branch_route[1]: request's destination uri: $du=sip:11.22.33.45:5060
branch_route[1]: request's force_send_sock: $fs=<null>
branch_route[1]: request's first branch: $br=sip:123456789@foobar.net
branch_route[1]: request's all branches: $bR=sip:123456789@foobar.net
branch_route[1]: request's destination set: $ds=Contact:
sip:123456789@foobar.net, sip:9790043699111
thanks
klaus
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
9 Feb
9 Feb
12:37 a.m.
On Thu, February 8, 2007 18:48, Bogdan-Andrei Iancu said:
Hi Klaus,
from the beginning I say it is a bug in dispatcher module :)
but it works. I just wonder about the values reported by $du and $fs.
regards
klaus
the module tries to do both - processing ruri/duri and handling the
forking (appending branches). The problem is when doing append_branch-
it uses the internal function for replicating the branch[0] as a new
branch (changing only duri)...and this does not trigger the new logic
about appending branches.
so, I see 2 possible fixups:
1) the module will do only uri processing and you do append_branch()
from script, if necessary (in failure route). This will be coherent with
the current model that you need to do an append_branch in failure route
if you want to continue processing. Also it gives you more liberty in
processing the duri and ruri after being set by the module (if they are
directly pushed into branches they cannot be modified anymore). The big
disadvantage will be of course that we change something people got used
with - they need an extra append_branch().
2) make the module to do append_branch via do_action() instead of
doing it directly.
regards,
bogdan
Klaus Darilion wrote:
Hi!
I hav the following questions about branch handling in openser 1.1.1:
In route[1] I use the dispatcher to forward to the gateway 11.22.33.46.
Thus, the DURI will be set. Further I use port 6060 to send calls to the
GW. So far everything is ok.
... setting fr_timer to 2 seconds
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
route[1]: request's uri: $ru=sip:123456789@foobar.net
route[1]: request's destination uri: $du=sip:11.22.33.46:5060
route[1]: request's force_send_sock: $fs=udp:11.22.33.44:6060
route[1]: request's first branch: $br=<null>
route[1]: request's all branches: $bR=
route[1]: request's destination set: $ds=Contact:
sip:123456789@foobar.net
... t_relay
Then, if the GW does not reply within 2 seconds the failure route
triggers:
First question: Why is the DURI set to NULL now?
... entering failure route
ERROR: no response from gateway or clients a1.net ...
branches before ds_next_dst: $ru=sip:123456789@foobar.net, $du=, $bR=
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
failure_route[1]: request's uri:
$ru=sip:123456789@foobar.net
failure_route[1]: request's destination uri: $du=
failure_route[1]: request's force_send_sock: $fs=udp:11.22.33.44:6060
failure_route[1]: request's first branch: $br=<null>
failure_route[1]: request's all branches: $bR=
failure_route[1]: request's destination set: $ds=Contact:
sip:123456789@foobar.net
... ds_next_dst
branches after ds_next_dst: $ru=sip:123456789@foobar.net, $du=,
$bR=sip:123456789@foobar.net
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
failure_route[1]: request's uri:
$ru=sip:123456789@foobar.net
failure_route[1]: request's destination uri: $du=
failure_route[1]: request's force_send_sock: $fs=udp:11.22.33.44:6060
failure_route[1]: request's first branch:
$br=sip:123456789@foobar.net
failure_route[1]: request's all branches:
$bR=sip:123456789@foobar.net
failure_route[1]: request's destination set: $ds=Contact:
sip:123456789@foobar.net, sip:979004369911
... activating branch_route
... t_relay
Second question: In the branch route the send_socket is reported as
NULL.
AFAIK it will be copied from branches[0] to the new branch during
ds_next_dst. Also the request is sent from port 6060 - thus it looks
like
the $fs is wrong in branch_route.
====================================================
branch_route[1]: request's uri: $ru=sip:123456789@foobar.net
branch_route[1]: request's destination uri: $du=sip:11.22.33.45:5060
branch_route[1]: request's force_send_sock: $fs=<null>
branch_route[1]: request's first branch: $br=sip:123456789@foobar.net
branch_route[1]: request's all branches: $bR=sip:123456789@foobar.net
branch_route[1]: request's destination set: $ds=Contact:
sip:123456789@foobar.net, sip:9790043699111
thanks
klaus
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
12 Feb
12 Feb
6:21 p.m.
Klaus,
it works for uri/dst, but the not for the rest of per-branch elements
(flags, path and socket) - you cannot print the values that were pushed
into branch.
regards,
bogdan
Klaus Darilion wrote:
On Thu, February 8, 2007 18:48, Bogdan-Andrei Iancu
said:
Hi Klaus,
from the beginning I say it is a bug in dispatcher module :)
but it works. I just wonder about the values reported by $du and $fs.
regards
klaus
the module tries to do both - processing
ruri/duri and handling the
forking (appending branches). The problem is when doing append_branch-
it uses the internal function for replicating the branch[0] as a new
branch (changing only duri)...and this does not trigger the new logic
about appending branches.
so, I see 2 possible fixups:
1) the module will do only uri processing and you do append_branch()
from script, if necessary (in failure route). This will be coherent with
the current model that you need to do an append_branch in failure route
if you want to continue processing. Also it gives you more liberty in
processing the duri and ruri after being set by the module (if they are
directly pushed into branches they cannot be modified anymore). The big
disadvantage will be of course that we change something people got used
with - they need an extra append_branch().
2) make the module to do append_branch via do_action() instead of
doing it directly.
regards,
bogdan
Klaus Darilion wrote:
Hi!
I hav the following questions about branch handling in openser 1.1.1:
In route[1] I use the dispatcher to forward to the gateway 11.22.33.46.
Thus, the DURI will be set. Further I use port 6060 to send calls to the
GW. So far everything is ok.
... setting fr_timer to 2 seconds
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
route[1]: request's uri: $ru=sip:123456789@foobar.net
route[1]: request's destination uri: $du=sip:11.22.33.46:5060
route[1]: request's force_send_sock: $fs=udp:11.22.33.44:6060
route[1]: request's first branch: $br=<null>
route[1]: request's all branches: $bR=
route[1]: request's destination set: $ds=Contact:
sip:123456789@foobar.net
... t_relay
Then, if the GW does not reply within 2 seconds the failure route
triggers:
First question: Why is the DURI set to NULL now?
... entering failure route
ERROR: no response from gateway or clients a1.net ...
branches before ds_next_dst: $ru=sip:123456789@foobar.net, $du=, $bR=
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
failure_route[1]: request's uri:
$ru=sip:123456789@foobar.net
failure_route[1]: request's destination uri: $du=
failure_route[1]: request's force_send_sock: $fs=udp:11.22.33.44:6060
failure_route[1]: request's first branch: $br=<null>
failure_route[1]: request's all branches: $bR=
failure_route[1]: request's destination set: $ds=Contact:
sip:123456789@foobar.net
... ds_next_dst
branches after ds_next_dst: $ru=sip:123456789@foobar.net, $du=,
$bR=sip:123456789@foobar.net
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
failure_route[1]: request's uri:
$ru=sip:123456789@foobar.net
failure_route[1]: request's destination uri: $du=
failure_route[1]: request's force_send_sock: $fs=udp:11.22.33.44:6060
failure_route[1]: request's first branch:
$br=sip:123456789@foobar.net
failure_route[1]: request's all branches:
$bR=sip:123456789@foobar.net
failure_route[1]: request's destination set: $ds=Contact:
sip:123456789@foobar.net, sip:979004369911
... activating branch_route
... t_relay
Second question: In the branch route the send_socket is reported as
NULL.
AFAIK it will be copied from branches[0] to the new branch during
ds_next_dst. Also the request is sent from port 6060 - thus it looks
like
the $fs is wrong in branch_route.
====================================================
branch_route[1]: request's uri: $ru=sip:123456789@foobar.net
branch_route[1]: request's destination uri: $du=sip:11.22.33.45:5060
branch_route[1]: request's force_send_sock: $fs=<null>
branch_route[1]: request's first branch: $br=sip:123456789@foobar.net
branch_route[1]: request's all branches: $bR=sip:123456789@foobar.net
branch_route[1]: request's destination set: $ds=Contact:
sip:123456789@foobar.net, sip:9790043699111
thanks
klaus
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
9:22 p.m.
New subject: [Users] DNS caching
Now that OpenSER supports NAPTR/SRV lookups I'd like to add DNS caching
to our SIP servers in order to decrease call setup delays and DNS server
load introduced by DNS queries.
I was wondering if others on this list have experience with running
OpenSER together with a DNS cache solution like nscd or dnsmasq. Initial
tests with nscd were not successful since somehow the OpenSER processes
do not go through the ncsd caching, whereas e.g. ping does. I'm also not
sure if ncsd or dnsmasq do support NAPTR and SRV type DNS queries.
I'd be glad to hear any recommendations on this topic,
Christian
10:26 p.m.
New subject: [Users] DNS caching
We have had all kinds of issues with the external caches and built consequently
our own in SER Ottendorf. (which is not openser though) The external caches
appeared suboptimal because there seemed to be some implementation issues and
also you can't combine external cache with blacklisting. (which we have in
SER).
-jiri
At 20:22 12/02/2007, Christian Schlatter wrote:
Now that OpenSER supports NAPTR/SRV lookups I'd
like to add DNS caching to our SIP servers in order to decrease call setup delays and DNS
server load introduced by DNS queries.
I was wondering if others on this list have experience with running OpenSER together with
a DNS cache solution like nscd or dnsmasq. Initial tests with nscd were not successful
since somehow the OpenSER processes do not go through the ncsd caching, whereas e.g. ping
does. I'm also not sure if ncsd or dnsmasq do support NAPTR and SRV type DNS queries.
I'd be glad to hear any recommendations on this topic,
Christian
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
--
Jiri Kuthan http://iptel.org/~jiri/
10:40 p.m.
New subject: [Users] DNS caching
I wonder why you need DNs caching inside openser. Usually you will a
resolving name server near (in terms of network hops) to your SIP proxy.
E.g. I have a bind9 running on the same linux box as openser. This name
server will be used by all processes running on this linux box
(/etc/resolv.conf points to 127.0.0.1 and to another name server in my
server farm).
Bind will cache all requests. A request for a domain which is cached in
bind will usually be <1ms and during waiting for the DNS response openser
wont cause CPU load - and probably the caching implementation in bind is a
good one.
Thus for me I do not see any reason for having the caching inside the SIP
proxy.
regards
klaus
On Mon, February 12, 2007 20:22, Christian Schlatter said:
Now that OpenSER supports NAPTR/SRV lookups I'd
like to add DNS caching
to our SIP servers in order to decrease call setup delays and DNS server
load introduced by DNS queries.
I was wondering if others on this list have experience with running
OpenSER together with a DNS cache solution like nscd or dnsmasq. Initial
tests with nscd were not successful since somehow the OpenSER processes
do not go through the ncsd caching, whereas e.g. ping does. I'm also not
sure if ncsd or dnsmasq do support NAPTR and SRV type DNS queries.
I'd be glad to hear any recommendations on this topic,
Christian
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
13 Feb
13 Feb
5:40 a.m.
New subject: [Users] DNS caching
I second Klaus in this.
I might add, it is pretty trivial to set up your 'local' copy of bind9 to timeout
within whatever 'acceptable' period you so desire (i.e., so as to prevent
'INVITE hangs', etc.).
cheers
----- Original Message -----
From: Klaus Darilion <klaus.mailinglists(a)pernau.at>
To: Christian Schlatter <cs(a)unc.edu>
Cc: users(a)openser.org
Sent: Monday, February 12, 2007 2:40:59 PM GMT-0600
Subject: Re: [Users] DNS caching
I wonder why you need DNs caching inside openser. Usually you will a
resolving name server near (in terms of network hops) to your SIP proxy.
E.g. I have a bind9 running on the same linux box as openser. This name
server will be used by all processes running on this linux box
(/etc/resolv.conf points to 127.0.0.1 and to another name server in my
server farm).
Bind will cache all requests. A request for a domain which is cached in
bind will usually be <1ms and during waiting for the DNS response openser
wont cause CPU load - and probably the caching implementation in bind is a
good one.
Thus for me I do not see any reason for having the caching inside the SIP
proxy.
regards
klaus
On Mon, February 12, 2007 20:22, Christian Schlatter said:
Now that OpenSER supports NAPTR/SRV lookups I'd
like to add DNS caching
to our SIP servers in order to decrease call setup delays and DNS server
load introduced by DNS queries.
I was wondering if others on this list have experience with running
OpenSER together with a DNS cache solution like nscd or dnsmasq. Initial
tests with nscd were not successful since somehow the OpenSER processes
do not go through the ncsd caching, whereas e.g. ping does. I'm also not
sure if ncsd or dnsmasq do support NAPTR and SRV type DNS queries.
I'd be glad to hear any recommendations on this topic,
Christian
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
--
*******************************************
Mahesh Paolini-Subramanya (703) 386-1500 x9100
CTO mahesh(a)aptela.com
Aptela, Inc. http://www.aptela.com
"Aptela: How Business Answers The Call"
*******************************************
11:59 a.m.
New subject: [Users] DNS caching
Hi,
I second this - we are using scnd and got good results. IMHO this is a
good alternative when you do not have a DNS server in your proximity
(and it gives the same level of configurability).
regards,
bogdan
Mahesh Paolini-Subramanya wrote:
I second Klaus in this.
I might add, it is pretty trivial to set up your 'local' copy of bind9 to timeout
within whatever 'acceptable' period you so desire (i.e., so as to prevent
'INVITE hangs', etc.).
cheers
----- Original Message -----
From: Klaus Darilion <klaus.mailinglists(a)pernau.at>
To: Christian Schlatter <cs(a)unc.edu>
Cc: users(a)openser.org
Sent: Monday, February 12, 2007 2:40:59 PM GMT-0600
Subject: Re: [Users] DNS caching
I wonder why you need DNs caching inside openser. Usually you will a
resolving name server near (in terms of network hops) to your SIP proxy.
E.g. I have a bind9 running on the same linux box as openser. This name
server will be used by all processes running on this linux box
(/etc/resolv.conf points to 127.0.0.1 and to another name server in my
server farm).
Bind will cache all requests. A request for a domain which is cached in
bind will usually be <1ms and during waiting for the DNS response openser
wont cause CPU load - and probably the caching implementation in bind is a
good one.
Thus for me I do not see any reason for having the caching inside the SIP
proxy.
regards
klaus
On Mon, February 12, 2007 20:22, Christian Schlatter said:
Now that OpenSER supports NAPTR/SRV lookups
I'd like to add DNS caching
to our SIP servers in order to decrease call setup delays and DNS server
load introduced by DNS queries.
I was wondering if others on this list have experience with running
OpenSER together with a DNS cache solution like nscd or dnsmasq. Initial
tests with nscd were not successful since somehow the OpenSER processes
do not go through the ncsd caching, whereas e.g. ping does. I'm also not
sure if ncsd or dnsmasq do support NAPTR and SRV type DNS queries.
I'd be glad to hear any recommendations on this topic,
Christian
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6492
days inactive
6497
days old
8 comments
5 participants
participants (5)
-
Bogdan-Andrei Iancu -
Christian Schlatter -
Jiri Kuthan -
Klaus Darilion -
Mahesh Paolini-Subramanya