Acme Packet (MOSC)

MOSC Banner

Why does ESBC relay non-SIP TCP traffic out-of-the-box without explicit configuration?

in Acme Packet (MOSC) 4 commentsAnswered

Hello,
My Oracle ESBC version is SCZ10.1.0 GA.

I am testing an IVR → Oracle SBC → TTS Server workflow, and I observed an unexpected behavior regarding how the SBC relays the independent TCP control stream (MRCPv2) that I'd like to understand architecturally.

The Call Flow & PCAP Analysis:The call starts as a pure audio call.In the middle of the call, the IVR sends a SIP Re-INVITE to trigger the TTS capabilities. The SDP explicitly negotiates the MRCPv2 channel as follows:
m=application 9 TCP/MRCPv2 1
a=setup:active
a=connection:new
a=resource:speechsynth

Naturally, this SIP Re-INVITE only establishes the session parameters and contains no application payload (no text to be synthesized).Immediately after this Re-INVITE handshake completes, the IVR begins sending actual application data over the newly established TCP stream. I captured the TCP packets on the SBC and confirmed that the raw MRCP messages (e.g., MRCP/2.0 SPEAK ... <Text Payload>) are being successfully source-NATed and relayed by the SBC to the backend TTS server on destination port.

Tagged:

Howdy, Stranger!

Log In

To view full details, sign in to My Oracle Support Community.

Register

Don't have a My Oracle Support Community account? Click here to get started.

Category Leaderboard

Top contributors this month

New to My Oracle Support Community? Visit our Welcome Center

MOSC Help Center