12 Aug
2009
12 Aug
'09
11:21 a.m.
.. fwd to list ... reply all button mismatch ...
---------- Forwarded message ----------
From: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: Wed, Aug 12, 2009 at 9:20 AM
Subject: Re: [Kamailio-Users] dialog info + Grandstreams = freezing
To: David <kamailio.org(a)spam.lublink.net>
Hello,
On Tue, Aug 11, 2009 at 2:18 PM, David <kamailio.org(a)spam.lublink.net>wrote;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:
--
Daniel-Constantin Mierla
http://www.asipto.com
--
Daniel-Constantin Mierla
http://www.asipto.com
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:
_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
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@myserver to 102 ( this is sent to asterisk )
sip:testspace.101@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@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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users