Hi Folks,
I have a problem with the hiding of my topology. Topoh module works great.
THX for that. However SDP is not processed by this module. I suppose that
mediaproxy should be the one who should care about this.
Owner(o) part of the body holds original IP of the sender, even thou
Creator(c) part was modified using engage_media_proxy(). Actually this was
reported as a mediaproxy bug, but till now unresolved.
After engage_mediaproxy(): (mind the "o=" and "c=")
v=0
o=- 102971 102971 IN IP4 192.168.0.5
s=-
c=IN IP4 8.8.8.8
t=0 0
.
.
.
So I tried fix_nated_sdp("8","8.8.8.8"). "o" part is OK now but oldmediaip
attribute was added at the bottom of the body. Addition of this attribute
was added to nathelper back in the 2003 for debuging
purposes. Unfortunately this ruins a whole idea of the topology hiding.
After fix_nated_contact(): (mid the "o=", "c=" and last "a=")
v=0
o=- 102971 102971 IN IP4 8.8.8.8
s=-
c=IN IP4 8.8.8.8
t=0 0
m=audio 35008 RTP/AVP 0 2 4 8 18 96 97 98 101
a=rtpmap:0 PCMU/8000
.
.
.
a=rtpmap:101 telephone-event/8000
a=oldmediaip:192.168.0.5
The only "nice" solution I was able to do was changing the source of the
nathelper module.
.
.
body2.s = oldip.s + oldip.len;
body2.len = bodylimit - body2.s;
if (alter_mediaip(msg, &body1, &oldip, pf, &newip, pf,1) == -1) {
LM_ERR("can't alter '%s' IP\n",line);
return -1;
.
.
On the line 1326(alter_mediaip above) in the file kamailio_k/nathelper.c I
changed last argument from 1 to 0. This attribute is called preserve and
adds mentioned "oldmediaip" attribute to the body. Simple changing it to 0
solved the problem.
So I can live with this solution but it would be much more better to have it
from the git repo.
Do I phantom it wrong or this might be considered as a bug? Shouldn't it be
better to have option to configure it?
Tested using last night build of the kamailio.
Thanks for the answer.
Regards,
Efelin
CC (gcc) [M p_usrloc.so] udomain.o
udomain.c: In function ‘new_udomain’:
udomain.c:136: warning: label ‘error2’ defined but not used
Regards,
Ovidiu Sas
On Wednesday 25 May 2011, Daniel-Constantin Mierla wrote:
> [..]
> > The comment "#!KAMILIO" was used to activate the compatibility mode.
> > With 3.1 release this is not needed anymore.
>
> Is this note written somewhere? If yes, then it should be removed, but
> otherwise I see no reason to bother with a comment line in order to add
> more comments.
Hello,
(moved to devel)
i did a quick check to the code, indeed all of the conditions where the mode
was checked are gone now. If nobody object i'd also remove the support for
this directive in the configuration parser, then its gone from the core
completly.
Cheers,
Henning
Hi, the documentation of TLS module says:
---------------------------------------
1.7. Known Limitations
The TLS certificate verifications ignores the certificate name,
subject altname and ip extensions, it just checks if the certificate
is signed by a recognized CA. One can use the select framework to try
to overcome this limitation (check in the script for the contents of
various certificate fields), but this is not only slow, but also not
exactly standard conforming (the verification should happen during TLS
connection establishment and not after).
-----------------------------------------
The last pharse "the verification should happen during TLS connection
establishment and not after" is incorrect. It's true that the SIP node
receiving a TLS certificate should first verify that the certificate
is signed by a recognized CA and it's not expired. This is the first
step and must occur when establishing the TLS session. IF not, drop
the connection.
But in case a proxy/server receives a TLS connection and wants to
authenticate SIP requests based on the certificate, it must extract
the SIP domain identities in the certificate by inspecting each value
in the subjectAltName field with type "domain". And for each SIP
request coming within this TLS connection, the proxy/server could
check whether the From domain matches a SIP domain present in the
certificate, so the request gets automatically authenticated (no need
of requiring SIP authenticationn neither checking the source IP
against a list of trusted IPs).
In order to implement it, I suggest the following behaviour in sip-router:
- A client establishes a TLS session with sip-router.
- The client presents a TLS certificate.
- sip-router extracts the SIP identities of the certificate and stores
them, somehow, in attributes belonging to this TLS session (maybe
pseudovariables).
- In the logic script, it would be possible then to match the From
domain of the request (or whatever) against the list of SIP identities
in the certificate (so authentication is done).
This is important in order to allow real SIP federation (as already
occurs in XMPP world). We all know that SIP federation is not used
yet, but it should in a future.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
CC (gcc) [M auth_db.so] authorize.o
authorize.c: In function ‘authenticate’:
authorize.c:334: warning: enumeration value ‘NONCE_REUSED’ not
handled in switch
authorize.c:334: warning: enumeration value ‘NO_CREDENTIALS’ not
handled in switch
authorize.c:334: warning: enumeration value ‘STALE_NONCE’ not
handled in switch
Regards,
Ovidiu Sas
Hello,
Kamailio SIP Server v3.1.4 stable release is out.
This is a maintenance release of latest stable branch, 3.1, that
includes fixes since release of v3.1.3. There is no change to database
schema or configuration language structure. Deployments running previous
v3.1.x versions are strongly recommended to be upgraded to v3.1.4.
For more details about version 3.1.4, visit:
http://www.kamailio.org/w/2011/05/kamailio-v3-1-4-released/
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.comhttp://linkedin.com/in/miconda -- http://twitter.com/miconda