[Users] Re: Dropped calls with OpenSER 1.1.x and Asterisk >= 1.2.14

Edoardo Serra edoardo.serra at webrainstorm.it
Sat May 19 19:43:42 CEST 2007


Sorry guys, I came across that by mysqlf

I shoud have moved up loose_route block.

Regards

Edoardo

Edoardo Serra ha scritto:
> Hi Bogdan, and sorry for my stupid question :)
> Let's try to describe the complete scenario
> 
> We're a VoIP provider using OpenSER as registrar server and load 
> balancer (with dispatcher module) for a cluster of Asterisk servers
> 
> We're now talking of received calls from our users perspective.
> One of our Asterisks originate an INVITE for someuser at openser,
> OpenSER does a lookup in the location table and forward the INVITE 
> statefully.
> 
> When the user answer the call sends a 200 OK to OpenSER which is 
> forwarded to Asterisk, Asterisk sends back an ACK which is not forwarded 
> back to the user.
> The user retries to send the OK but after a while it drops the call 
> because it's considering that a critical error
> 
> Here is a dump of what I mean
> 
> ASTERISK -> OPENSER - SIP/SDP Request: INVITE - 
> SIP:sorsatrav at 213.92.79.131, with session 
> description
> OPENSER -> ASTERISK - SIP Status: 100 trying -- your call is important 
> to us
> OPENSER -> USER - SIP/SDP Request: INVITE - SIP:s at 81.196.154.44:5060, 
> with session description
> OPENSER -> USER - SIP/SDP Request: INVITE - SIP:s at 81.196.154.44:5060, 
> with session description
> USER -> OPENSER - SIP Status: 100 Trying
> 
> USER -> OPENSER - SIP/SDP Status: 200 OK, with session description
> OPENSER -> ASTERISK - SIP/SDP Status: 200 OK, with session description
> ASTERISK -> OPENSER - SIP Request: ACK - SIP:s at 192.168.0.251
> (this packet is not forwarded to user so client retries to send the OK)
> 
> USER -> OPENSER - SIP/SDP Status: 200 OK, with session description
> OPENSER -> ASTERISK - SIP/SDP Status: 200 OK, with session description
> ASTERISK -> OPENSER - SIP Request: ACK - SIP:s at 192.168.0.251
> 
> In this case the USER is an Asterisk, I tried the same tests with an 
> XLite as user and the packet is forwarded correctly.
> 
> Here are the details of the ACK packet
> 
> Request-Line: ACK sip:s at 192.168.0.251 SIP/2.0
> Message Header
>     Via: SIP/2.0/UDP 213.92.79.138:5060;branch=z9hG4bK5a1555e7;rport
>     Route: <sip:213.92.79.131;lr=on;ftag=as3b66b2ad>
>     From: "Unknown" 
> <sip:Unknown at 213.92.79.138>;tag=as3b66b2ad
>     To: 
> <sip:sorsatrav at 213.92.79.131>;tag=as4b185fcc
>     Contact: <sip:Unknown at 213.92.79.138>
>     Call-ID: 
> 6c21caa9503939325dc45a343434e8dc at 213.92.79.138
>     CSeq: 102 ACK
>     User-Agent: Exsorsa
>     Max-Forwards: 70
>     Content-Length: 0
> 
> Tnx in advance for you help
> 
> Regards
> 
> Edoardo
> 
> P.S.: Here is my openser.cfg
> 
> # $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 andrei Exp $
> # ----------- global configuration parameters ------------------------
> 
> check_via=yes    # (cmd. line: -v)
> dns=no          # (cmd. line: -r)
> rev_dns=no      # (cmd. line: -R)
> fifo="/tmp/ser_fifo"
> 
> #uid=nobody
> #gid=nobody
> 
> # ------------------ 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://user:pass@192.168.252.5/openser")
> modparam("usrloc", "timer_interval", 120)
> modparam("auth_db", "calculate_ha1", 0)
> modparam("auth_db", "db_url", 
> "mysql://user:pass@192.168.252.5/db")
> modparam("uri_db", "db_url", 
> "mysql://user:pass@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{
>         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==ip.of.asterisk.1) || (src_ip==ip.of.asterisk.1)) {
>                 if (!lookup("location")) {
>                         sl_send_reply("486", "Busy here");
>                         exit;
>                 };
>                 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 (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");
>                 t_relay();
>                 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");
> 
>     if ((src_ip!=ip.of.asterisk.1) && (src_ip!=ip.of.asterisk.2)) {
>             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();
>     };
> }
> 
> 
> Bogdan-Andrei Iancu ha scritto:
>> Hi Edoardo,
>>
>> the ACK for 200 OK is generated by the call originator (caller) - it 
>> is an end-to-end request ; so you have to check if the caller sent an 
>> ACK, if it got to openser and if it contained proper route information 
>> in order to be sent to Asterisk.
>>
>> regards,
>> bogdan
>>
>> Edoardo Serra wrote:
>>> Hi guys,
>>>     I'm having a problem about asterisk dropping calls received from 
>>> OpenSER
>>>
>>> The problems was spotted at Asterisk users mailing lists
>>> http://lists.digium.com/pipermail/asterisk-users/2007-April/184875.html
>>>
>>> Asterisk complains about an ACK not received and drops the calls.
>>> It expects OpenSER to send an ACK back to its '200 OK' when the call 
>>> is set up
>>>
>>> Is that a problem OpenSER should solve ???
>>>
>>> Tnx in advance
>>>
>>> Regards
>>>
>>> Edoardo Serra
>>> WeBRainstorm S.r.l.
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
> 
> 





More information about the Users mailing list