It seems you have no tags attached to pages. To attach a tag simply click on the tags button at the bottom of any page.
visuallinux
RSS: New posts
visuallinux 1245363078|%e %b %Y, %H:%M %Z|agohover
Dear all,
From fews days my FS and Wikipbx not works:
I has config FS & Wikipbx for received traffic from a external gateway and forward the calls to other SIP Provider, but for some reason now alls calls are rejected; and i do not understand why?
I get the following logs on FS_CLI:
http://pastebin.freeswitch.org/9435
Any idea?.
Fernando
tleyden 1245366860|%e %b %Y, %H:%M %Z|agohover
Thanks for using pastebin!
Can you do an ngrep and filter on the host/ip of the upstream gateway? Eg:
ngrep -W byline src or dst YOUR_UPSTREAM_GATEWAY.com
Maybe the rejection sip message has more details that is not being shown on the fs console.
tleyden 1245367046|%e %b %Y, %H:%M %Z|agohover
Also on the freeswitch wiki it suggests to enable "late negotation" if using proxy media mode.
visuallinux 1245368511|%e %b %Y, %H:%M %Z|agohover
Hello thanks for your help.
This is my SIP TRACE
http://pastebin.freeswitch.org/9438
In /sip_profiles/internal.xml i have:
<param name="inbound-late-negotiation" value="true"/>
I try to send traffic from a gateway Asterisk to my FS Wikipbx systems and i get the following log in Asterisk CLI:
— Executing Dial("SIP/452904-081848d8", "SIP/56968482060@fs|45") in new stack
— Called 56968482060@fs
Jun 18 19:29:27 WARNING[25651]: chan_sip.c:9761 handle_response_invite: Forbidden - wrong password on authentication for INVITE to '"452904" <sip:521.71.802.091|40925424#521.71.802.091|40925424>;tag=as49c31700'
— SIP/fs-08189e18 is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
Fernando
tleyden 1245370591|%e %b %Y, %H:%M %Z|agohover
Welcome to the difficult world of debugging voip problems :D
I wish I could help, but I don't even have a clear picture of what's going on. You get an incoming call to freeswitch, and you bridge out of an asterisk gateway? Then why does the call go from asterisk to freeswitch? (you say "I try to send traffic from a gateway Asterisk to my FS Wikipbx systems"). Seems like the call is going in circles..
If it worked at one point and stopped working after you modified the freeswitch config xml templates, you could try this ..
Or if it never worked, then that won't help .. and you will probably have to debug asterisk to find out why its rejecting the call. Maybe the peer is setup incorrectly in the sip.conf .. could be any number of reasons.
visuallinux 1245432231|%e %b %Y, %H:%M %Z|agohover
Hello all.
Thank you tleyden for your support and help.
I recovered from SVN templates of wikipbx/freeswitchxml as you told me and now the system works again. Sure i has a problem in sofia.conf.xml
I am simulating a producction environment and testing wikipbx too; like this
Asterisk-1 -> FS(wkipbx)-->Asterisk-2(Gateways GSM)
Asterisk-1 : Simulate my customers (Gateways)
Asterisk-2 : I have conected Channels banks and gateways GSM for terminating mobile.
I am very interested in receive all traffic on my FS(Wikipbx) and i like very much Wikipbx i think is excellent.
Regarding wikipbx; do you know how many stable is wikipbx for a producction environment?
I come back from Asterisk and i want change for FS with Wkipbx.
Thank you again, and excuse my english.
Fernando
stas_shtin 1245433967|%e %b %Y, %H:%M %Z|agohover
It's quite stable and can be running 24/7 for months.
As for performance, it really is a question about freeswitch, not wikipbx. Because wikipbx shouldn't decrease call throughput considerably. Anyway, it depends on may factors:
1. codecs used, is transcoding enabled?
2. hardware used
3. is it running XML dialplans or mod_python scripts - the later are quite a bit more resource hungry
etc.
In my experience, a performance of over 250 concurrent calls on a quad-core server should be achievable with no degradation of call quality, but your mileage may vary. Feel free to share your benchmarks' results in the General forum section here, it looks like a FAQ to me so it should probably be documented.
