Hi,
I'm using kamailio 1.5 from the branch. In a conditional forwarding scenario with this call flow:
Phone A Kamailio Phone B Phone C | | | | | | | | | | | | |INVITE | | | |------------->| | | |100 Trying | | | |<-------------| | | | |INVITE | | | |------------->| | | |100 trying | | | |<-------------| | | |180 Ringing | | | |<-------------| | |180 Ringing | | | |<-------------| | | | |486 Busy Here | | | |<-------------| | | |ACK | | | |------------->| | | |INVITE | | | |---------------------------->| | |100 trying | | | |<----------------------------| | |180 Ringing | | | |<----------------------------| |180 Ringing | | | |<-------------| | | | |200 OK | | | |<----------------------------| |200 OK | | | |<-------------| | | |ACK | | | |------------->| | | | |ACK | | | |---------------------------->| | | | | | | | |
What I'm observing is that when Kamailio receives the 486 from B, the dialog between A and B is not destroyed, so when the call is finally established between A and C there are two active dialogs as I could check with `kamctl fifo get_statistics active_dialogs`. Shouldn't there be only one active dialog? Is this a problem in my script or a problem with the dialog module?
Thanks in advance,
Santi
El Jueves, 18 de Febrero de 2010, Santiago Gimeno escribió:
Hi,
I'm using kamailio 1.5 from the branch. In a conditional forwarding scenario with this call flow:
Phone A Kamailio Phone B Phone C |INVITE | | | |------------->| | | |100 Trying | | | |<-------------| | | | | |INVITE | | | |------------->| | | |100 trying | | | |<-------------| | | |180 Ringing | | | |<-------------| | | |180 Ringing | | | |<-------------| | | | | |486 Busy Here | | | |<-------------| | | |ACK | | | |------------->| | | |INVITE | | | |---------------------------->| | |100 trying | | | |<----------------------------| | |180 Ringing | | | |<----------------------------| | |180 Ringing | | | |<-------------| | | | | |200 OK | | | |<----------------------------| | |200 OK | | | |<-------------| | | |ACK | | | |------------->| | | | | |ACK | | | |---------------------------->|What I'm observing is that when Kamailio receives the 486 from B, the dialog between A and B is not destroyed, so when the call is finally established between A and C there are two active dialogs as I could check with `kamctl fifo get_statistics active_dialogs`. Shouldn't there be only one active dialog? Is this a problem in my script or a problem with the dialog module?
For now dialog module is not "forking-aware" which means that fails detecting cases like yours. However I don't know which should be the expected behaviour for your case (serial forking) with the current dialog module code.
PS: Could you tell me how did you "paint" the above SIP flow? it's very nice :)
Hi Iñaki,
2010/2/18 Iñaki Baz Castillo ibc@aliax.net
For now dialog module is not "forking-aware" which means that fails
detecting cases like yours. However I don't know which should be the expected behaviour for your case (serial forking) with the current dialog module code.
Thanks for the answer. It's a pity it's not supported as it makes the pua_dialoginfo module to work in a weird way. It's not nice to see a BLF for a extension that's not actually ringing. Maybe something can be done in the script in order to drop the PUBLISH requests I'm not interested in. Do you think this is feasible?
PS: Could you tell me how did you "paint" the above SIP flow? it's very nice :)
Yeah, it's great. It doesn't look it's maintained anymore but it does its job just fine:
http://sourceforge.net/projects/callplot/
Best regards,
Santi
-- Iñaki Baz Castillo ibc@aliax.net
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
nice tip santi! i thought you typed the callflow character per character.
Kelvin Chua
On Thu, Feb 18, 2010 at 6:35 PM, Santiago Gimeno santiago.gimeno@gmail.comwrote:
Hi Iñaki,
2010/2/18 Iñaki Baz Castillo ibc@aliax.net
For now dialog module is not "forking-aware" which means that fails
detecting cases like yours. However I don't know which should be the expected behaviour for your case (serial forking) with the current dialog module code.
Thanks for the answer. It's a pity it's not supported as it makes the pua_dialoginfo module to work in a weird way. It's not nice to see a BLF for a extension that's not actually ringing. Maybe something can be done in the script in order to drop the PUBLISH requests I'm not interested in. Do you think this is feasible?
PS: Could you tell me how did you "paint" the above SIP flow? it's very nice :)
Yeah, it's great. It doesn't look it's maintained anymore but it does its job just fine:
http://sourceforge.net/projects/callplot/
Best regards,
Santi
--
Iñaki Baz Castillo ibc@aliax.net
Kamailio (OpenSER) - Users mailing list Users@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@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
-
Iñaki Baz Castillo -
Kelvin Chua -
Santiago Gimeno