[OpenSIPS-Users] dialog info + Grandstreams = freezing

Bogdan-Andrei Iancu bogdan at voice-system.ro
Thu Aug 13 10:52:44 CEST 2009


Hi David,

As you experience problems with Kamilio, why do you post the bugs on the 
OpenSIPS mailing list? These are separate project, which are not 
compatible from source code and cfg script any more.

Even the script you posted is no compatible with OpenSIPS.

Also, cross posting between multiple mailing list is not a best practice.

Thanks for your understanding,
Bogdan

David wrote:
> Hello,
>
> I am having this problem on kamailio 1.5.2-tls compiled on Ubuntu 8.04, 
> 1.5.1-tls ( compiled with no tls ) on Ubuntu 8.04 and with OpenSIPS 
> 1.5.2-tls compilde on Ubuntu 8.04
>
> I am trying to setup presence_dialoginfo with my Grandstreams, Snom and 
> Linksys. I have a 4 phones on the server.
>
> 101 - Linksys SPA962             ( 6.1.5a    )
> 102 - Grandstream GXP2020 ( 1.2.1.4   )
> 103 - Grandstream GXP2000 ( 1.2.1.4   )
> 104 - Grandstream GXP2000 ( 1.1.6.46 )
> 105 - Snom 360                       ( 7.3.23    )
>
> My Kamailio deals with registrations, NAT and BLF everything else is 
> sent to one of two asterisk boxes. I use the dispatcher module for this. 
> This means that when I call one extension to the other, both call legs 
> from asterisk are going through Kamailio as separate calls. But to 
> divide my customers, the usernames are different from the URL that the 
> user types. For example the customer dials '101' but it is changed to 
> testspace.101 when it comes back from asterisk. So Kamailio would have 
> two calls in the event that 101 dials 102.
>
> sip:testspace.101 at myserver to 102 ( this is sent to asterisk )
> sip:testspace.101 at myserver to testspace.102 ( this is coming back from 
> asterisk )
>
> Something is horribly wrong. I have the following problems :
>
> 1. If 102 calls 103, when 103 answers both phones hang for about 2 minutes
> 2. If 105 calls 101, 101 BLF comes back to the inactive state ( green on 
> the Linksys and dark on the Snom), but the orange light stays on on the 
> Snom and it thinks the call is still active ( the light is on, but the 
> call is over )
> 3. If any extension calls any extension and I try a call pickup, it 
> fails. It looks like the Linksys is sending a NOTIFY to pickup the call 
> ( I thought it was supposed to send an invite... ? )
>
> Looking at the logs it looks like Kamailio is sending out so many 
> NOTIFYs that it is crashing the Grandstreams, and causing the Snom to 
> act funny.
>
> Here are some experts from my config file :
>
> root at kamailio-dev:/etc/kamailio# grep dialog *
> kamailio.cfg:# * avp value for dialogs is still not correct
> kamailio.cfg:loadmodule "dialog.so"
> kamailio.cfg:loadmodule "presence_dialoginfo.so"
> kamailio.cfg:loadmodule "pua_dialoginfo.so"
> kamailio.cfg:#modparam("pua_dialoginfo", "include_localremote", 0)
> kamailio.cfg:#modparam("pua_dialoginfo", "include_tags", 0)
> kamailio.cfg:#modparam("pua_dialoginfo", "include_callid", 0)
> kamailio.cfg:modparam("dialog", "dlg_flag", 4)
> kamailio.cfg:modparam("dialog", "db_mode", 1)
> kamailio.cfg:modparam("dialog", "timeout_avp", "$avp(i:10)") # I still 
> haven't figured out how to set $avp(i:10)
> kamailio.cfg:modparam("pua_dialoginfo", "override_lifetime", 300)
> kamailio.cfg:modparam("presence_dialoginfo", "force_single_dialog", 1)
> kamailio.cfg:modparam("pua_dialoginfo", "caller_confirmed", 1)
> kamailio.cfg:modparam("auth_db|usrloc|acc|domain|avpops|presence|presence_xml|pua|dialog", 
> "db_url",
> kamailio.cfg:# Flag 4 = Mark the current request for a dialog
> kamailio.cfg:          # sequential request withing a dialog should
>
> the set flag looks like this :
>  if (  ds_is_from_list() )
>      {
>           xlog("L_INFO", "Coming from asterisk");
>           if ( is_method("INVITE"))
>           {
>                setflag(4);
>           }
> }
>
> So the dialog flag is only set for the leg coming back from asterisk.
>
> When a notify comes in :
>
>      if(is_method("NOTIFY") )
>      {
>           if (! t_newtran())
>           {
>                sl_reply_error();
>                exit;
>           };
>
>           t_reply("200", "OK");
>           t_release();
>         
>           exit ;
>      }
>
> Publish and subscribe are like this :
>
>
>  if( is_method("PUBLISH") || is_method("SUBSCRIBE") )
>      {
>           route(5);
>           exit;
>      }
>
> route[5]
> {
>      # absorb retransmissions
>      if (! t_newtran())
>      {
>           xlog("L_INFO", "Ignoring PUBLISH/SUBSCRIBE on retransmition - 
> M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");
>           sl_reply_error();
>           exit;
>      };
>
>      append_to_reply("Contact: <sip:myserver.tld:5060>\r\n");
>
>      if(is_method("PUBLISH"))
>      {
>           handle_publish();
>           t_release();
>
>      } else if( is_method("SUBSCRIBE")) {
>           handle_subscribe();
>           t_release();
>      }
>      else
>      {
>      }
>
>      exit;
> }
>
> I also have NAT checking for those telephones where stun isn't enough. 
> Before I reach publish/subscribe/invite/notify, I also call setbflag() 
> and sometimes call fix_nated_contact(). Additionnally, I have a block if 
> code before my presence stuff if ( has_totag() && loose_route()) { 
> t_relay();  }.
>
> If sip.conf:canreinvite=yes, the grandstreams freeze so long that the 
> server times out, and the BLFs get really messed up. if 
> sip:canreinvite=no the grandstreams only freeze for about 30 seconds.
>
> Obviously I am doing something wrong, but despite having searched google 
> for endless hours, and poured over documentation, I can not seem to find 
> what I did wrong.
>
> I would really appreciate if someone could shed light on my problem.
>
> I am having this problem on kamailio 1.5.2-tls compiled on Ubuntu 8.04, 
> 1.5.1-tls ( compiled with no tls ) on Ubuntu 8.04 and with OpenSIPS 
> 1.5.2-tls compilde on Ubuntu 8.04
>
> Thanks,
>
> David
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   




More information about the Users mailing list