[Asterisk-Users] SIP Testing

[Stephen Davies]

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 at 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 at 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 at 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