Alcatel Unleashed

you are correct

REFER is used

Ive done a "motortrace 3" trace , see results below which are the messages sent after the call is up (with two-way speech) for 20 seconds and then is dropped by a bye message sent by OXE ...
my thoughts are it looks like there is a server failure event to do with an Invite ... whether its an incoming or outgoing Invite i cant tell ....
anyone have any thoughts ?


1298025300 -> main.trace.timer = 480mn
1298025305 -> [ipc_thread] IPC Thread : Ipc reception 2107.
1298025305 -> [ipc_thread] IPC Thread : TCL thread signaled.
1298025305 -> [exec_ipc] in 2106.
1298025305 -> [display_ipc_in] ------------ Begin ---------------
1298025305 -> neqt : 1008 Id : -1
1298025305 -> SERVER FAILURE
1298025305 -> xx : 2
1298025305 -> RELATIVE REQUEST : INVITE
1298025305 -> [display_ipc_in] ------------- End ----------------
1298025305 -> [CMotorCallManager::onIncomingEvent] an event 10768 arrived on the eqt 1008--1.
1298025305 -> [CMotorCallManager::onIncomingEvent] state = COMPLETED_STATE.
1298025305 -> [onIncomingEvent] SERVER FAILURE arrived.
1298025305 -> [receiveServerFailureEvent] Call: fae4305f37429dc303c09462e2831369@10.10.9.111 eqt: 1008 COMPLETED_STATE received a not handled event.
1298025305 -> 1153[emitEventToMonitel] content size (lginfo): 656
1298025305 -> 1153[emitEventToMonitel] CAC = 0 eqtCAC = -1
1298025305 -> 1153[emitEventToMonitel] CAC = 0
1298025305 -> [sendLgEvtSip] Event sent on eqt : 1008 Id :-1
1298025305 -> [display_ipc_out] ------------ Begin ---------------
1298025305 -> Id : -1
1298025305 -> ACK
1298025305 -> [display_ipc_out] ------------- End ----------------
1298025305 -> [exec_ipc] in end 2106.
1298025305 -> [ipc_thread] IPC Thread : Ipc reception 2107.
1298025305 -> [ipc_thread] IPC Thread : TCL thread signaled.
1298025305 -> [exec_ipc] in 2106.
1298025305 -> [display_ipc_in] ------------ Begin ---------------
1298025305 -> neqt : 1007 Id : -1
1298025305 -> BYE
1298025305 -> [display_ipc_in] ------------- End ----------------
1298025305 -> [CMotorCallManager::onIncomingEvent] an event 10755 arrived on the eqt 1007--1.
1298025305 -> [CMotorCallManager::onIncomingEvent] state = COMPLETED_STATE.
1298025305 -> [onIncomingEvent] BYE arrived.
1298025305 -> [receiveByeEvent] Call: 0187a119d41e01a14d4d66601900 eqt: 1007 COMPLETED_STATE received an event.
1298025305 -> 1152 [CCall::makeGenericRequest] BYE
1298025305 -> 1152 [CCall::getDialog] Confirmed Dialog found
1298025305 -> 15bd [CDialog::createRequest]
1298025305 -> 15bd [CDialog::buildServicesForAllRequest]
1298025305 -> 15bd [CDialog::createByeRequest]
1298025305 -> 219c [CTransaction::changeState] STATE CHANGED TO INITIAL
1298025305 -> 219c [CTransaction::changeState] notifying the parent dialog
1298025305 -> 15bd [CDialog::onTransactionState(pTrans = 219c, previousState = Terminated, currentState = Initial, reason = None]
1298025305 -> 4A0 [CRequest::CRequest] Creation of a request
1298025305 -> 4A0 [CMessage::send] sip_sendMessage (10.10.9.34:5060)
1298025305 -> SEND MESSAGE TO NETWORK (10.10.9.34:5060 [TCP]) (BUFF LEN = 701)
----------------------utf8-----------------------
BYE sip:41000@10.10.9.45;transport=tcp SIP/2.0 Route: <sip:17182ac4@10.10.9.34;transport=tcp;lr> Route: <sip:10.10.9.33:15060;lr;sap=-1376366123*1*016asm-callprocessing.sar554240522~1298028974657~63474230~1;transport=tcp> Route: <sip:17182ac4@10.10.9.34;transport=tcp;lr> Route: <sip:10.10.9.45;transport=tcp;lr> Supported: replaces,timer,100rel User-Agent: OmniPCX Enterprise R9.1 i1.605.16 To: sip:41000@mmsil.local;tag=0187a119d41e01a04d4d66601900 From: sip:36002@10.10.9.34;tag=7ef82abdadfff2d8333cf10e56d63dd5 Call-ID: 0187a119d41e01a14d4d66601900 CSeq: 1132665891 BYE Via: SIP/2.0/TCP 10.10.9.111;branch=z9hG4bKe279a2c04631310ccf93b8a87f8df28c Max-Forwards: 70 Content-Length: 0 -------------------------------------------------
1298025305

Would be good if you post the whole trace and not just the bye message.

tommyphelan wrote:anyone have any thoughts ?

Does OXE support unattended transfer feature between two SIP trunk groups? Who knows? No one here answered - yes, it should work.
Though transfer is a basic feature of all switches, and it should work, we can spend a lot of time trying to find it empirically but now as we did not find any answer the best way is to ask the vendor - did he implement this?

hi, see attached full motortrace log for the un-attended transfer.

alex wrote:

tommyphelan wrote:anyone have any thoughts ?

the best way is to ask the vendor - did he implement this?

the vendor is looking to implement the type of scenario i am testing, i dont know if they have done a similar test before but i can ask