pact contract for outbound call init passes locally. hitting 403 in prod when architect flow tries to attach media. sip stack version 2.4.1.
{
“status”: 403,
“reason”: “Media policy violation”
}
checking the sip headers. looks like the from-uri is getting mangled by the edge.
That 403 isn’t a SIP header issue. It’s the media policy engine rejecting the stream before it even hits the SIP stack. The From-URI might look wrong in logs, but the edge usually rewrites that for routing anyway.
Check the outbound media profile in the architecture flow. You’re likely trying to push a codec or encryption method that the target endpoint doesn’t support, or the policy requires DTLS and your config is sending SRTP only.
Verify the mediaPolicyId in your outbound connector config. If it’s null, it falls back to default, which is strict. Try forcing a specific policy that allows opus and g711 with unencrypted media if this is a test environment.
Also, check the sipStack logs for the actual SDP offer. The 403 usually fires when the a=crypto line is missing or malformed.
The suggestion above is spot on. I’ve seen this exact 403 when the media profile doesn’t explicitly allow the codec the edge negotiates. Don’t rely on defaults. You need to pin the codec in the media profile config. Here’s the payload that fixed it for us last quarter. It forces G.711 and disables SRTP if the target doesn’t support it. The key is the enabled flag on the codecs array.
{
"name": "Outbound Strict Media",
"codecs": [
{
"name": "G711ULAW",
"enabled": true,
"priority": 1
},
{
"name": "G711ALAW",
"enabled": false,
"priority": 2
}
],
"encryption": {
"type": "none"
}
}
Update the profile via PUT /api/v2/outbound/media/profiles/{mediaProfileId}. The flow will pick it up instantly. No restart needed. Check the encryption block too. If you leave it open, the edge might try SRTP and fail silently before the 403.
Honestly, I’m a bit out of my depth here with the SIP stack and media policies. My world is mostly about keeping agents happy with leaderboards and gamification metrics, not debugging 403 errors on outbound media streams. That said, the advice about checking the media profile configuration seems really solid. If the edge is rejecting the stream before it even hits the SIP stack, it’s probably a policy mismatch as mentioned above.
Just a thought from a process perspective: have you checked if there are any recent updates to the security policies that might be blocking specific codec negotiations? Sometimes these things happen after a platform update without much fanfare. It’s always worth double-checking the release notes. Until this is sorted, are you seeing any impact on agent performance or just failed call attempts? Might be worth flagging with the network team if you’re stuck.
The media policy rejection is likely tied to how the outbound flow handles state. I’d suggest pinning the codec in the Terraform resource to match the edge requirements, avoiding any drift.
resource "genesyscloud_outbound_campaign" "test" {
media_policy_id = var.strict_media_id
}
This forces the correct policy attachment.