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!
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.
Expecting dialog to be un-buggy is, in my opinion, sort of like expecting TM to be less buggy than, say, alias_db.
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
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.
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 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
On 19.07.2009 17:42 Uhr, Juha Heinanen wrote:
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?
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 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
On 19.07.2009 18:02 Uhr, Juha Heinanen wrote:
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?
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 schrieb:
On 19.07.2009 17:42 Uhr, Juha Heinanen wrote:
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?
the initial dialog created by dlg_bridge (invite+refer+bye) is not
How are NOTIFYs sent by the transferee handled? Are they also auomatically answered with 200?
regards klaus
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
On 20.07.2009 9:47 Uhr, Klaus Darilion wrote:
Daniel-Constantin Mierla schrieb:
On 19.07.2009 17:42 Uhr, Juha Heinanen wrote:
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?
the initial dialog created by dlg_bridge (invite+refer+bye) is not
How are NOTIFYs sent by the transferee handled? Are they also auomatically answered with 200?
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
-
Alex Balashov -
Daniel-Constantin Mierla -
jh＠tutpro.com -
Klaus Darilion