On Sun, 6 Apr 2003, Mark Spencer wrote:
> In general, I find that SIP is extremely fragile, and every time I try to
> fix one bug, I end up creating another somewhere. What I need are
> strategies for verifying that the SIP implementation is correct, either
> via some sort of SIP test suite or even just a collection of users who
> will sign off on things.
>
> Anyway I'm soliciting for ideas from the list. I'd be happy to get
some
> feedback.
Well - I did some testing with the the current CVS.
I tested with:
1) As local client: a Cisco ATA186, both ports configured as local
"friends" of * (extn 6001 and 6002)
2) As "remote" SIP call targets or sources:
a) On Free World Dialup:
- An SJPhone client, using FWD's proxy service for getting through NAT,
FWD number 21622
- The Libertel eDial conference server on FWD 14551
b) On Packet8:
- Packet8's DTA310 SIP adapter (like ATA186), using Packet8's broadband
phone service (www.packet8.net) [I've enabled g711 on my DTA310]
My Asterisk registers with FWD with my FWD number 21542.
On my setup reinvites are turned off - my ATA186 at home is on an unrouted
address so "native bridging" between them and outside SIP services
won't
work.
I made the following tests. In every case I check that the call cleared
correctly from either end.
Test 1: "intercom calls" from port 1 of ATA to port 2, via Asterisk
A simple setup - no proxies involved.
>> Test PASSED
Test 2: outgoing call from * to FWD, calling the SJPhone mentioned above
For calls via FWD to work, Record-Route handling needs to be done
right. My SJPhone client is configured to work through FWD's
Peerpoint NAT proxy by Jasomi Networks - so SIP traffic passes
through 2 proxies, RTP streams also pass through the Jasomi Peerpoint.
>> Test PASSED
Test 3: outgoing call from * to FWD, calling the Libertel eDial conference
system on FWD 14551
The Libertel conference system is reached through FWD, so again
Record-Route handling must work. Doesn't use the Peerpoint, though.
In this case I couldn't test clearing the call from the eDial end - I
don't have control of that end, and their IVR wouldn't hang up on me.
>> Test PASSED
Test 4: outgoing call from * to my Packet8 account,
SIP/1847xxxyyyy@packet8.net
Packet8 will see this as a call from "outside" their network.
In this test call * did quite a few retransmits before the Packet8
service started to respond. So it exercised the retransmit code.
>> Test PASSED
Test 5: incoming call from SJPhone client on FWD to my
21542@fwd.pulver.net
Inbound from SJPhone via the Jasomi Peerpoint and the FWD proxy.
BUG: BYE originated from * end was not seen at SJPhone - lost
in transit. SJPhone (obviously) didn't OK it. But * did not
retransmit. Call did not clear at the SJPhone end. The
bug is the lack of retransmits - on subsequent
tests where the BYE wasn't lost the call cleared fine.
BUG? Asterisk does not return the Record-Route header in the
"180 Ringing" response. FIXME: Check against RFC!!. Didn't
affect the call as far as I can tell.
>> Test FAILED
>> (though call "worked")
Test 6: incoming call from the PSTN to 21542@fwd.pulver.com, via eDial
test inbound gateway
From *'s point of view, like Test 5 except that the Peerpoint proxy
isn't used.
Same bug with Record-Route not copied back in 180 response seenm
but apart from that:
>> Test PASSED
So that set of tests were mostly rather successful. Two bugs found:
BUG#1: BYE not retransmitted - for Mark to fix I'd say.
BUG#2? Record-Route not copied back to 180 response - for me to
investigate, maybe fix
Regards,
Steve