Cube dual trunk

[Peterson Cristovam]

Hi I am enabling dual trunk to SIP Provider on the CUBE and I am getting a strange behavior Cube uses the same IP source for both trunks. Both trunks are registered. No issues Inbound calls are working in both trunks. No issues Outbound calls are working in both trunks. No issues The problem occurs when there is an RE-INVITE or update. If the cube receive a call from the second trunk sip for example, and a re-invite it needs, the cube does not send the signaling to the same trunk that received. It is sending the signaling to the first sip trunk. is there a command (I think should be the default behavior), to cube preserve the full signaling in the original trunk?

[Jonathan Schulenberg]

If I understand you correctly, you’re saying that CUBE receives a mid-dialog reINVITE from one side and instead of sending it within the existing dialog on the other side it creates a new one? IF true that would be a defect because CUBE should recognize the existing dialog state based on the Call-ID headers. Can you share a properly redacted config (ie no passwords) and the output of ‘debug ccsip messages’ showing an example of this? Please note the calling/called numbers and what the IPv4 addresses involved in the debug are. Also what equipment and IOS version?

[Mohammed al Baqari]

+5 Jonathan. In fact cube won't perform route lookup for reINVITE. If CUBE
receives reINVITE without existing call it will send 487 call leg doesn't
exist

[Ayodeji Okanlawon]

Just to add to what Jonathan and Mohammed have both said. CUBE will send RE-INVITE to the contact header in the dialog, since RE-INVITE is a future request. Now for your call to have been successfully completed then the contact header is correct because your ACK is also sent to the contact header. To understand what is going on fully, we will need your logs as requested. We need to see debug ccsip messages from CUBE.