ASBCE direct media path/rtp relay

[RINGINnBLINGIN]

The layout:
IPOffice is connected to SBC via TLS.
- There are phones that connect to the IPoffice internally
o These phones utilize direct media path to stream RTP traffic directly to the service provider
SBC supports the sip trunk to service provider
- There are remote phones that connect to the SBC
o These phone need to NOT use direct media path, and need to leverage the RTP relay of either the SBC or IPO


the session policies have been configured to require/not require media anchoring for remote/inside, respectively. this actually works like a champ with one major caveat....

the session flows are based on priority, not a value.
so, when the session flow for direct media is 1, the internal phones connect and stream traffic directly to the SP, as designed. However, the remote phones say they are using the RTP relay, but to the SP, which translates into no audio.
when the "no direct media" takes priority, there is audio throughout. The remote phones connect and use the SBC for the rtp relay, as designed. However, the internal phones also use the RTP relay and never connect directly with the SP.

what i am thinking is the priority session flow needs to be narrowed down enough so the opposite "fails" to priority 2. for example, we've tried to set a uri group to include "(one extension)@*" to force all other phones to use the priority 2 but it did not work.

Any thoughts?

 

[janni78]

I don't quite get what you're trying to do.
Why would the phone connect directly to the SP?
The point of the SBC is that it anchors signaling and RTP between internal and external.

Also I wouldn't run TLS on IP Office, it doesn't handle that well although you might not notice anything unless you have high call volumes.

"Trying is the first step to failure..." - Homer

 

[RINGINnBLINGIN]

There are multiple sites that utilize a contact center. The contact center solution requires all agents to be registered to the primary. In order to not flood the MPLS, the phones stream media directly to the SP. This actually resulted in a better quality audio. The call is setup through the SBC/IPO and then handed off to the device/trunk.

The SBC can allow/force/deny calls from being anchored in various ways. Both of the ways I described originally work, just not simultaneously. This is what we are trying to accomplish.

I am unfamiliar with the limitation of TLS and IPO. Is there any documentation that suggests call volume limits?