ip-codec set

[trilogy8]

how do I get the bottom section about the media encryption to appear. when I do a change ip-codec-set x I don't get the options or even have them visible for that bottom section.

 

[trilogy8]

nevermind... media encryption over IP is set to 'n'. is setting that to 'y' impacting?

 

[kyle555]

No. set it in the license in the CM web page.

Just remember to add none as a last choice, otherwise anything that can't do SRTP will fail.

There's a lot more to it than just adding it in the codec set btw.

 

[trilogy8]

when I first enable it what will be populated in that bottom section initially? Trying not to make anything currently working from going crackers once it's enabled.

 

[kyle555]

Nono, when you first enable it, the fields appear at the bottom of the screen.

There's a bunch of kinds of encryption to choose from.
If your first choice is 'none' and 2nd/3rd are some algorithm, then the default is to not be encrypted and an endpoint that DOESN'T support unencrypted communication would use choice 2 or 3.

Conversely, if you don't have 'none' entered as your last choice, then any phone that can't do encrypted calls will fail.

 

[trilogy8]

I enabled the feature, no issue. I added in the wide band codecs and at the bottom I selected the SRTP80, 32 and None respectively. When I attempt to make a call out from these 3rd party SIP devices I get 488 Transport Not Secure. I tried changing the order and not having any luck. I thought for sure it was codec and encryption settings.

 

[kyle555]

Nope. if you want secure media, you need TLS SIP signaling. The encryption keys are sent in the signaling and CM won't let you set up SRTP if the SIP signaling is TCP.

 

[trilogy8]

Not following. The SIP endpoint is registered to ASM via TLS and the ASM entity link to CM is TLS. CM SG/TG is TLS too.

 

[kyle555]

488 usually gets a 'not acceptable here' - like I send a SIP message for G729 over a trunk that responds only supporting G711.

Transport not secure usually means just that - some leg of the call is in TCP. If you were to look at the invite that ultimately results in the 488, in the contact and via headers, do you see anything that's TCP and not TLS?