Hi folks
First of all thanks to the team for this software. The admin webgui is clean and things are straight forward to configure and everything feels pretty fast and responsive compared to other solutions (config changes are applied almost immediately and even service restarts are pretty fast. It's fun playing around with the 3CX solution).
Part I / II
Keywords: CUBE, Mobile, App, Trunk, SIP, INVITE, SBC, 3CX Tunnel, Cisco, B2BUA
Who can help us:
a) People that have set up a predefined or general SIP trunk and can successfully make calls to the PSTN from the 3CX Mobile App -> You could help us with a trace / by posting the exchanged SIP Messages measured a) on the Mobile device itself and b) On the 3CX PBX (Admin GUI > Dashboard > Activity Log)
b) 3CX Devs/Engineers that could shed some light on how the 3CX PBX processes incoming SIP messages. We're especially interested in which criteria are used to validate incoming SIP messages (as we see "Malformed SIP request received" in the Admin GUI > Dashboard > Activity Log, but can't quite figure out what exactly the 3CX PBX doesn't like about some of them. Check section "What we are seeing" below for detailed information)
What would really help
A reference guide for this particular architecture that shows the expected, ideal SIP messages exchanged between all the involved components to successfully set up a call.
Such a reference would help us craft the SIP messages on the SBC (Cisco CUBE) into the desired format.
(If somebody that got this setup working posts an anonymized trace we can reverse engineer what the SIP messages along the path should ideally look like. Such a trace would ideally also contain the SDP)
Here are some examples of what I mean:
SIP Exchange for some scenario with a CUBE SBC (Cisco), that's Cisco's dialect:
Sip exchange for a scenario with a Dialogic SBC, which talks a slightly different dialect:
Some diagram like the second one above that demonstrates what SIP message order and format 3CX expects from an SBC would be immensely helpful.
Scope / Situation / Setup:
We're running a small PoC where we try to get local 3CX Mobile Clients (App) to make outgoing calls to an external BSC (Cisco CUBE) / the PSTN.
Generic SIP Trunk configuration from 3CX to the BSC (CUBE) is straight forward and so is the configuration of inbound and outbound rules. Device configuration is self explanatory as well and I don't think we're messing up there, but who knows.
What we expect to see:
Calls beween 3CX Mobile Users work flawlessly. (Note: Those are never routed to the BSC and stay within the scope of the 3CX System)
Calls from 3CX Mobile Users to the SBC (CUBE) / PSTN work flawlessly. (Note: Those are sent over a SIP trunk to the BSC)
What we see:
Calls between 3CX Mobile App users work flawlessly.
Calls from 3CX Mobile Users to the SBC (CUBE) / PSTN do go through and it rings on the far end, but a connection can't be established. For some reason the 3CX PBX seems to discard some of the received SIP messages (In particular the 183 Session Progress message) and not pass them on to the 3CX Mobile app. What is really puzzling though is that some of the SIP messages are passed on to the 3CX Mobile App (the 100 Trying message is passed on to the 3CX Mobile App). Result of this behaviour being an incomplete SIP message exchange and funky behaviour on both ends of the call (Infinite ringing on both ends / no call tear down when one of the users terminates the call).
I've tried to sketch out what we've figured out with reverse engineering so far. If we got things wrong, please feel free to lecture us about the correct design.
Here is SIP message (5) and (6) that the 3CX PBX still passes over to the 3CX SBC/to the mobile device:
We can find the SIP message above in the 3CX Mobile Apps logs as well, so for some reason this malformed SIP request makes it all the way from the SBC (Internal) to the 3CX App.
Then something must happen or must have happened within the 3CX PBX. It might crashed due to the malformed SIP request (notice that in the above message the SDP is missing, which might be the actual root cause for the troubles in this case - unfortunately the logs don't clearly state why the message is considered malformed), it might flushed the Call-ID of that particular call because it thought the SIP message is considered corrupt, it might just have disliked the next SIP message because it was considered "too broken to be forwarded" - we really don't know what is happening.
It seems like the 3CX PBX internally tears the call down without sending out the corresponding SIP messages but we honestly can't quite figure out what is happening inside the 3CX core components after that initial 100 Invite message made its way through to the mobile device.
The next SIP message (7) that's sent towards the 3CX Mobile App then never makes it to the mobile device (Traffic in the 3CX tunnel is encrypted and we don't know what's going on in there. Wireshark allows you to sniff on the loopback interface of the 3CX server though - that way we were able to see which SIP messages are passed on to the 3CX SBC as it uses a different port number). We still see the message arriving at the 3CX PBX but now it doesn't seem to get passed to the 3CX SBC anymore.
We guess the 3CX PBS doesn't exactly like the format of the incoming SIP message but we couldn't find any reference what the ideal, incoming SIP messages should look like to make the 3CX PBX happy.
First of all thanks to the team for this software. The admin webgui is clean and things are straight forward to configure and everything feels pretty fast and responsive compared to other solutions (config changes are applied almost immediately and even service restarts are pretty fast. It's fun playing around with the 3CX solution).
Part I / II
Keywords: CUBE, Mobile, App, Trunk, SIP, INVITE, SBC, 3CX Tunnel, Cisco, B2BUA
Who can help us:
a) People that have set up a predefined or general SIP trunk and can successfully make calls to the PSTN from the 3CX Mobile App -> You could help us with a trace / by posting the exchanged SIP Messages measured a) on the Mobile device itself and b) On the 3CX PBX (Admin GUI > Dashboard > Activity Log)
b) 3CX Devs/Engineers that could shed some light on how the 3CX PBX processes incoming SIP messages. We're especially interested in which criteria are used to validate incoming SIP messages (as we see "Malformed SIP request received" in the Admin GUI > Dashboard > Activity Log, but can't quite figure out what exactly the 3CX PBX doesn't like about some of them. Check section "What we are seeing" below for detailed information)
What would really help
A reference guide for this particular architecture that shows the expected, ideal SIP messages exchanged between all the involved components to successfully set up a call.
Such a reference would help us craft the SIP messages on the SBC (Cisco CUBE) into the desired format.
(If somebody that got this setup working posts an anonymized trace we can reverse engineer what the SIP messages along the path should ideally look like. Such a trace would ideally also contain the SDP)
Here are some examples of what I mean:
SIP Exchange for some scenario with a CUBE SBC (Cisco), that's Cisco's dialect:
Sip exchange for a scenario with a Dialogic SBC, which talks a slightly different dialect:
Some diagram like the second one above that demonstrates what SIP message order and format 3CX expects from an SBC would be immensely helpful.
Scope / Situation / Setup:
We're running a small PoC where we try to get local 3CX Mobile Clients (App) to make outgoing calls to an external BSC (Cisco CUBE) / the PSTN.
Generic SIP Trunk configuration from 3CX to the BSC (CUBE) is straight forward and so is the configuration of inbound and outbound rules. Device configuration is self explanatory as well and I don't think we're messing up there, but who knows.
What we expect to see:
Calls beween 3CX Mobile Users work flawlessly. (Note: Those are never routed to the BSC and stay within the scope of the 3CX System)
Calls from 3CX Mobile Users to the SBC (CUBE) / PSTN work flawlessly. (Note: Those are sent over a SIP trunk to the BSC)
What we see:
Calls between 3CX Mobile App users work flawlessly.
Calls from 3CX Mobile Users to the SBC (CUBE) / PSTN do go through and it rings on the far end, but a connection can't be established. For some reason the 3CX PBX seems to discard some of the received SIP messages (In particular the 183 Session Progress message) and not pass them on to the 3CX Mobile app. What is really puzzling though is that some of the SIP messages are passed on to the 3CX Mobile App (the 100 Trying message is passed on to the 3CX Mobile App). Result of this behaviour being an incomplete SIP message exchange and funky behaviour on both ends of the call (Infinite ringing on both ends / no call tear down when one of the users terminates the call).
I've tried to sketch out what we've figured out with reverse engineering so far. If we got things wrong, please feel free to lecture us about the correct design.
Here is SIP message (5) and (6) that the 3CX PBX still passes over to the 3CX SBC/to the mobile device:
We can find the SIP message above in the 3CX Mobile Apps logs as well, so for some reason this malformed SIP request makes it all the way from the SBC (Internal) to the 3CX App.
Then something must happen or must have happened within the 3CX PBX. It might crashed due to the malformed SIP request (notice that in the above message the SDP is missing, which might be the actual root cause for the troubles in this case - unfortunately the logs don't clearly state why the message is considered malformed), it might flushed the Call-ID of that particular call because it thought the SIP message is considered corrupt, it might just have disliked the next SIP message because it was considered "too broken to be forwarded" - we really don't know what is happening.
It seems like the 3CX PBX internally tears the call down without sending out the corresponding SIP messages but we honestly can't quite figure out what is happening inside the 3CX core components after that initial 100 Invite message made its way through to the mobile device.
The next SIP message (7) that's sent towards the 3CX Mobile App then never makes it to the mobile device (Traffic in the 3CX tunnel is encrypted and we don't know what's going on in there. Wireshark allows you to sniff on the loopback interface of the 3CX server though - that way we were able to see which SIP messages are passed on to the 3CX SBC as it uses a different port number). We still see the message arriving at the 3CX PBX but now it doesn't seem to get passed to the 3CX SBC anymore.
We guess the 3CX PBS doesn't exactly like the format of the incoming SIP message but we couldn't find any reference what the ideal, incoming SIP messages should look like to make the 3CX PBX happy.
