[asterisk-dev] Asterisk 18.16.0-rc1 Now Available

Michael Maier m1278468 at mailbox.org
Tue Dec 20 10:10:35 CST 2022


Hello Max,

On 20.12.22 at 11:29 Fridrich Maximilian wrote:
> Mr. Maier,

Michael :-)

> 
> thank you very much for your feedback! We provided this specifically
> for Telekom's "CompanyFlex" trunks which still require mediasec headers
> according to their website [1]. Specifically, we have to adhere to
> their technical specification 1TR119 [2].

Well, for Telekom MagentaZuhause, the headers must look like this to work (there 
seems to be a difference to the CompanyFlex servers):

Security-Client: sdes-srtp;mediasec
			  ^^^^^^^^^
The ",mediasec" is missing.

Further more, if you configure (id est: a list)
security_mechanisms=sdes-srtp,...
always the first entry of the list configured above is dropped in the following 
register request. Is this fixed by your mentioned patch below?

Example:
Request
Response 401
Request (now without first entry of the list)
	Security-Client: ...

> 
>> Does your patch work, too, if a server doesn't answer the Mediasec
>> request?
> 
> We set the Require: mediasec header, so if a server does not understand
> this, it MUST respond with 420 Bad Extension.

The new consumer VoIP server just ignores it ...

> Nonetheless, if you have
> configured mediasec a server could ignore the mediasec headers and still
> send 2XX replies to our requests. Since the mediasec headers are static
> and no real security mechanism is negotiated anyways (all we need to do
> is satisfy Telekom's requirements), we still allow further transactions
> to take place (which is not how RFC 3329 intends it).

Same as I do :-)

> However, it does
> affect the SDP by setting the 3ge2ae attribute, even if the server never
> sent us Security-Server headers.

[...]

>> I wasn't able to get it working. The headers you are setting
>> unfortunately doesn't meet the Deutsche Telekom requirements - besides
>> one additional bug.
> 
> Thank you for testing it! We have identified similar issues (see
> ASTERISK-30276) and I just uploaded a patch fixing those [3]. I believe
> this patch fixes the issues you are seeing. In our setup, it seems to
> be working fine - including outgoing calls, re-registrations, and
> OPTIONS.
> 
> Please let me know, if you are still experiencing issues with the new
> patch.

I think the different headers are not addressed?


Thanks
Michael



More information about the asterisk-dev mailing list