That info should be in the INSTALL file.
On Tue, Feb 8, 2011 at 8:27 PM, Robin Malhotra wrote:
> Hi,
>
> Please let me know how to compile a module. I am a beginner.
>
> Say a module xyz
>
> usr/src/opensips-1.6.2-tls/modules/xyz
>
> Please let me know the process to compile the module
>
>
> T
I have not seen a response to this question yet, and it is of particular
interest to me. I don't suppose anyone has any comments on getting OCP to
query multiple servers. Thoughts?
Much appreciated.
-dg
On Fri, Jan 28, 2011 at 4:46 PM, Cinthia Leung wrote:
> Hello,
>
> I have several OpenSI
Hi,
Please let me know how to compile a module. I am a beginner.
Say a module xyz
usr/src/opensips-1.6.2-tls/modules/xyz
Please let me know the process to compile the module
Thanks
--
Robin
___
Users mailing list
Users@lists.opensips.org
http://list
"Now you now, and knowing is half the battle."
-- G.I. Joe
On 2/8/11 5:36 PM, "Ovidiu Sas" wrote:
>yup
>
>On Tue, Feb 8, 2011 at 5:15 PM, Jeff Pyle wrote:
>> Got it.
>>
>> Am I to believe, then, that only the initial "initialized" UAC INVITE
>>hits
>> the local r
Chris,
What does an ngrep trace on the interface (interfaces?) of the machine
show? Are the packets changed when they leave the machine? In that
case it must be happening on that machine, i.e. no external firewall
munging. If that is the case then run OpenSIPS with debug level 9 or
so, save th
Ovidiu,
On Tue, Feb 8, 2011 at 2:31 PM, Ovidiu Sas wrote:
> You din't posted a proper SIP capture (no UDP src/dst IP for your
> packets), but it seems that you are having a firewall issue. Just add
I agree that it almost sounds like a firewall issue butI
completely disabled iptables on the
yup
On Tue, Feb 8, 2011 at 5:15 PM, Jeff Pyle wrote:
> Got it.
>
> Am I to believe, then, that only the initial "initialized" UAC INVITE hits
> the local route? Everything after that for a dialog is visible in the b2b
> ones only, and therefore untouchable?
>
>
> - Jeff
>
>
> On 2/8/11 4:58 PM,
Hello Bogdan,
I figured it out, and here's the answer.
On Fri., Feb 04, 2011, Bogdan-Andrei Iancu wrote:
> opensipsl...@encambio.com wrote:
>> I'm using:
>>
>> Solaris 11 x86 (nv-b91)
>> OpenSIPS 1.6.4 with TLS
>>
>> ...and am logging dialogs with the siptrace module.
>>
>> The problem is th
Got it.
Am I to believe, then, that only the initial "initialized" UAC INVITE hits
the local route? Everything after that for a dialog is visible in the b2b
ones only, and therefore untouchable?
- Jeff
On 2/8/11 4:58 PM, "Ovidiu Sas" wrote:
>In b2b routes you see the received message and th
In b2b routes you see the received message and therefor you cannot
apply any changes to the message that is sent (you don't have a handle
to it).
In local route, you see the INVITE that is about to be sent out and
that one is modifiable.
Regards,
Ovidiu Sas
On Tue, Feb 8, 2011 at 4:48 PM, Jeff P
On 2/8/11 4:39 PM, "Ovidiu Sas" wrote:
>On Tue, Feb 8, 2011 at 3:59 PM, Jeff Pyle wrote:
>> Ovidiu,
>>
>> Apparently once a dialog is in b2b-land, its messages are unavailable to
>> scripting functions? It seems Anca has said this a time or two. Or
>> three. Still seems strange.
>
>Not stra
On Tue, Feb 8, 2011 at 3:59 PM, Jeff Pyle wrote:
> Ovidiu,
>
> Apparently once a dialog is in b2b-land, its messages are unavailable to
> scripting functions? It seems Anca has said this a time or two. Or
> three. Still seems strange.
Not strange at all. B2B is a different type of beast then
You din't posted a proper SIP capture (no UDP src/dst IP for your
packets), but it seems that you are having a firewall issue. Just add
an xlog into your opensips server and see that you will have no
entries in syslog.
The INVITE that is sent out is having the same "Max-Forwards" counter
and you h
Ovidiu,
Apparently once a dialog is in b2b-land, its messages are unavailable to
scripting functions? It seems Anca has said this a time or two. Or
three. Still seems strange.
I'm close to what you have suggested. I'm using mediaproxy on my "main"
proxy in lieu of rtpproxy, with b2bua on a de
Ovidiu,
On Tue, Feb 8, 2011 at 1:16 PM, Ovidiu Sas wrote:
> Based on your description, it seems that you are dealing with a weird
> firewall/NAT that is SIP aware.
> Also, I don't know if this is a typo, but you are forwarding with
> opensips to 67.212.153.179 and your INVITE is actually sent to
Dave,
On Tue, Feb 8, 2011 at 1:09 PM, Dave Singer wrote:
> So weird.
> Did you specify the -f on the opensips cmd line?
> That is the only thing left that I can think of as the problem, it is
> using a default config that is somewhere else.
Yes - used:
opensips -f /etc/opensips/opensips.cfg
>
What's the point of hiding the o= line?
The c= line will still reveal the connection IP for RTP.
If you want true topology hiding, then use two servers and chain them:
- opensips with rtpproxy;
- opensips as a b2bua with "top hidding".
On the rtpproxy server you will be able to mask everything
Based on your description, it seems that you are dealing with a weird
firewall/NAT that is SIP aware.
Also, I don't know if this is a typo, but you are forwarding with
opensips to 67.212.153.179 and your INVITE is actually sent to
67.212.153.178.
Try to turn off the firewall and NAT ans see it thi
So weird.
Did you specify the -f on the opensips cmd line?
That is the only thing left that I can think of as the problem, it is
using a default config that is somewhere else.
try
updatedb
locate opensips.cfg
Most likely the default location is /usr/etc/opensips/opensips.cfg or
/etc/opensips/
Jeff,
I ran into this too. I was not using opensips to do the SIP top hiding
but was for the SDP using media_proxy. Media proxy doesn't touch "o"
unfortunately.
So I used fix_nated_sdp :
fix_nated_sdp("8","$Ri"); #the recieved on IP (my IP)
That fixed the "o" header but it created a "oldip" or "
Dave,
On Tue, Feb 8, 2011 at 12:02 AM, Dave Singer wrote:
> Don't know what tools you are familiar with so here are some
> suggestions for what they're worth.
Appreciate the input!
Am familiar with all - but included output below - always happy to
have another set of eyes on things ;-)
> what
s could be happening? Has anyone seen this before?
Regards,
Paris
__ Information from ESET NOD32 Antivirus, version of virus signature
database 5855 (20110208) __
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Hello,
Since the top-hiding scenario doesn't touch the SDP, it seems some
extracurricular textops may be required to fully hide the topology of the
network. I've been trying various subst_body() functions on my b2b Opensips
instance, each failing in a new and wonderful way.
route[b2b_request]
Hi, Jeff!
I moved the server_address parameter to b2b_logic module and it is not
compulsory anymore. If not set, the socket IP and port where the request
was received will be used. Of course, for external scenarios you have to
set it to something.
Anca
On 02/08/2011 07:07 PM, Jeff Pyle wro
Kyle,
use t_replicate("sip:");
Look at the tm module docs for a more complete picture.
Then modify the message. One branch will go out with the message the
way it was before the t_replicate and one will have the changes after
the t_replicate.
If you need more replicated destinations, use append_br
Hi Users!
I have a *simple* scenario that I just can't seem to
accomplish...famous last words right? Ok here goes...
I receive a NOTIFY message that I want to forward to two destinations,
one destination I want to forward the message and modify the body, the
other destination I just want to for
Anca,
Section 6 of the B2buaTutorial says -
compulsory: the server_address parameter in b2b_entities
Yet reality does not agree -
Parameter not found in module - can't set
Is the server_address no longer required, or it accomplished through another
method? I didn't see anything relevant
Good afternoon,
I have a perfectly running OpenSIPs server, but I can see that from time to
time and with step increment,
the openserMsgQueueDepth is increasing. During the year 2010, the number of
peers simply have increased by 30%, but the number of SIP transaction hasn't
increased at all, th
Anton,
My bet is that since the first one was dropped, a transaction was
never created and thus the transaction cleanup doesn't happen either.
If you want it to it do the automatic cleanup it might work to create
a transaction prior to the reply, then use t_reply and finally drop.
Dave
On Tue, F
Hello!
There is Opensips 1.6.4-2 and I use CDR flag for accounting purposes.
Today I found one record in acc table which have duration 10829 s.
I found sip_debug of this call (I am using ngrep utility for caching sip). The
debug I attached to the message.
In this debug:
1.1.1.1
I'm sorry in advance that I am not posting tcpdump packets. It's 11:20 and
I'm tired.
I have a strange issue.
Scenario:
A has DID A
B has DID B
Both A and B reside on the same UAS. HOWEVER, when A calls B using DID B -
the call should be routed to the carrier (and it comes right back in - but
Hi
We have a patched freeradius-xs 2.1.10 almost ready to go, but we are
still testing this. I looked to find the failed patch, but I can not
find it in the main repo of freeradius.
Can you tell us a bit more Ram?
Best regards,
Tijmen de Mes
AG Projects
Op 2/8/11 2:29 PM, Jeff Pyle schreef
ram,
Are you saying that the stock version of Freeradius has the FAILED patch
already installed? If so, can you say at which version this started?
I installed the freeradius-xs deb packages from AG Networks' repository. It
worked, but it required a lot of tricky updates from the Debian testin
Chris,
Weird indeed. Dave Singers suggestions are excellent, maybe also check
that there are no old OpenSIPS processes hanging around (with ps axu).
I occasionally see a process that won't die and then the restart will
fail.
Cheers,
Henk Hesselink
On 08-02-11 03:14, Chris Stone wrote:
Sorry
Japan mate. It's Japan. I'm lucky it isn't NTT... Now that would be like
being in prison.
On Tue, Feb 8, 2011 at 4:17 PM, Dave Singer wrote:
> I'm just trying to be helpful where I can, appreciative of the help
> I've received and the great free software. My biggest worry is
> misleading someo
Log inspections shows that while I processing first INVITE an original UAc
sends INVITE again, but OpenSIPS doesn't recognize it as already received
and start processing it again (makes a new transaction).
Why that can happens?
>
> Hi.
>
> I have 2 nested routes:
>
> route -> route[invite] ->
patch already added in to freeradius latest version
On Tue, Dec 21, 2010 at 2:47 PM, rad bogdan wrote:
> Hi everyone,
>
> I've started configuring CDRTool 8.0.10, FreeRadius 2.1.10, CallControl
> 2.0.8 and OpenSIPS 1.6 but I've encountered some problems: all the servers
> have installed succe
Hi.
I have 2 nested routes:
route -> route[invite] -> route[check]
In the route[check] I need to stop the execution of the script. I wrote:
route[check]
{
sl_send_reply("401", "Forbidden");
drop;
}
But this isn't working.
OpenSIPS replies "401: Forbidden" but continues the execu
Hello there,
We've been using dialog module in order to implement a concurrent calls limit
in the way described in http://www.opensips.org/Resources/DocsTutConcurrentCalls
However we have seen that some dialogs remain open in state 3 or state 4 and
therefore some customers with concurrent limit
Thanks a lot for prompt answer.
Changed and its working :)
Thanks,
Maciej
2011/2/8 Duane Larson :
> http://www.opensips.org/Resources/DocsCoreFcn16#toc66
>
> On Mon, Feb 7, 2011 at 6:49 PM, David J. wrote:
>>
>> You dont have to recompile;
>>
>> Look in the docs; there is a Server header you can
40 matches
Mail list logo
