Hi Andreas,
the docs were updated with your fix. thanks!
the difference between ds_select_dst("1", "0") and
ds_select_domain("1",
"0") is where the select address will be pushed into the request. The
first one it will push it into destination_uri which is an internally
uri used as outbound proxy - the RURI will remain unchanged, but the
request is fwd to the destination_uri. The second function push the
selected address directly into RURI (only host and port part).
the destination uri may be visible via $du pseudo variable
http://openser.org/docs/pseudo-variables.html#pv_du
and RURI via $ru
(
http://openser.org/docs/pseudo-variables.html#pv_ru)
regards,
bogdan
Anders Brownworth wrote:
Hi,
I am trying to get an OpenSER instance running with the dispatcher
module spreading load amongst several other OpenSER servers. I'm
having trouble understanding from the docs and practical application
exactly what the dispatcher module does and how to make it do what I
want.
I want to accept requests and use the dispatcher module to send
requests to one of a number of other servers. (I want this setup to
scale so I don't want to use the tm module.) Each subsequent request
with the same CallId should go back to the same server. Therefore
using the hash over the CallId algorithm in the dispatcher module
seems like the best choice.
I'm running OpenSER 1.0.0 and working off of the configuration in the
modules documentation:
http://openser.org/docs/modules/1.0.x/dispatcher.html
I fixed up a few things that didn't seem to work out of the box such
as replacing forward( ) with forward( uri:host, uri:port ).
I have several questions.
1. What exactly does ds_select_dst("1", "0") do? I understand the
parameters but the module documentation says it "selects a destination
from addresses set". OK, so does it return it somehow? How do I get my
hands on what it picks? What is an example of a situation where this
function would be useful?
2. What exactly ds_select_domain("1", "0") do? I gather it rewrites
the host and port with what it gets from the addresses set (which
seems more useful than ds_select_dst), but when I run this in
practice, _if_ it rewrites the host / port, it always seems to pick
the same destination. (in my tests I only get an outgoing INVITE about
10% of the time) It does seem like I want to be using
ds_select_domain() though.
Can someone point out where my misunderstanding is? I have my
configuration copied below.
Thanks.
-Anders
---------------------------------------------------------------------------------------
What I'm expecting:
When the first INVITE comes from 10.1.50.30 (Asterisk) to 10.1.50.31,
(OpenSER with dispatcher) I want to see an outgoing INVITE from
10.1.50.31 to one of the listed addresses. (10.1.50.[34-37])
What I'm seeing:
A tcpdump shows that most of the time all I see is the incoming
INVITE. Seemingly random INVITES produce an outgoing INVITE, even when
calling the same number. Presumably the only substantive difference is
the CallID.
openser.cfg:
-----------------------------------------------------------------------------
#debug=4
fork=yes
log_stderror=no
children=4
check_via=no
dns=off
rev_dns=off
port=5060
mpath="/usr/local/lib/openser/modules"
loadmodule "maxfwd.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "dispatcher.so"
modparam( "dispatcher", "list_file",
"/usr/local/etc/openser/dispatcher.list" )
route {
if ( ! mf_process_maxfwd_header( "10" ) ) {
sl_send_reply( "483", "To Many Hops" );
drop( );
};
ds_select_domain( "1", "0" );
forward( uri:host, uri:port );
}
-----------------------------------------------------------------------
dispatcher.list:
-----------------------------------------------------------------------
# gateways
1 sip:10.1.50.34:5060
1 sip:10.1.50.35:5060
1 sip:10.1.50.36:5060
1 sip:10.1.50.37:5060
-----------------------------------------------------------------------
tcpdump shows:
-----------------------------------------------------------------------
07:43:37.216888 IP 10.1.50.30.5060 > 10.1.50.31.5060: UDP, length: 685
.@.@...
.2.
.2.........INVITE sip:+18666775910@10.1.50.31 SIP/2.0
Via: SIP/2.0/UDP 10.1.50.30:5060;branch=z9hG4bK434da07b
From: "+19195551212" <sip:+19195551212@10.1.50.30>;tag=as3a379ead
To: <sip:+18666775910@10.1.50.31>
Contact: <sip:+19195551212@10.1.50.30>
Call-ID: 7dd7978262a876832fc69a4364f89f22(a)10.1.50.30
CSeq: 102 INVITE
User-Agent: BandwidthVoice
Date: Fri, 03 Feb 2006 12:41:35 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 202
v=0
o=root 11014 11014 IN IP4 10.1.50.30
s=session
c=IN IP4 10.1.50.30
t=0 0
m=audio 8360 RTP/AVP 0 3 8
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
-----------------------------------------------------------------------
with no outgoing INVITE. Things seem to be dead. Then I try the same
call a few seconds later and I get the outgoing INVITE:
-----------------------------------------------------------------------
07:43:48.695958 IP 10.1.50.30.5060 > 10.1.50.31.5060: UDP, length: 686
.@.@...
.2.
.2.........INVITE sip:+18666775910@10.1.50.31 SIP/2.0
Via: SIP/2.0/UDP 10.1.50.30:5060;branch=z9hG4bK15490a4e
From: "+19195551212" <sip:+19195551212@10.1.50.30>;tag=as302ac772
To: <sip:+18666775910@10.1.50.31>
Contact: <sip:+19195551212@10.1.50.30>
Call-ID: 531db3695f15035620baae890d555216(a)10.1.50.30
CSeq: 102 INVITE
User-Agent: BandwidthVoice
Date: Fri, 03 Feb 2006 12:41:46 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 203
v=0
o=root 11015 11015 IN IP4 10.1.50.30
s=session
c=IN IP4 10.1.50.30
t=0 0
m=audio 28484 RTP/AVP 0 3 8
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
07:43:48.696191 IP 10.1.50.31.5060 > 10.1.50.36.5060: UDP, length: 747
E....*@.@..g
.2.
.2$......S.INVITE sip:+18666775910@10.1.50.36:5060 SIP/2.0
Max-Forwards: 10
Via: SIP/2.0/UDP 10.1.50.31;branch=0
Via: SIP/2.0/UDP 10.1.50.30:5060;branch=z9hG4bK15490a4e
From: "+19195551212" <sip:+19195551212@10.1.50.30>;tag=as302ac772
To: <sip:+18666775910@10.1.50.31>
Contact: <sip:+19195551212@10.1.50.30>
Call-ID: 531db3695f15035620baae890d555216(a)10.1.50.30
CSeq: 102 INVITE
User-Agent: BandwidthVoice
Date: Fri, 03 Feb 2006 12:41:46 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 203
v=0
o=root 11015 11015 IN IP4 10.1.50.30
s=session
c=IN IP4 10.1.50.30
t=0 0
m=audio 28484 RTP/AVP 0 3 8
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
-----------------------------------------------------------------------
any help greatly appreciated.
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users