Changing state on 1:1 from PROGRESS_MEDIA to PROGRESS
Hello, anybody has a clue what this message means? [WARNING] ozmod_libpri.c:729 VETO Changing state on 1:1 from PROGRESS_MEDIA to PROGRESS What does VETO mean here? Best regards Peter
On Wed, Aug 12, 2009 at 4:04 PM, Peter P GMX <Prometheus001@gmx.net> wrote:
Hello,
anybody has a clue what this message means? [WARNING] ozmod_libpri.c:729 VETO Changing state on 1:1 from PROGRESS_MEDIA to PROGRESS What does VETO mean here?
Best regards Peter
Means that state transition should not occur. The only thing that it would cause that (I think) is a bug in the the openzap code. -- Moises Silva Software Developer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com
Isn't progress_media already past progress in the state machine? so the state machine can't move backwards in states right? /b On Aug 12, 2009, at 3:33 PM, Moises Silva wrote:
On Wed, Aug 12, 2009 at 4:04 PM, Peter P GMX <Prometheus001@gmx.net> wrote: Hello,
anybody has a clue what this message means? [WARNING] ozmod_libpri.c:729 VETO Changing state on 1:1 from PROGRESS_MEDIA to PROGRESS What does VETO mean here?
Best regards Peter
Means that state transition should not occur. The only thing that it would cause that (I think) is a bug in the the openzap code.
Correct, so the question is why ozmod_libpri attempting to move from progress_media to progress ... may be a delayed libpri event? or some crap along those lines. On Wed, Aug 12, 2009 at 4:42 PM, Brian West <brian@freeswitch.org> wrote:
Isn't progress_media already past progress in the state machine? so the state machine can't move backwards in states right? /b
On Aug 12, 2009, at 3:33 PM, Moises Silva wrote:
On Wed, Aug 12, 2009 at 4:04 PM, Peter P GMX <Prometheus001@gmx.net> wrote:
Hello,
anybody has a clue what this message means? [WARNING] ozmod_libpri.c:729 VETO Changing state on 1:1 from PROGRESS_MEDIA to PROGRESS What does VETO mean here?
Best regards Peter
Means that state transition should not occur. The only thing that it would cause that (I think) is a bug in the the openzap code.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Moises Silva Software Developer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com
Yes you can get a progress after you get a progress with media ... I have seen it. /b On Aug 12, 2009, at 3:57 PM, Moises Silva wrote:
Correct, so the question is why ozmod_libpri attempting to move from progress_media to progress ... may be a delayed libpri event? or some crap along those lines.
On Wed, Aug 12, 2009 at 4:01 PM, Brian West <brian@freeswitch.org> wrote:
Yes you can get a progress after you get a progress with media ... I have seen it.
Yes, you definitely can and I believe that some of the PRI specs suggest that this is totally legal, even though it's kind of silly. -MC
then probably we should check the current state and ignore the libpri event when already in progress with media. On Wed, Aug 12, 2009 at 5:10 PM, Michael Collins <msc@freeswitch.org> wrote:
On Wed, Aug 12, 2009 at 4:01 PM, Brian West <brian@freeswitch.org> wrote:
Yes you can get a progress after you get a progress with media ... I have seen it.
Yes, you definitely can and I believe that some of the PRI specs suggest that this is totally legal, even though it's kind of silly. -MC
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Moises Silva Software Developer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com
On Wed, Aug 12, 2009 at 7:19 PM, Brian West <brian@freeswitch.org> wrote:
Well you really can't ignore it... it happens with our ISDN stack too. Thats what the VETO handles.
/b
You lost me. What do you mean we can't ignore it? the way I see it, sure we can and we should. Currently that warning comes from the on_ringing() callback which blindly attempts to move the state of the zap channel to ZAP_CHANNEL_STATE_PROGRESS, even when the state may be already ZAP_CHANNEL_STATE_PROGRESS_MEDIA (which means on_proceed() was called first). As I see it, the VETO warning is more an aid to the programmer so you quickly realize your doing a useless state change, which should be fixed. In this case, the fix is simply checking the state of the channel before trying to move it to progress, and don't even try to move it if already in progress with media. -- Moises Silva Software Developer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com
It probably just VETO it so it avoid sending SWITCH_MESSAGE_INDICATE_PROGRESS again since the call is already making progress from the core's point of view? Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca On 13-Aug-09, at 11:02 AM, Moises Silva wrote:
On Wed, Aug 12, 2009 at 7:19 PM, Brian West <brian@freeswitch.org> wrote: Well you really can't ignore it... it happens with our ISDN stack too. Thats what the VETO handles.
/b
You lost me. What do you mean we can't ignore it? the way I see it, sure we can and we should.
Currently that warning comes from the on_ringing() callback which blindly attempts to move the state of the zap channel to ZAP_CHANNEL_STATE_PROGRESS, even when the state may be already ZAP_CHANNEL_STATE_PROGRESS_MEDIA (which means on_proceed() was called first).
As I see it, the VETO warning is more an aid to the programmer so you quickly realize your doing a useless state change, which should be fixed. In this case, the fix is simply checking the state of the channel before trying to move it to progress, and don't even try to move it if already in progress with media.
-- Moises Silva Software Developer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Yes, agreed, but there is no point in sending a WARNING since is a normal condition, therefore should not even try to change the state of the channel. On Thu, Aug 13, 2009 at 7:57 PM, Mathieu Rene <mrene_lists@avgs.ca> wrote:
It probably just VETO it so it avoid sending SWITCH_MESSAGE_INDICATE_PROGRESS again since the call is already making progress from the core's point of view? Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca
On 13-Aug-09, at 11:02 AM, Moises Silva wrote:
On Wed, Aug 12, 2009 at 7:19 PM, Brian West <brian@freeswitch.org> wrote:
Well you really can't ignore it... it happens with our ISDN stack too. Thats what the VETO handles.
/b
You lost me. What do you mean we can't ignore it? the way I see it, sure we can and we should.
Currently that warning comes from the on_ringing() callback which blindly attempts to move the state of the zap channel to ZAP_CHANNEL_STATE_PROGRESS, even when the state may be already ZAP_CHANNEL_STATE_PROGRESS_MEDIA (which means on_proceed() was called first).
As I see it, the VETO warning is more an aid to the programmer so you quickly realize your doing a useless state change, which should be fixed. In this case, the fix is simply checking the state of the channel before trying to move it to progress, and don't even try to move it if already in progress with media.
-- Moises Silva Software Developer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Moises Silva Software Developer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com
Issue is we don't handle progress and progress media differently, maybe we should. The message is however harmless, but annoying and should probably be dealt with a bit better. Patches welcome. Mike On Aug 13, 2009, at 9:04 PM, Moises Silva wrote:
Yes, agreed, but there is no point in sending a WARNING since is a normal condition, therefore should not even try to change the state of the channel.
On Thu, Aug 13, 2009 at 7:57 PM, Mathieu Rene <mrene_lists@avgs.ca> wrote: It probably just VETO it so it avoid sending SWITCH_MESSAGE_INDICATE_PROGRESS again since the call is already making progress from the core's point of view?
Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca
On 13-Aug-09, at 11:02 AM, Moises Silva wrote:
On Wed, Aug 12, 2009 at 7:19 PM, Brian West <brian@freeswitch.org> wrote: Well you really can't ignore it... it happens with our ISDN stack too. Thats what the VETO handles.
/b
You lost me. What do you mean we can't ignore it? the way I see it, sure we can and we should.
Currently that warning comes from the on_ringing() callback which blindly attempts to move the state of the zap channel to ZAP_CHANNEL_STATE_PROGRESS, even when the state may be already ZAP_CHANNEL_STATE_PROGRESS_MEDIA (which means on_proceed() was called first).
As I see it, the VETO warning is more an aid to the programmer so you quickly realize your doing a useless state change, which should be fixed. In this case, the fix is simply checking the state of the channel before trying to move it to progress, and don't even try to move it if already in progress with media.
-- Moises Silva Software Developer Sangoma Technologies Inc. | 50 McIntosh Drive, Suite 120, Markham ON L3R 9T3 Canada t. 1 905 474 1990 x 128 | e. moy@sangoma.com
participants (6)
-
Brian West
-
Mathieu Rene
-
Michael Collins
-
Michael Jerris
-
Moises Silva
-
Peter P GMX