19 Jul
2009
19 Jul
'09
11:23 a.m.
i'm basin
my assumption about buggyness of dialog module just on the
large number bugs that has been reported and fixed during its lifetime.
according to some theory, the number of past bugs is an indication of
remaining ones.
-- juha
That seems believable, but I hope it is not true or I am really screwed! 
19 Jul
19 Jul
11:31 a.m.
New subject: crash with dialog module
Alex Balashov writes:
The dialog message is also rather ambitious in its
aims; it tackles some
rather complicated state-keeping tasks. Complex design, many possible
state permutations, and the need to carefully and precisely manage
numerous elements of data persistence in all scenarios in a deductively
rigourous way are attributes that result in more bugs as well.
i agree. dialog module has adopted a very complex task that is not what
a sip proxy is normally supposed to do.
-- juha
11:29 a.m.
New subject: crash with dialog module
Alex Balashov writes:
True, although it is also one of the project's most useful, innovative and
distinguishing features, and I would not advocate its disappearance under
any circumstances.
The new inventions Daniel introduced in 1.5.x - especially dlg_bridge() -
have also served me incredibly well. It's allowed me to totally ditch
Asterisk in a couple of outbound call broadcast scenarios. Great stuff!
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
The dialog message is also rather ambitious in
its aims; it tackles
some
rather complicated state-keeping tasks. Complex
design, many possible
state permutations, and the need to carefully and precisely manage
numerous elements of data persistence in all scenarios in a deductively
rigourous way are attributes that result in more bugs as well.
i agree. dialog module has adopted a very complex task that is not what
a sip proxy is normally supposed to do.
11:42 a.m.
New subject: crash with dialog module
Alex Balashov writes:
The new inventions Daniel introduced in 1.5.x -
especially dlg_bridge() -
have also served me incredibly well. It's allowed me to totally ditch
Asterisk in a couple of outbound call broadcast scenarios. Great stuff!
if you need to do that kind of bridging often, then sure dialog module
is a way to go.
daniel suggested that i could use dialog module dlg_bridge mi command to
implement click-to-dial calls.
if only a very small percentage of all calls would be click-to-dial
calls and thus use dialog module, would it introduce a performance
penalty for every bye (or even for every in-dialog) request, because
they need to be checked for did param in route header?
-- juha
11:58 a.m.
New subject: crash with dialog module
On 19.07.2009 17:42 Uhr, Juha Heinanen wrote:
Alex Balashov writes:
the initial dialog created by dlg_bridge (invite+refer+bye) is not
tracked by dialog module (nor stored in db). There is no penalty, the
call created by one side because of REFER comes to proxy as an usual
call and it is a matter of config to be tacked or not.
Bottom line, if you load dialog module just for dlg_bridge (don't set
the dlg flag nor use dlg_manage() in config), there is no effect for any
of the calls.
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/index.php/sip-router-bootcamp/
The new inventions Daniel introduced in 1.5.x -
especially dlg_bridge() -
have also served me incredibly well. It's allowed me to totally ditch
Asterisk in a couple of outbound call broadcast scenarios. Great stuff!
if you need to do that kind of bridging often, then sure dialog module
is a way to go.
daniel suggested that i could use dialog module dlg_bridge mi command to
implement click-to-dial calls.
if only a very small percentage of all calls would be click-to-dial
calls and thus use dialog module, would it introduce a performance
penalty for every bye (or even for every in-dialog) request, because
they need to be checked for did param in route header?
12:02 p.m.
New subject: crash with dialog module
Daniel-Constantin Mierla writes:
the initial dialog created by dlg_bridge
(invite+refer+bye) is not
tracked by dialog module (nor stored in db). There is no penalty, the
call created by one side because of REFER comes to proxy as an usual
call and it is a matter of config to be tacked or not.
ok, thanks for the explanation. why is dialog module then forcing me to
define a dialog flag, if dlg_bridge is not creating a dialog module
dialog?
-- juha
12:11 p.m.
New subject: crash with dialog module
On 19.07.2009 18:02 Uhr, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
probably there is need for a parameter to set kind of passive mode. By
default there are some mandatory parameters for normal operation mode,
they must be set as parameter, but to create dialog structure the flag
must be set in route (or dlg_manage() used) for initial invite.
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/index.php/sip-router-bootcamp/
the initial dialog created by dlg_bridge
(invite+refer+bye) is not
tracked by dialog module (nor stored in db). There is no penalty, the
call created by one side because of REFER comes to proxy as an usual
call and it is a matter of config to be tacked or not.
ok, thanks for the explanation. why is dialog module then forcing me to
define a dialog flag, if dlg_bridge is not creating a dialog module
dialog?
20 Jul
20 Jul
3:47 a.m.
New subject: crash with dialog module
Daniel-Constantin Mierla schrieb:
On 19.07.2009 17:42 Uhr, Juha Heinanen wrote:
How are NOTIFYs sent by the transferee handled? Are they also
auomatically answered with 200?
regards
klaus
Alex Balashov writes:
the initial dialog created by dlg_bridge (invite+refer+bye) is not The new inventions Daniel introduced in 1.5.x -
especially
dlg_bridge() -
have also served me incredibly well. It's
allowed me to totally ditch
Asterisk in a couple of outbound call broadcast scenarios. Great
stuff!
if you need to do that kind of bridging often, then sure dialog module
is a way to go.
daniel suggested that i could use dialog module dlg_bridge mi command to
implement click-to-dial calls.
if only a very small percentage of all calls would be click-to-dial
calls and thus use dialog module, would it introduce a performance
penalty for every bye (or even for every in-dialog) request, because
they need to be checked for did param in route header?
tracked by dialog module (nor stored in db). There is
no penalty, the
call created by one side because of REFER comes to proxy as an usual
call and it is a matter of config to be tacked or not.
Bottom line, if you load dialog module just for dlg_bridge (don't set
the dlg flag nor use dlg_manage() in config), there is no effect for any
of the calls.
Daniel
10:45 a.m.
New subject: crash with dialog module
On 20.07.2009 9:47 Uhr, Klaus Darilion wrote:
Daniel-Constantin Mierla schrieb:
Yes. The whole process is a sequence of calling TM
uac functions,
passing a dlg structure as callback parameters in order to construct
in-dialog requests.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com/index.php/sip-router-bootcamp/
On 19.07.2009 17:42 Uhr, Juha Heinanen wrote:
How are NOTIFYs sent by the transferee handled? Are they also
auomatically answered with 200? Alex Balashov writes:
the initial dialog created by dlg_bridge (invite+refer+bye) is not The new inventions Daniel introduced in 1.5.x -
especially
dlg_bridge() -
have also served me incredibly well. It's
allowed me to totally
ditch
Asterisk in a couple of outbound call broadcast
scenarios. Great
stuff!
if you need to do that kind of bridging often, then sure dialog module
is a way to go. daniel suggested that i could use dialog module
dlg_bridge mi command to
implement click-to-dial calls.
if only a very small percentage of all calls would be click-to-dial
calls and thus use dialog module, would it introduce a performance
penalty for every bye (or even for every in-dialog) request, because
they need to be checked for did param in route header?
5425
days inactive
5426
days old
8 comments
4 participants
participants (4)
-
Alex Balashov -
Daniel-Constantin Mierla -
jh＠tutpro.com -
Klaus Darilion