Can someone help me,i counter this error when try to install ldap in kamailio
Compiling ldap_api_fn.c
gcc -fPIC -DPIC -g -O9 -funroll-loops -Wcast-align -Wall -minline-all-stringops -falign-loops -ftree-vectorize -mtune=prescott -Wold-style-definition -Wmissing-field-initializers -Wredundant-decls -DMOD_NAME='"ldap"' -DNAME='"kamailio"' -DVERSION='"1.4.3-notls"' -DARCH='"i386"' -DOS='"linux"' -DCOMPILER='"gcc 4.3.2"' -D__CPU_i386 -D__OS_linux -D__SMP_yes -DCFG_DIR='"/usr/local/etc/kamailio/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -I/usr/local/include -c ldap_api_fn.c -o ldap_api_fn.o
ldap_api_fn.c:38:18: error: ldap.h: No such file or directory
In file included from ldap_api_fn.c:40:
Plzzzzz help me
regards
Husna
This e-mail and the attachments are intended solely for the person to whom it has been addressed. It contains privileged and/or confidential information and is privileged or otherwise protected from disclosure. If you are not the person for whom this e-mail was intended, or the e-mail has reached you by mistake, please delete it immediately and
inform us of the error. Our e-mail address is administrator(a)uniten.edu.my.
All opinions, conclusions and other information in this message that do not relate to the official business of Universiti Tenaga Nasional (UNITEN) shall be understood as neither given nor endorsed by UNITEN. UNITEN shall not be responsible for any activity that may be considered as illegal and/or improper use of e-mail and UNITEN further is claims and shall not accept liability for any content of this e-mail, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing.
WARNING
Internet communications cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, arrive late or contain viruses. As such, we do not accept liability for any errors or omissions in the content of this message which may arise as a result of internet transmission.
UNITEN does not authorize any of its employees to make any defamatory or seditious statements or commit any offence which is contrary to the laws of Malaysia. Any such communications and/or actions by such employees are outside the scope of employment of the said individuals and UNITEN shall not be liable for such communications and/or actions.
I have a client who occasionally sends calls where
there is a npdi=yes tag (and there may or may not be a rn=VALUE
tag present with it), BUT the answer these two tags are
providing is wrong! That is, the number in question has
or hasn't been ported, but the information provided in
the INVITE message doesn't match reality. Either a
rn=VALUE should have had value X and it instead has value Y,
OR there is no rn=VALUE at all, and there should have
been one, OR the number hasn't actually been ported, and
no rn=VALUE should have been sent at all but we got a junk
one, that probably isn't the right LRN for the true destination
of the call.
Because of these wrong npdi=yes tags, our PSTN gateway switch
ends up failing these incorrectly-marked call, because it takes
the provided rn=VALUE or lack of one to be correct and
so it doesn't do its own LNP query, and the one provided in
the SIP INVITE is sometimes just flat out wrong. If the PSTN
gateway switch had ignored these suspect npdi=yes and rn=VALUE
tages and simply done the LNP query itself, in virtually all
cases these otherwise doomed calls would have completed
successfully.
For this particular customer, the problem of bogus values
appears to be a permanent artifact. They either don't know
how to fix it, or don't think it is important, of they are
spoofing it to avoid being billed for LNP queries. Whatever
the reason, it causes trouble tickets. So, we would
like to have SER strip the npdi=yes and any rn=VALUE tags
from the INVITE when it is this customer (known by src ip),
so that the PSTN switch will do the LNP query itself
on the SS7 side and get the call routing right. (We have
already determined that getting the outfit that is sending
the junk to do the right thing isn't going to happen any
time soon.)
Does anybody have any suggestions as how to write the
ser.cfg code to edit-out a npdi=yes and rn=VALUE if they
are present in INVITEs? We just want to always throw
npdi=yes and any rn=VALUE that shows up if the call
is coming from this given customer, basically treating
all npdi=yes and rn= tags coming from this customer as
being untrustworthy.
There has to be an easier way than stripping the thing
down and reassembling a new one with repeated strip(1)
type operations, which looks to be extremely inefficient
for this task and probably really meant only for stripping
country codes and such off the phone numbers, not for
cleaning up bad tags.
Thanks, in advance!
Hello,
Is it possible to do NAT traversal without RTP-PROXY ?
If yes, have you an example?
Cordialement,
BERGANZ François
P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.
Hi, Sir:
In the US, assume a person from 1-408-1234567 is dialing phone number
1234568.
how do I figure out the caller's country code and area code and prepend to
the local number ?
I tried
prefix($(from.user{s.substr, 0, 4}));
and openser reported as parser error in config file, bad argument, string
expected.
Jimmy
Hi
Does anybody know if there is a way to use the set_advertised_address
function with an avp or variable parameter instead of plain string? I
need to change the IP in the Via header with the value of a variable.
Thanks
Catalina
Dear Whom May Concern,
When I try to compile ldap module in kamailio I get error,ldap.h :No such file or directory.
Where can I get that file.please someone help me.
Regards
Husna
________________________________
This e-mail and the attachments are intended solely for the person to whom it has been addressed. It contains privileged and/or confidential information and is privileged or otherwise protected from disclosure. If you are not the person for whom this e-mail was intended, or the e-mail has reached you by mistake, please delete it immediately and
inform us of the error. Our e-mail address is administrator(a)uniten.edu.my.
All opinions, conclusions and other information in this message that do not relate to the official business of Universiti Tenaga Nasional (UNITEN) shall be understood as neither given nor endorsed by UNITEN. UNITEN shall not be responsible for any activity that may be considered as illegal and/or improper use of e-mail and UNITEN further is claims and shall not accept liability for any content of this e-mail, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing.
WARNING
Internet communications cannot be guaranteed to be secured or error-free as information could be intercepted, corrupted, lost, arrive late or contain viruses. As such, we do not accept liability for any errors or omissions in the content of this message which may arise as a result of internet transmission.
UNITEN does not authorize any of its employees to make any defamatory or seditious statements or commit any offence which is contrary to the laws of Malaysia. Any such communications and/or actions by such employees are outside the scope of employment of the said individuals and UNITEN shall not be liable for such communications and/or actions.
Hello,
On 02/13/2009 12:08 PM, Abdul Hakeem wrote:
> Hi,
> Are you able to put me in touch with the guys using the SDP parser ?
>
direct your emails to mailing list all the time. Those people are there,
the developer of SDP parser and others using it. You will get much
faster response and maybe better than writing private emails.
Thanks,
Daniel
> Cheers,
> Abdul Hakeem
>
> -----Original Message-----
> From: Daniel-Constantin Mierla [mailto:miconda@gmail.com]
> Sent: 11 February 2009 15:20
> To: alhakeem(a)ipextelecom.net; kamailio
> Subject: Re: [Kamailio-Users] SIP-T: Multipart SDPs, ISUP parsing, etc
>
> Hello,
>
> On 02/11/2009 03:20 PM, Abdul Hakeem wrote:
>
>> Hi,
>>
>> Just wanted to touch base on the parser to find out if you are still
>> pursuing this.
>>
>>
> it is still on my todo list, however didn't make it in the upcoming 1.5.0.
> Ovidiu Sas did some commits to the SDP parser and I know couple of others
> using it with success.
>
> Please open a feature request at:
> http://sourceforge.net/tracker/?atid=743023&group_id=139143&func=browse
>
> It is easier to track and not forgot about it for the next release.
>
> Thanks,
> Daniel
>
>
>
>> I am in the mind of purchasing some Cisco equipment to do the Sip-MAP
>> gateway from a GSM network.
>> I have someone else from the OpenBTS with me on this.
>> The object is to provide a full fledged sip based routing of voice,
>> sms and multimedia calls from gsm handsets to BTS with a Sip server
>>
> backend.
>
>> Cheers,
>> Abdul Hakeem
>>
>> -----Original Message-----
>> From: users-bounces(a)lists.kamailio.org
>> [mailto:users-bounces@lists.kamailio.org] On Behalf Of
>> Daniel-Constantin Mierla
>> Sent: 03 September 2008 17:45
>> To: Kristian Kielhofner
>> Cc: users(a)lists.kamailio.org
>> Subject: Re: [Kamailio-Users] SIP-T: Multipart SDPs, ISUP parsing, etc
>>
>> Hello,
>>
>> On 09/03/08 19:10, Kristian Kielhofner wrote:
>>
>>
>>> Hello everyone,
>>>
>>> Feel free to set $OSSPROXY to whatever you like =
>>> Kamailio/OpenSIPS/OpenSER (for those of you who can't let go).
>>>
>>> $OSSPROXY is my favorite SIP toolkit. In addition to being an
>>> excellent proxy and registrar it serves as a platform to do SIP
>>> mangling and wrangling. With that in mind let me propose a crazy
>>> idea...
>>>
>>> How hard would it be to get $OSSPROXY to be able to parse what is
>>> commonly referred to as SIP-T (RFC 3372)? I understand $OSSPROXY has
>>> no business getting too involved in the SDP but I feel it makes sense
>>> in some instances (like this one). What if I want to make a routing
>>> decision based on an encapsulated ISUP parameter of some sort? Who
>>> knows what it could be!?!? Maybe there are some other uses but that
>>> makes the most sense and seems to be the most practical. It should
>>> be possible to develop an $OSSPROXY module to:
>>>
>>> - Use the SDP parser to find the ISUP SDP part:
>>>
>>> http://www.kamailio.net/dokuwiki/doku.php/development:sdp-parsing
>>>
>>> - Pass that part into a "real" ISUP parser (if necessary). I
>>> couldn't seem to find the perfect library but perhaps something like
>>> this could
>>> work:
>>>
>>> http://www.openss7.org/isup.html
>>>
>>> - Make the ISUP parameters available via AVPs, pseudo variables, etc
>>> for use in the $OSSPROXY script.
>>>
>>> I don't really have a need for this but it seems like it could be
>>> cool. Am I nuts?
>>>
>>>
>>>
>>>
>> I would expose the body as a dynamic structure, so components will be
>> accessible in the script, e.g. (naming schema just for example),
>>
>> if($body(0=>content-type)=="application/sdp")
>> {
>> if($body(0=>m=>type) == "audio")
>> {
>> }
>> }
>>
>> Based on the available content type parsers (sdp, isup), the structure
>> has different attributes.
>>
>> Cheers,
>> Daniel
>>
>>
>> --
>> Daniel-Constantin Mierla
>> http://www.asipto.com
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users(a)lists.kamailio.org
>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>
> --
> Daniel-Constantin Mierla
> http://www.asipto.com
>
>
--
Daniel-Constantin Mierla
http://www.asipto.com
Hello,
I do as the example in the module registrar doc:
lookup("location");
switch ($?) {
case -1:
case -3:
sl_send_reply("404", "Not Found");
exit;
case -2:
sl_send_reply("405", "Not Found");
exit;
};
And SER report me ERROR:core:pv_parse_spec: wrong char [$/36] in [$?] at [0
(0)]
Know you why?
Cordialement,
BERGANZ François
P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.