VoIP Mailing List Archives

[freeswitch-users at li...]

------ Start of attached email. Subject: Re: REGISTER with Telekom SIP Trunk ------
Hello Johannes, hello list!

I just found your post because I'm trying to achieve the same thing waht's already
implemented for asterisk long time ago.

A few things to clarify the goal of the desired change a bit more:

- The standard registration with Telekom AllIP works just fine (regarding SIP over
TLS e.g.)
- But if you additionally want to use encrypted RTP, you have to go through
mediasec enabled registration. That's what you described partly below.


I want to go a bit more into deep how mediasec works at Deutsche Telekom. It's an
extension of the regular registration process. It works like this (RFC3329) (only
the additional headers of the regular register added):


(1) ----> (Request sent by FS)
REGISTER sip:tel.t-online.de SIP/2.0
CSeq: 12735 REGISTER
...
Security-Client: sdes-srtp;mediasec
Proxy-Require: mediasec
Require: mediasec

(2) <---- (Response sent to FS)
SIP/2.0 494 Security Agreement Required
CSeq: 12735 REGISTER
...
Security-Server: msrp-tls;mediasec
Security-Server: sdes-srtp;mediasec
Security-Server: dtls-srtp;mediase

(3) ---->
REGISTER sip:tel.t-online.de SIP/2.0
CSeq: 12736 REGISTER
...
Security-Verify: msrp-tls;mediasec
Security-Verify: sdes-srtp;mediasec
Security-Verify: dtls-srtp;mediasec

(4) <-----
SIP/2.0 401 Unauthorized 11030030345
CSeq: 12736 REGISTER
...
Security-Server: msrp-tls;mediasec
Security-Server: sdes-srtp;mediasec
Security-Server: dtls-srtp;mediasec

(5) ---->
REGISTER sip:tel.t-online.de SIP/2.0
CSeq: 12737 REGISTER
...
Security-Verify: msrp-tls;mediasec
Security-Verify: sdes-srtp;mediasec
Security-Verify: dtls-srtp;mediasec

(6) <----
SIP/2.0 200 OK
...


To summarize it:
mediasec adds one additional request / response process at the beginning of the
known registration process and a few additional headers:
Requesting mediasec (it's the known register start plus additional headers) and
the response is 494 Security Agreement Required. From now on registration works as
usual except for those three additional headers.

I searched and found lots of documentation. Therefore I found a pretty easy way to
add those additional headers (in the C code) and I'm able to start the mediasec
process. Unfortunately, I'm not able to handle / route this additional
request/response process right at the beginning, because sofia doesn't provide any
means to modify the registration process based on freeswitch (id est: without
changing sofia). Is this correct? Or is there nevertheless a way to integrate this
additional request / response because I overlooked something?

I am able to get the 494 in freeswitch, but I don't know how to exactly proceed
because sofia doesn't know anything about this process and sofia has its own
definition on how to do registration. Maybe some of you do have any idea?

Basically it's pretty easy: after the first preceeding request / response, the
"real" registration has to be (re)started. That's how it's possible in asterisk.

The key point is, that the "restarted" registration process must know about the
fact that the mediasec process has already been done, because after the 494, you
have to set three other headers in the register as before (compare (1) and (3) above).

The registration process is started with nua_register(). It probably would work if
it would be possible to just silently (= do not send anything to the SIP provider
at all) end the complete registration process after the 494 and immediately
restart it again right from the beginning (plus three additional headers) - at
this moment, the registration process itself works normally as sofia expects it.


If registration proceeds, the next and last step is to add the
a=3ge2ae:requested
to the outgoing invite's SDP. At the moment, I don't know how to do it - but the
reason is pretty simple: I first have to solve registration - afterwards let's do
the next step.



Thanks for any help!
Gregor

On 17.08.21 at 09:00 Schäffner, Johannes wrote: