Problem with our custom reinvite management

[Erik Eliasson]

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


On Tue, 2006-08-15 at 17:52 +0200, Lorenzo Miniero wrote:
> Hi Erik,
> thanks a lot for the very quick answer!
> 
> >If the transition in SipDialogVoip gets the packet, then the CallId
> >should match?! If the CallId did not match the dialog, then it would not
> >be a re-invite, right?
> >  
> >
> 
> Yes, the call-ids surely match until then: the reinvite is handled fine, 
> I suppose something goes wrong in a second moment, when the OK is 
> compiled and sent back in reply to the reinvite.
> 
> >I can't add much else to your analysis without some additional
> >information.
> >
> >If you have enabled debugging, then you can press "+" and then enter in
> >the console to show the current internal state of the sip stack. If you
> >press "p" and then enter you will see all the packets. "d" will make the
> >debug output more verbose. (if you use the textui then the commands are
> >"+", "show packets" and "show debug")
> >  
> >
> 
> So this is the way to make mdbg lines appear! I redifined them as merr 
> in libmutil, since I never saw them during debug, and this is how I 
> monitored what was happening.
> 
> >Maybe you could provide some more information?
> >
> >Regards,
> >Erik
> >  
> >
> 
> I saved the full debug of all that is happening in three different text 
> files, every part preceeded by the internal state of Minisip at that moment:
> 
>     * _debug1.txt_ shows the first part:
>          1. Minisip invites Asterisk;
>          2. Asterisk replies (Trying and then OK);
>          3. Minisip ACKs;
>          4. Asterisk sends the reinvite (SDP+BFCP);
>          5. Minisip replies with an OK (SDP+BFCP);
>          6. Asterisk ACKs.
>       The call-id so far is 162664392, but some weird things already
>       appear, as the "stop_ringing" command sent to the MessageRouter
>       after the invite_ok handling (which is probably caused by the fact
>       an OK usually follows an INVITE after the user has physically
>       accepted a remote call, while in this case this is a reinvite and
>       Minisip is actually the client of the call, not the receiver),
>       followed by a "call_terminated" shortly after...
>     * _debug2.txt_ shows Asterisk trying to hang up the call by sending
>       a BYE: the debug is mostly the same BYE retransmitted many times,
>       since Minisip doesn't answer. I added a custom debug line that
>       shows why the call-id check fails:
> 
>           SipDialog: 1869851581 at 192.168.1.100 != 162664392 at 192.168.1.100
> 
>       The correct call-id, as showed before, should be 162664392, but
>       the check in SipDialog::handleCommand fails, since
>       dialogState.callId returns 1869851581 instead.
>     * _debug3.txt_ shows Minisip hanging the call from the gui (since
>       apparently the call is still on), the same error happens if
>       hanging up the call before the server does it: the BYE is never
>       sent. The cause is probably the same, since the destination_id is
>       set to 162664392 at 192.168.1.100 (and as we have seen before, the
>       callid seems to have changed), but here the request is discarded
>       in DefaultDialogHandler.
> 
> I attached to the txt debugs an Ethereal dump too: only the SIP & 
> SIP/SDP packets are reported, so that you can see for yourself how 
> exactly all the messages are. The files are all in the attached package.
> 
> Hope this is enough to have an overview of the possible problems: every 
> opinion will be more than welcome!
> 
> Best regards,
> Lorenzo
> 
> --
> http://confiance.sourceforge.net/
> _______________________________________________
> Minisip-devel mailing list
> Minisip-devel at minisip.org
> http://lists.minisip.org/mailman/listinfo/minisip-devel
-- 
Erik Eliasson <eliasson at it.kth.se>