Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

On 21.12.22 at 16:53 Michael Maier wrote:

On 21.12.22 at 15:52 Fridrich Maximilian wrote:

I got it working now with [...]


That is excellent news!


I meanwhile sent Max some more information about missing things (like missing 
parameter information in pjsip show endpoint|registration and not working retry 
path (which breaks calls) among others).



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

On 21.12.22 at 15:52 Fridrich Maximilian wrote:

I got it working now with [...]


That is excellent news!


But the remaining useless headers in Invite should be removed before the 
final release.



I think this should be part of the documentation.


I'm not a maintainer but I think usually the documentation is kept
quite general without describing specific use cases. The docs for the
security_mechanisms parameter say "This is a comma-delimited list of
security mechanisms to use. Each security mechanism must be in the form
defined by RFC 3329 section 2.2." [1]. I think this should suffice.


Sorry - I wasn't able to derive the options string needed *for your 
implementation* based on RFC 3329 section 2.2. For me it wasn't obvious, 
that the ';mediasec' has to be added (I would have expected, that this 
is done automatically if the first parameter is set to mediasec 
(security_negotiation=mediasec))


security_mechanisms=msrp-tls\;mediasec,sdes-srtp\;mediasec,dtls-srtp\;mediasec

Therefore I still think this must be part of the documentation. What's 
wrong to provide an example for a (specific) use case? Why should it be 
secret? This way, users know, how the config option has to be used 
without long try and error to guess the correct syntax.



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Fridrich Maximilian]

> I got it working now with [...]

That is excellent news!

> I think this should be part of the documentation.

I'm not a maintainer but I think usually the documentation is kept
quite general without describing specific use cases. The docs for the
security_mechanisms parameter say "This is a comma-delimited list of
security mechanisms to use. Each security mechanism must be in the form
defined by RFC 3329 section 2.2." [1]. I think this should suffice.

> The Invite has to many headers

Thank you, I will look into it.

> I did not test options and reInvite. Did you test reInvites?

I have tested OPTIONS and in my current setup I have only tested
re-INVITES on outgoing calls from the caller.

Best,
Max

[1] 
https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Configuration_res_pjsip#Asterisk18Configuration_res_pjsip-endpoint_security_mechanisms

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

On 21.12.22 at 09:17 Michael Maier wrote:

On 21.12.22 at 08:21 Fridrich Maximilian wrote:

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


Yes, the security_mechanisms option is a comma separated list of the
literal security_mechanisms that should be used. I.e. you have to
specify security_mechanisms=sdes-srtp\;mediasec,dtls-srtp\;mediasec
(don't forget to escape the semicolon).


I got it working now with (order has been important if I remember correctly)

security_mechanisms=msrp-tls\;mediasec,sdes-srtp\;mediasec,dtls-srtp\;mediasec

I think this should be part of the documentation.


But:
The Invite has to many headers - those are not needed (or is it Telekom 
specific?):

Security-Client: msrp-tls;mediasec
Security-Client: sdes-srtp;mediasec
Security-Client: dtls-srtp;mediasec

Maybe remove them?


Just detected some more eventually unneeded headers in Invite:

Require: mediasec
Proxy-Require: mediasec


Those three headers in Invite seem to be enough (besides the a=3ge2ae:requested in 
SDP) - couldn't see any problem during ~ 3 years until now.


Security-Verify: msrp-tls;mediasec
Security-Verify: sdes-srtp;mediasec
Security-Verify: dtls-srtp;mediasec


Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

On 21.12.22 at 08:21 Fridrich Maximilian wrote:

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


Yes, the security_mechanisms option is a comma separated list of the
literal security_mechanisms that should be used. I.e. you have to
specify security_mechanisms=sdes-srtp\;mediasec,dtls-srtp\;mediasec
(don't forget to escape the semicolon).


I got it working now with (order has been important if I remember correctly)

security_mechanisms=msrp-tls\;mediasec,sdes-srtp\;mediasec,dtls-srtp\;mediasec

I think this should be part of the documentation.


But:
The Invite has to many headers - those are not needed (or is it Telekom 
specific?):

Security-Client: msrp-tls;mediasec
Security-Client: sdes-srtp;mediasec
Security-Client: dtls-srtp;mediasec

Maybe remove them?




always the first entry of the list configured above is dropped in
the following register request. Is this fixed by your mentioned patch
below?


I could not reproduce this behavior. I just tested it with the current
patch and no list entries were dropped.


Yes - the current version including your additional patch doesn't show this 
behavior any more.





I think the different headers are not addressed?


Do you mean the missing ";mediasec" values? That is due to the
configuration, as stated above. Besides that, I'm quite confident it
behaves as intended, we have been running test systems for quite a
while now.

I hope we can resolve your issues, it would certainly be desirable if
this patch worked for more than just very specific Telekom servers.


Yes - that would be very good! Please think about documentation using some 
practical examples to get a working connection!



I tested inbound and outbound calls. I did not test options and reInvite. Did you 
test reInvites?



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Fridrich Maximilian]

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

Yes, the security_mechanisms option is a comma separated list of the
literal security_mechanisms that should be used. I.e. you have to
specify security_mechanisms=sdes-srtp\;mediasec,dtls-srtp\;mediasec
(don't forget to escape the semicolon).

> always the first entry of the list configured above is dropped in
> the following register request. Is this fixed by your mentioned patch
> below?

I could not reproduce this behavior. I just tested it with the current
patch and no list entries were dropped.

> I think the different headers are not addressed?

Do you mean the missing ";mediasec" values? That is due to the
configuration, as stated above. Besides that, I'm quite confident it
behaves as intended, we have been running test systems for quite a
while now.

I hope we can resolve your issues, it would certainly be desirable if
this patch worked for more than just very specific Telekom servers.

Best,
Max

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

On 20.12.22 at 17:10 Michael Maier wrote:

Hello Max,

On 20.12.22 at 11:29 Fridrich Maximilian wrote:

Please let me know, if you are still experiencing issues with the new
patch.


I think the different headers are not addressed?


Just tested it - doesn't work.

It is fine for me if you don't want to address the requirements of VoIP 
MagentaZuhause. But it would be good, I think, if you would add the information to 
the documents page, that this implementation is not a generic mediasec 
implementation, but a specific Telekom CompanyFlex one :-), which doesn't work 
with MagentaZuhause (or some others, too).


If I remember correctly, somebody told me my patch would have been working, too, 
with CompanyFlex - but I'm not sure any more. This could be wrong, too. It has 
been quite some time ago 



Thanks
Michael




--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

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

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Fridrich Maximilian]

Mr. Maier,

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].

> 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. 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). However, it does
affect the SDP by setting the 3ge2ae attribute, even if the server never
sent us Security-Server headers.

> Do you maybe plan to get asterisk ready to cope with 3 completely
> independent SIP servers provided by the SRV lookup?

Unfortunately, I will probably not have time to look into that in the
near future. As stated above, we provided this patch to work with SIP
trunks (e.g. CompanyFlex) that explicitly require mediasec.

> 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.

Thanks,
Max

[1] https://hilfe.companyflex.de/de/grundlagen/systemvoraussetzungen
[2] https://www.telekom.de/hilfe/downloads/1tr119.pdf
[3] https://gerrit.asterisk.org/c/asterisk/+/19740

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

On 17.12.22 at 18:21 Michael Maier wrote:

On 15.12.22 at 14:39 Asterisk Development Team wrote:


# [ASTERISK-30032 ] -
    Support of mediasec SIP headers and SDP attributes
(Reported by Maximilian Fridrich)


Hi Maximilian,

today I tried your implementation with Deutsche Telekom (MagentaZuhause).

My configuration:
security_negotiation=mediasec
security_mechanisms=sdes-srtp(,dtls-srtp,msrp-tls)

for endpoint and registration.


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.


If you compare it to my patch, you most probably will see the differences / the 
bug.

Please be careful as Deutsche Telekom not always responds with 494 during 
registration and even authorization during registration isn't always necessary 
(only sometimes)! You should have a close look over ~1 day and each reRegistration 
to be sure to get each possible procedure! Try to force reRegistrations with pjsip 
send register ... and carefully check the headers. Does it still work 1 hour later 
(in- and outbound calls)?


The registration implementation is not necessarily ok if the registration is fine 
(no error is thrown)! You must try to place an outgoing call e.g. - this call must 
work! At the moment, the registration proceeds, but outgoing calls are rejected 
(403 Forbidden). The cause is, that the registration wasn't correct and therefore 
srtp isn't possible - but Deutsche Telekom requires / enforces srtp if tls is active!


Here you can see how it should look like: 
https://www.ip-phone-forum.de/threads/telekom-all-ip-privat-endlich-erfolgreiche-registierung-ssl-tls-m%C3%B6glich.300166/page-3

(Meester Proper is a very good skilled employee of Deutsche Telekom)

Btw:
- Are Options packages working? Did you test this, too?
- I can provide my mediasec patch for 18.16.0-rc1 if you want to have it.



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Asterisk 18.16.0-rc1 Now Available

[Michael Maier]

On 15.12.22 at 14:39 Asterisk Development Team wrote:


# [ASTERISK-30032 ] -
Support of mediasec SIP headers and SDP attributes
(Reported by Maximilian Fridrich)


Hi Maximilian,
thanks for adding Mediasec support to asterisk! Unfortunately somewhat late - at 
least regarding Deutsche Telekom consumer infrastructure. Telekom started quite 
some time ago dropping the Mediasec requirement for their SIP servers. The new SIP 
servers like


[city]-l01-mav-pc-rt-001.edns.t-ipnet.de

don't need any Mediasec headers any more. Those servers are meanwhile often the 
primary ones provided by the SRV lookup (if they already exist for the location 
you are requesting for).


But the old ones, which are still provided currently with lower priority, still 
need it. Therefore it is necessary to enable Mediasec nevertheless to be able to 
change to them if necessary. Does your patch work, too, if a server doesn't answer 
the Mediasec request?




Another question:
Do you maybe plan to get asterisk ready to cope with 3 completely independent SIP 
servers provided by the SRV lookup? Currently, asterisk can't handle it (it must 
be ensured that all subsequent requests after the register must use the same 
server previously registered to and not any other server of the list. Before 
switching to another server, it's necessary to unregister the current active 
server and afterwards register to the new one).



Thanks
Michael

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev