Sipwitch - Anyone got this working - build failed
by agraham
Hi all,
I thought I'd give Sip Witch a go but I'm have problems making any
calls, my set up is as follows:
Single segment LAN, with no firewalls, the main host runs sipw in the
foreground so I can see the messages as follows:-
# sipw -trace -x9 -foreground
/etc/sipwitch.conf says:
<?xml version="1.0"?>
<sipwitch>
<access>
<local>192.168.10.0/24</local>
</access>
<stack>
<domain>hdtv</domain>
<localnames>hdtv</localnames>
<restricted>local</restricted>
<trusted>local</trusted>
<mapped>200</mapped>
<threading>2</threading>
<interface>*</interface>
<dumping>false</dumping>
<peering>(my public IP Address here)</peering>
<system>system</system>
<anon>anonymous</anon>
</stack>
<timers>
<ring>4</ring>
<cfna>4</cfna>
<reset>6</reset>
</timers>
<registry>
<prefix>200</prefix>
<range>100</range>
<keysize>77</keysize>
<mapped>200</mapped>
</registry>
<routing>
</routing>
</sipwitch>
my modified /etc/sipwitch.d/lab.xml contains:
<provision>
<user id="user1">
<secret>user1</secret>
<extension>201</extension>
<display>201</display>
</user>
<user id="user2">
<secret>user2</secret>
<extension>202</extension>
<display>202</display>
</user>
<user id="testing">
<digest>92528744b1fbef79095af90584dedaca</digest>
<extension>210</extension><display>Testing</display>
</user>
<test id="test1">
<extension>299</extension><answer>12</answer><duration>120</duration><display>Testing</display>
</test>
<test id="ringerr">
<extension>298</extension><error>180</error>
</test>
<test id="busyerr">
<extension>297</extension><error>486</error>
</test>
<test id="looperr">
<extension>296</extension><error>482</error>
</test>
<test id="reorder">
<extension>295</extension><error>484</error>
</test>
</provision>
No other config files exist.
The sipw start up log shows the following:
sipw: loading config from /etc/sipwitch.conf
sipw: new realm 9f67c701-77dc-07c6-0000-cdc9875be742
sipw: media proxy configured for 38 ports
sipw: scanning config from /etc/sipwitch.d
sipw: loaded lab.xml
sipw: adding user user1
sipw: adding user user2
sipw: adding user testing
sipw: adding test test1
sipw: adding test ringerr
sipw: adding test busyerr
sipw: adding test looperr
sipw: adding test reorder
sipw: adding admin root
sipw: startup
sipw: registry starting; mapping 200 entries
sipw: starting cdr thread
sipw: stack starting; 200 maps and 10 threads at priority 1
sipw: starting thread 1
sipw: starting thread 2
sipw: starting thread 3
sipw: starting thread 4
sipw: starting thread 5
sipw: starting thread 6
sipw: starting thread 7
sipw: starting thread 8
sipw: starting thread 9
sipw: starting thread 10
sipw: media proxy starting for 38 ports
sipw: starting background thread
sipw: starting media thread
sipw: starting signals
sipw: logfile: server starting 2010-06-09 13:14:07
On the first client (different machine) I run twinkle and it registers
ok as shown below:
sipw: sip: event 27; cid=0, did=0, instance=8
sipw: challenge required for 192.168.10.1:5060
sipw: sip: event 27; cid=0, did=0, instance=7
sipw: activating user1; extension=201
sipw: logfile: activating user1 2010-06-09 13:16:20
sipw: registering user1(201) for 3600 seconds from 192.168.10.1:5060
on the second machine (yet another machine) I also run twinkle and it
registers fine as shown below:
sipw: sip: event 27; cid=0, did=0, instance=10
sipw: challenge required for 192.168.10.101:5060
sipw: sip: event 27; cid=0, did=0, instance=6
sipw: activating user2; extension=202
sipw: logfile: activating user2 2010-06-09 13:17:23
sipw: registering user2(202) for 3600 seconds from 192.168.10.101:5060
So far so good :)
Now, user 1 (201) will dial 202:
sipw: sip: event 5; cid=1, did=2, instance=8
sipw: authorizing local; target=202
sipw: rewrite process; target=202, dialing=202
sipw: rewrite process; registry=0x7f987b808158, dialed=0x269e020
sipw: local call 4c0f869e:1 for 202 from 201
sipw: cannot invite sip:192.168.10.101:5060; build failed
sipw: disconnecting call 4c0f869e:1
sipw: sip: sending source reply 486
sipw: sip: event 25; cid=1, did=-1, instance=7
sipw: sip: event 26; cid=1, did=-1, instance=2
sipw: clearing call 4c0f869e:1
sipw: call 4c0f869e:1 local busy 2010-06-09 13:18:38 0 201 202 n/a 201
As you can see, I get "build failed"
What I'm I doing wrong ?
TIA
Albert.
p.s. The sipwitch version in F13 seems to be way behind current
developments (0.8.3), so if this is a bug, it may have already been
fixed upstream - however the upstream version will not compile on F13 :(
13 years, 9 months
[Fedora QA] #63: RFE - i18n install verification
by fedora-badges
#63: RFE - i18n install verification
-------------------------+--------------------------------------------------
Reporter: jlaska | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 14
Component: Test Review | Version:
Keywords: |
-------------------------+--------------------------------------------------
This ticket is intended to track the post-Fedora 13 addition of several
i18n test cases to the
[https://fedoraproject.org/wiki/QA:Fedora_13_Install_Test_Plan
installation test plan]. Adam, Hurry and myself discussed several
different i18n use cases to target, including:
{{{
> On Tue, 2010-04-13 at 22:47 -0700, Adam Williamson wrote:
> Non-English European language - French or German, maybe
> Asian language - C, J or K :)
> Cyrillic language - Russian is fine
> Arabic
> Something else as a wildcard, maybe something African
}}}
For Fedora 13, a small change as been made to
[http://fedoraproject.org/wiki/QA:Testcase_Anaconda_autopart_%28encrypted%...
QA:Testcase Anaconda autopart (encrypted) install] to install with a non-
English keymap using characters that don't exist on an english keymap.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/63>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
13 years, 9 months
[Fedora QA] #97: Request for a mentor
by fedora-badges
#97: Request for a mentor
-----------------------------------------+----------------------------------
Reporter: masami | Owner:
Type: proventester request | Status: new
Priority: major | Milestone:
Component: Proventester Mentor Request | Version:
Keywords: |
-----------------------------------------+----------------------------------
I would like to request a mentor to be a proventester. I'd be happy to
working with proventesters.[[BR]]
I've been doing updates testing, testing rawhide and submitting the
results, such as write a bug report, reporting updates testing result via
fedora-easy-karma.
[[BR]]
Thanks,
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/97>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
13 years, 9 months
[Fedora QA] #88: Add test coverage for 'basic video driver install'
by fedora-badges
#88: Add test coverage for 'basic video driver install'
---------------------------+------------------------------------------------
Reporter: jlaska | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 14
Component: Wiki | Version:
Keywords: retrospective |
---------------------------+------------------------------------------------
= problem =
There is no explicit verification that the ''basic video driver install''
boot option exists, or even works.
= analysis =
With ''nomodeset'' no longer an option for some video drivers, having
xdriver=vesa working is an important workaround for display problems. A
installer boot option is provided for this, but not confirmed. The
installer boot option is not present on live media.
= enhancement recommendation =
1. File a bug against the ''correct'' component (not sure if it's spin-
kickstarts, livecd-tools or other) to ensure that the Fedora LIVE images
have a ''base video driver'' boot option
2. Recommend updating
[https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_Graphical
QA:Testcase_Anaconda_User_Interface_Graphical], or creating a new test
case, that confirms expected behavior when booting ''Install system with
basic video driver''. This test will need to be run against traditional
media (CD, DVD and boot.iso) and Live media.
* it should boot with ''xdriver=vesa''
* when X starts, it should be using the vesa driver (confirm by
inspecting ''/tmp/X.log'')
* does the installed system also boot with ''xdriver=vesa''?
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/88>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
13 years, 9 months
[Fedora QA] #99: Proven Tester Mentor Request
by fedora-badges
#99: Proven Tester Mentor Request
-----------------------------------------+----------------------------------
Reporter: boblfoot | Owner:
Type: proventester request | Status: new
Priority: major | Milestone:
Component: Proventester Mentor Request | Version:
Keywords: |
-----------------------------------------+----------------------------------
Based on my participation in F12 and F13 pre-release test days and my work
with the Fedora-Unity folks in testing their respins - I am requesting a
mentor to achieve the status or Proven Tester going forward thru the F14
cycle.
Bob Lightfoot
FAS Username - boblfoot
IRC Nick - boblfoot
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/99>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
13 years, 9 months