[Kamailio-Users] dialog info + Grandstreams = freezing
David
kamailio.org at spam.lublink.net
Tue Aug 11 15:04:32 CEST 2009
I installed kamailio 1.5 from branch without any difference.
But now we refer to the same code.
David
> Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> Please take latest kamailio 1.5 from svn branch 1.5 as there were
>> committed some updates (maybe they don't affect you, being mainly to
>> rls, but is better to have the latest stable so we refer to same
>> source code).
>>
>> Cheers,
>> Daniel
>>
>>
>> On 11.08.2009 5:03 Uhr, 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
>>>
>>> _______________________________________________
>>> Kamailio (OpenSER) - Users mailing list
>>> Users at lists.kamailio.org
>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>>>
>>
>
>
> _______________________________________________
> Kamailio (OpenSER) - Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
More information about the Users
mailing list