While functionally, yes, you are correct; the media address does not need to be in the SIP ACL. However, and this is mostly from my experience, that in doing so, adds a measure of resiliency without a significant security or performance risk should something change.
This experience mostly comes from dealing with small regional CLECs that tend to, "do whatever the hell they want" and may switch signaling/media ..etc. Granted, a bigger carrier like CenturyLink is highly unlikely to do something like that or at least without a decent amount of notification. Thanks, Ryan ________________________________ From: NateCCIE <natec...@gmail.com> Sent: Wednesday, September 12, 2018 9:54 PM To: 'Ryan Huff'; 'Jason Aarons (Americas)'; 'cisco-voip' Subject: RE: [cisco-voip] CUBE setup to Centurylink SIP Trunk I don’t see any reason to include the media address in the trusted list. That would be like including all IP phones in the trusted list. A lot of the time I only route specific IPs to the outside next hop, as a security measure. If they didn’t indicate where the media was coming from, it would be easy to miss that and get one way audio. And centurylink has many SIP plaforms, the registration one with multi-tennant configs for dual registration is the Broadsoft platform, the sonos platform isn’t adding new customers, and then there is the IP TollFree/LD, that one is still current and doesn’t require registration. There also are at least two Level3 platforms that are now “centurylink” Thanks, -Nate From: cisco-voip <cisco-voip-boun...@puck.nether.net> On Behalf Of Ryan Huff Sent: Wednesday, September 12, 2018 7:31 PM To: Jason Aarons (Americas) <jason.aar...@dimensiondata.com>; cisco-voip (cisco-voip@puck.nether.net) <cisco-voip@puck.nether.net> Subject: Re: [cisco-voip] CUBE setup to Centurylink SIP Trunk Target the signaling address in your dial peers, the media address will be advertised in the SDP. Make sure to include both in your IP Trusted List ACL (under the voice service voip configuration) as well as any CUCM signaling nodes that are not directly targeted by a dial-peer (but I typically add all the nodes in regardless, just as a measure of safety). Thanks, Ryan ________________________________ From: cisco-voip <cisco-voip-boun...@puck.nether.net<mailto:cisco-voip-boun...@puck.nether.net>> on behalf of Jason Aarons (Americas) <jason.aar...@dimensiondata.com<mailto:jason.aar...@dimensiondata.com>> Sent: Wednesday, September 12, 2018 8:37 PM To: cisco-voip (cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>) Subject: [cisco-voip] CUBE setup to Centurylink SIP Trunk I have a new CenturyLink SIP Service. CenturyLink said it is new and doesn't match the Cisco guides. (No more of the funky registrar and fixup headers via SIP profiles!) In short in CUBE they want me to send calls to them per these settings; SIP Signaling IP 6.6.156.245:5060 RTP IP 6.6.156.244 I'm just drawing a blank on how to setup CUBE to send SIP signaling requests to CenturyLink with different Signaling and RTP destination addresses. Don't I just send session target ipv4:X.X.156.245:5060 and the SDP takes care of the RTP negotiation part? Do I really care in my CUBE what their RTP address is? -jason This email and all contents are subject to the following disclaimer: "http://www.dimensiondata.com/emaildisclaimer";<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Feur04.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%253A%252F%252Fwww.dimensiondata.com%252FGlobal%252FPolicies%252FPages%252FEmail-Disclaimer.aspx%26data%3D02%257C01%257C%257Cce21fa3547064a9bd8a008d619112c06%257C84df9e7fe9f640afb435aaaaaaaaaaaa%257C1%257C0%257C636723958879576925%26sdata%3D2PDRGixdvFatDGAD1sCQrYgXUKSWNBa3LSzCbk7wYJQ%253D%26reserved%3D0&data=02%7C01%7C%7Cc2c08ca28d6a4d39cff208d6191bca6f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636724004485171057&sdata=wWlL90U9dsyW%2FQEbY1aKfwn33Cc6Z7J8feMe7zykNso%3D&reserved=0>
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
