[Kamailio-Users] Fwd: dialog info + Grandstreams = freezing
Daniel-Constantin Mierla
miconda at gmail.com
Wed Aug 12 09:21:35 CEST 2009
.. fwd to list ... reply all button mismatch ...
---------- Forwarded message ----------
From: Daniel-Constantin Mierla <miconda at gmail.com>
Date: Wed, Aug 12, 2009 at 9:20 AM
Subject: Re: [Kamailio-Users] dialog info + Grandstreams = freezing
To: David <kamailio.org at spam.lublink.net>
Hello,
On Tue, Aug 11, 2009 at 2:18 PM, David <kamailio.org at spam.lublink.net>wrote:
> Hey,
>
> I am not good at diagrams, but here goes :
>
>
> [ Asterisk] [ Asterisk ] ================> [ MySQL ]
> / \ / \
> [ Kamailio ] ============/\
> / \ / \ / \
> [ Extension ] [ Extension ] [ Extension ]
>
> Here is a simple flow :
>
> 1. Extension 1 is plugged in
> 2. It registers to Kamailio and Kamailio stores to Location
> 3. Extension 1 subscribes to all the other extensions
> 4. Kamailio calls handle_publish() and t_release()
> 5. Extension 1 dials '102'
> 6. Kamailio receives the INVITE chooses an asterisk server and relays the
> INVITE ( t_relay )
> 7. Asterisk does some checking, starts monitor ( if needed ) and some other
> stuff
> 8. Asterisk sends INVITE to Kamailio for testspace.102
> 9. Kamailio finds testspace.102 in database and forwards INVITE to the
> appropriate extension
> 10. Extension replies 'OK'
> 11. Kamailio, using reply-route, sends it back to asterisk
> 12. Asterisk bridges the call with 101
> 13. Asterisk sends an OK back through Kamailio to Extension 1.
> 14. Asterisk tries to reinvite the audio ( if not monitoring )
> 15. Audio bypasses Asterisk, but the SIP still is making the full trip.
>
> Does this answer your question?
Do you do call tracking with dialog for both legs (inbond: phone to
asterisk; outbound: asterisk to phone)? You should do it for one, outbound
is the best, in case asterisk auto-answers the inbound leg.
Cheers,
Daniel
>
> David
>
>
>
> Daniel-Constantin Mierla wrote:
>
>> Hello,
>>
>> I am using the module with snom 370 and works ok. The BLF is on for
>> Polycoms but they do not implement the call pickup properly (they have
>> direct call pickup as far as I could get).
>>
>> 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).
>>
>> What would be good is to have a diagram of the signaling, since you say
>> there are lot of messages sent around.
>> http://callflow.sourceforge.net/
>>
>> 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
>
--
Daniel-Constantin Mierla
http://www.asipto.com
--
Daniel-Constantin Mierla
http://www.asipto.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20090812/9de72ac3/attachment.htm>
More information about the sr-users
mailing list