Juha Heinanen writes: > transition "bye on other leg" CONNECTED - B2B.otherBye() / stop(true) -> END; > > based on my tests, the transition has no effect, since sems relays the > bye from callee to caller before this transition is executed.
I took debug output and it confirmed the above. Sip dialog is disconnected when bye from callee leg is received: Sep 30 21:28:59 lohi sems[4507]: [#7ffafed14700] [handle_sip_request, SipCtrlInterface.cpp:788] DEBUG: ^^ M [7F15BDCB-560C29DF000DF3C8-FE007700|7508D885-560C29DF000DF3C0-FE007700] Ru SIP request BYE handled ^^ Sep 30 21:28:59 lohi sems[4507]: [#7ffafdf06700] [processingCycle, AmSession.cpp:346] DEBUG: vv S [7F15BDCB-560C29DF000DF3C8-FE007700|7508D885-560C29DF000DF3C0-FE007700] Connected, running, 0 UACTransPending, 0 usages vv Sep 30 21:28:59 lohi sems[4507]: [#7ffafdf06700] [process, AmSession.cpp:638] DEBUG: AmSession processing event Sep 30 21:28:59 lohi sems[4507]: [#7ffafdf06700] [onRxRequest, AmBasicSipDialog.cpp:308] DEBUG: AmBasicSipDialog::onRxRequest(req = BYE) Sep 30 21:28:59 lohi sems[4507]: [#7ffafdf06700] [setStatus, AmBasicSipDialog.cpp:84] DEBUG: setting SIP dialog status: Connected->Disconnecting Sep 30 21:28:59 lohi sems[4507]: [#7ffafdf06700] [onSipRequest, AmB2BSession.cpp:352] DEBUG: relaying B2B SIP request (fwd) BYE sip:127.0.0.1:5090;transport=udp ... After that, B2BOtherBye event is processed but it is too late: Sep 30 21:28:59 lohi sems[4507]: [#7ffafe007700] [onOtherBye, DSMCall.cpp:838] DEBUG: * Got BYE from other leg Sep 30 21:28:59 lohi sems[4507]: [#7ffafe007700] [runEvent, DSMStateEngine.cpp:603] DEBUG: o v DSM current state 'conn', processing 'B2BOtherBye' event v Sep 30 21:28:59 lohi sems[4507]: [#7ffafe007700] [runEvent, DSMStateEngine.cpp:611] DEBUG: > state 'conn' Sep 30 21:28:59 lohi sems[4507]: [#7ffafe007700] [runEvent, DSMStateEngine.cpp:617] DEBUG: ...checking transition 'bye on other leg' Sep 30 21:28:59 lohi sems[4507]: [#7ffafe007700] [runEvent, DSMStateEngine.cpp:626] DEBUG: .>>transition 'bye on other leg' matched. Sep 30 21:28:59 lohi sems[4507]: [#7ffafe007700] [runEvent, DSMStateEngine.cpp:653] DEBUG: >>>running 2 actions of transition 'bye on other leg' Sep 30 21:28:59 lohi sems[4507]: [#7ffafe007700] [runactions, DSMStateEngine.cpp:316] DEBUG: running 2 DSM action elements Sep 30 21:28:59 lohi sems[4507]: [#7ffafe007700] [runactions, DSMStateEngine.cpp:321] DEBUG: executing 'log(2, received bye)' Sep 30 21:28:59 lohi sems[4507]: [#7ffafe007700] [execute, DSMCoreModule.cpp:613] INFO: FSM: 'received bye' Sep 30 21:28:59 lohi sems[4507]: [#7ffafe007700] [runactions, DSMStateEngine.cpp:321] DEBUG: executing 'B2B.sendReinvite(true)' Sep 30 21:28:59 lohi sems[4507]: [#7ffafe007700] [reinvite, AmSipDialog.cpp:600] DEBUG: reinvite(): we are not connected (status=Disconnecting). do nothing! Is there some way to prevent sems from disconnecting caller leg when bye is received from callee so that it would be possible to reinvite caller back to sems and keep on processing the dsm diagram or ivr script? -- Juha _______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
