[Kamailio-Users] Fwd: dialog info + Grandstreams = freezing

Daniel-Constantin Mierla miconda at gmail.com
Thu Aug 13 19:26:38 CEST 2009


Hello,

On 12.08.2009 15:24 Uhr, David wrote:
> Hello,
>
> Yes, I am tracking both legs. Because, if a call comes in on a DID, 
> Asterisk decides which extension to ring and it's the second leg which 
> needs to be tracked, whereas if it is an outbound call to a PRI, it's 
> the first leg that should be tracked because the second leg doesn't 
> make it through Kamailio ( for now ).
>
> So you think my problem is because I am tracking both legs? I thought 
> of this last night as well, I'll have a look today or tomorrow and 
> will post my results.
trying to cacth up after some traveling period ... maybe you sorted out, 
anyhow ... if asterisk does not change the caller id, then you have two 
calls going on. The watcher might get confused in case of call pickup.

Cheers,
Daniel

>
> David
>
> Daniel-Constantin Mierla wrote:
>> .. fwd to list ... reply all button mismatch ...
>>
>> ---------- Forwarded message ----------
>> From: *Daniel-Constantin Mierla* <miconda at gmail.com 
>> <mailto: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 <http://kamailio.org>@spam.lublink.net 
>> <http://spam.lublink.net>>
>>
>>
>> Hello,
>>
>> On Tue, Aug 11, 2009 at 2:18 PM, David <kamailio.org 
>> <http://kamailio.org>@spam.lublink.net <http://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 <mailto: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 <mailto: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