[Users] Re: OpenSER + Asterisk - Music On Hold

Edoardo Serra edoardo.serra at webrainstorm.it
Mon Mar 12 14:38:13 CET 2007


Tnx Carsten for attention.

My openser.cfg is following
I probably contains some misconfiguration as I'm still new to OpenSER

Tnx in advance

Regards



# ----------- global configuration parameters ------------------------
check_via=yes    # (cmd. line: -v)
dns=no          # (cmd. line: -r)
rev_dns=no      # (cmd. line: -R)
port=5060
fifo="/tmp/ser_fifo"

# ------------------ module loading ----------------------------------

loadmodule "/usr/lib/openser/modules/sl.so"
loadmodule "/usr/lib/openser/modules/tm.so"
loadmodule "/usr/lib/openser/modules/rr.so"
loadmodule "/usr/lib/openser/modules/maxfwd.so"
loadmodule "/usr/lib/openser/modules/usrloc.so"
loadmodule "/usr/lib/openser/modules/registrar.so"
loadmodule "/usr/lib/openser/modules/nathelper.so"
loadmodule "/usr/lib/openser/modules/textops.so"
loadmodule "/usr/lib/openser/modules/exec.so"
loadmodule "/usr/lib/openser/modules/uri.so"
loadmodule "/usr/lib/openser/modules/uri_db.so"
loadmodule "/usr/lib/openser/modules/dispatcher.so"
loadmodule "/usr/lib/openser/modules/mysql.so"
loadmodule "/usr/lib/openser/modules/auth.so"
loadmodule "/usr/lib/openser/modules/auth_db.so"

modparam("usrloc", "db_mode", 2)
modparam("usrloc", "db_url", "mysql://XXX:XXX@192.168.252.5/openser")
modparam("usrloc", "timer_interval", 120)

modparam("auth_db", "calculate_ha1", 0)
modparam("auth_db", "db_url", "mysql://XXX:XXX@192.168.252.5/userdb")

modparam("uri_db", "db_url", "mysql://XXX:XXX@192.168.252.5/openser")

modparam("rr", "enable_full_lr", 1)

modparam("registrar", "nat_flag", 6)
modparam("registrar", "max_expires", 3600)
modparam("registrar", "min_expires", 60)
modparam("registrar", "append_branches", 0)
modparam("registrar", "desc_time_order", 1)

modparam("nathelper", "natping_interval", 20) # Ping interval 20 s
modparam("nathelper", "ping_nated_only", 1)   # Ping only clients behind NAT

modparam("dispatcher", "force_dst", 1)

# -------------------------  request routing logic -------------------

# main routing logic

route{
         # initial sanity checks -- messages with
         # max_forwards==0, or excessively long requests
         if (!mf_process_maxfwd_header("10")) {
                 sl_send_reply("483","Too Many Hops");
                 exit;
         };
         if ( msg:len > max_len ) {
                 sl_send_reply("513", "Message too big");
                 exit;
         };

         if ( (method=="OPTIONS") || (method=="SUBSCRIBE") || 
(method=="NOTIFY") ) {
                 sl_send_reply("405", "Method Not Allowed");
                 exit;
         }

         if (!method=="REGISTER") {
                 record_route();
         };


         if ((src_ip==111.222.333.444) || (src_ip==555.666.777.888)) {
         # IPs of our PSTN gateways
                 if (!lookup("location")) {
                         sl_send_reply("486", "Busy here");
                         exit;
                 };
                 # forward to current uri now; use stateful forwarding; that
                 # works reliably even if we forward from TCP to UDP
                 if (!t_relay()) {
                         sl_reply_error();
                 };
                 exit;
         };

         if (nat_uac_test("3")) {
                 if ((method=="REGISTER") || (method=="INVITE") || 
(method=="OPTIONS")) {
                         fix_nated_contact();
                         force_rport();
                         setflag(6);    # Mark as NATed
                 }
         }
         # if the request is for other domain use UsrLoc
         # (in case, it does not work, use the following command
         # with proper names and addresses in it)
         if (method=="REGISTER") {
                 if (!proxy_authorize("exorsa", "openser_view")) {
                         proxy_challenge("exorsa", "0");
                         exit;
                 }
                 if (!check_to()) {
                         sl_send_reply("403", "Digest username and URI 
username do NOT match! Stay away!");
                         exit;
                 }

                 save("location");

                 exit;
         };


	if (method=="INVITE") {
		if (!proxy_authorize("exorsa", "openser_view")) {
			proxy_challenge("exorsa", "0");
			exit;
		}

		if (!check_from()) {
			sl_send_reply("403", "Digest username and URI username do NOT match! 
Stay away!");
			exit;
		}
	}

         # loose-route processing
         if (loose_route()) {
                 # mark routing logic in request
                 append_hf("P-hint: rr-enforced\r\n");
                 route(1);
                 exit;
         };

         if (!uri==myself) {
                 # mark routing logic in request
                 append_hf("P-hint: outbound\r\n");
                 route(1);
                 exit;
         };

         append_hf("P-hint: usrloc applied\r\n");
         route(1);
}

route[1]
{
         # !! Nathelper
         if (uri=~"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)" 
&& !search("^Route:")){
             sl_send_reply("479", "We don't forward to private IP 
addresses");
             exit;
         };

         # NAT processing of replies; apply to all transactions (for 
example,
         # re-INVITEs from public to private UA are hard to identify as
         # NATed at the moment of request processing); look at replies
         t_on_reply("1");

         # send it out now; use stateful forwarding as it works reliably
         # even for UDP2TCP
	if ((src_ip!=111.222.333.444) && (src_ip!=555.666.777.888)) {
	#IPs of our PSTN Gateways
	        ds_select_dst("1", "0");
         }

         if (!t_relay()) {
                 sl_reply_error();
         };
}

# !! Nathelper
onreply_route[1] {
     # NATed transaction ?
     if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") {
         fix_nated_contact();
     # otherwise, is it a transaction behind a NAT and we did not
     # know at time of request processing ? (RFC1918 contacts)
     } else if (nat_uac_test("1")) {
         fix_nated_contact();
     };
}
Carsten Bock ha scritto:
> Hi Edoardo,
> 
> Normally this would be handled by an Record-Route/Loose-Route construct.
> When doing record-routing/loose-routing, the in-dialog request
> "Re-INVITE" (for Music-On-Hold) should take the same route as the
> initial request (following the route headers) and you should no longer
> need to query the dispatcher-module for these in-dialog requests.
> Maybe you could post your config, i guess then we could help a little
> more.
> 
> Carsten
> 
> 
> Am Montag, den 12.03.2007, 13:10 +0100 schrieb Edoardo Serra:
>> Daniel,
>> 	thanks for your interest in the problem.
>>
>> I better analyzed the problem and found the point in it.
>> I try to describe where I guess the problem is
>>
>> When one of our users receive a call from the PSTN, the PSTN Gateway 
>> (Asterisk) sends an INVITE at username at openser, the INVITE is correctly 
>> forwarded to the user and the call is set up without problems.
>> (RTP from PSTN gw to USER and SIP through OpenSER)
>>
>> When the user wants to put the caller OnHold it sends an INVITE to 
>> OpenSER but OpenSER forwards the INVITE to one of the PSTN GW using 
>> dispatcher module.
>> This way, if the INVITE is not forwarded to the PSTN GW which is 
>> handling the call a second call is generated.
>>
>> Do you have any suggestion ?
>> Every kind of help is appreciated.
>>
>> Sorry for not having sent a network capture, but is quite difficult to
>> prepare such a capture on our system because it's always very busy
>>
>> Hoping to hear from you soon
>>
>> Regards
>>
>> Edoardo
>>
>>
>> Daniel-Constantin Mierla ha scritto:
>>> Hello,
>>>
>>> a network trace (ngrep or wireshark) will help to spot what might be the 
>>> problem, otherwise is hard to guess.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 03/04/07 17:32, Edoardo Serra wrote:
>>>> Hi all,
>>>>     I have an OpenSER server in front of serveral Asterisk acting as a 
>>>> load balancer and registrar server.
>>>>
>>>> We're offering both, inbound and outbound call services.
>>>>
>>>> When an outbound call is made, OpenSER, through the dispatcher module, 
>>>> choose an Asterisk server to handle the media of the call.
>>>>
>>>> When an inbound call is received (by a PSTN GW interconnected with one 
>>>> of the Asterisks), Asterisk calls SIP/username at openser.
>>>>
>>>> Media flows directly from user to Asterisks without using RTPProxy as 
>>>> every Asterisk server has got a public IP Address..
>>>>
>>>> I have the following problem with MOH.
>>>>
>>>> If a user tries to put on hold an outbound call (placed by him) 
>>>> everything is OK, Asterisk start playing MOH and stops when the user 
>>>> wants to stop it.
>>>>
>>>> But, if a user wants to put on hold an inbound call (a call just 
>>>> answered), as soon as it press the hold button another call to the 
>>>> caller is originated and the first call is not put on hold by the 
>>>> Asterisk
>>>>
>>>> I guess the problem is that, in this case, the asterisk doesn't 
>>>> recognise the INVITE as a re-INVITE and originate a new call instead 
>>>> of putting the other on hold.
>>>>
>>>> Do you have any idea on how to solve the problem ?
>>>> Every suggestion is appreciated.
>>>>
>>>> Regards
>>>>
>>>> Edoardo Serra
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at openser.org
>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
> 
> 





More information about the Users mailing list