i did more testing of b2b_connect_extension example dsm diag and it turned out that it behaves the same way as ivr scripts when negative response is received from callee. if response is 480, call is cleared:
Nov 8 11:56:42 rautu /usr/bin/sip-proxy[10644]: INFO: INVITE <sip:[email protected]> is temporarily unavailable! Nov 8 11:56:42 rautu sems[10268]: [#b3f51b70] [execute, DSMCoreModule.cpp:569] WARNING: FSM: 'received negative reply' Nov 8 11:56:42 rautu sems[10268]: [#b3f51b70] [execute, DSMCoreModule.cpp:569] WARNING: FSM: #code '480' Nov 8 11:56:42 rautu sems[10268]: [#b3f51b70] [execute, DSMCoreModule.cpp:569] WARNING: FSM: #reason 'Temporalily Unavailable' Nov 8 11:56:42 rautu /usr/bin/sip-proxy[10643]: INFO: Routing in-dialog BYE <sip:[email protected]:5068;transport=tcp> from <sip:*77*@test.tutpro.com> to <sip:192.98.102.30:57095;transport=TCP> based on gruu whereas if reply is 486, call is not cleared: Nov 8 11:56:58 rautu sems[10268]: [#b3f51b70] [execute, DSMCoreModule.cpp:569] WARNING: FSM: 'received negative reply' Nov 8 11:56:58 rautu sems[10268]: [#b3f51b70] [execute, DSMCoreModule.cpp:569] WARNING: FSM: #code '486' Nov 8 11:56:58 rautu sems[10268]: [#b3f51b70] [execute, DSMCoreModule.cpp:569] WARNING: FSM: #reason 'Rejected' Nov 8 11:57:13 rautu /usr/bin/sip-proxy[10680]: INFO: Routing in-dialog BYE <sip:127.0.0.1:5090;transport=udp> from <sip:[email protected]> in the above the bye was sent by the caller. i then added to transition "negative reply" set(#processed="true"); but it didn't have any effect. looks like #processed parameter is not valid in B2B.otherReply(). according to dsm_syntax.txt, it is valid in remoteDisappeared(), but when i added that transition to the diag, it did not get executed. so the question still remains: how to avoid call clearing in B2B.otherReply() no matter that the negative reply code is? -- juha _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
