Problem with our custom reinvite management

[Lorenzo Miniero]

Erik Eliasson wrote:

>My best guess now is that you registred your new transition to go to
>"termwait", instead of remaining in "in_call". 
>
>
>Long explanation:
>
>The GUI sends the "stop_ringing" to the media subsystem when it receives
>the "invite_ok" (perhaps this is not how it should be - it should
>probably be done in libminisip/SipDialogVoip.cxx to make it independent
>of the GUI).
>
>It could be that the "stop_ringing" is not sent because of the
>re-invite, but because of the first invite (the GUI thread might be busy
>requesting the sound card to be opened, and does not send the
>"stop_ringing" until that is done, and then the re-invite has already
>arrived as shown in the logs).
>
>The strange thing is, as you say, that you get the "call_terminated"
>shortly after.
>
>When I look at it, it seems as that can only be generated by the
>following three transitions:
>   - a1003_byerequest_termwait_26
>   - a1101_termwait_terminated_notransactions
>   - a1102_termwait_termwait_early
>
>My guess is that it is generated by
>"a1101_termwait_terminated_notransactions" since the SIP stack will
>generate a "no_transactions" command when where is no transactions.
>
>This should how ever not result in the call hanging up since you should
>not be in the "termwait" state.
>
>Guess: Maybe you did not register your new "incall_incall" transition
>correctly.
>Maybe you wanted to write the following in "setUpStateMachine":
>  new StateTransition<SipSMCommand,string>(this,
>     "transition_incall_incall_invite", ..., 
>     s_incall, s_incall);
>, but wrote:
>  new StateTransition<SipSMCommand,string>(this,
>     "transition_incall_incall_invite", ..., 
>     s_incall, s_termwait);
>
>The difference in the two cases above is the destination state (the last
>argument).
>
>That would explain why you get your strange behavour, and also why you
>in dump3.txt don't have a dialog for the VoIP call when you press "+".
>
>When you try to hang up in the GUI, the call is not really ongoing (as
>far as the SIP stack knows), and therefore the "hangup" will not be
>handled by the SipDialogVoip (it was hung up by the re-invite).
>
>Any luck?
>--Erik
>  
>

Hi Erik,

now I feel really really REALLY stupid :)
I have been looking anywhere in any code, while it was exactly as you 
said about the registration of the new transition...
Now everything works like a charm, thanks a lot!

Lorenzo

--
http://confiance.sourceforge.net/