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

Edoardo Serra edoardo.serra at webrainstorm.it
Fri Mar 16 11:05:40 CET 2007


Hi all,
	I don't want to bother you about this problem again but I'm a little 
bit stuck.

Someone can help ?

Tnx in advance

Regards

Edoardo

Edoardo Serra ha scritto:
> 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