This document lists the test results in various SIP devices examined by CommuniGate Systems

ManufacturerProductVersion User-Agent ProblemStatus Comment
Saxa IP NetPhone S / SX     no problem found  

Hitachi Cable IP5000 Wireless     no problem found  

Cisco Systems, Inc. IP Phone 7940 CSCO/* no problem found
Linksys IP Phone 4.x Sipura/SPA941-4.* no problem found
ATA 186 3.x.x Cisco ATA 186 v3.* CANCEL requests can be sent with a completely bogus URI, making it impossible to cancel a call. bug no workarounds

Microsoft Corp. Windows Messenger 5.x RTC/* Most operations require non-standard packet signing not a bug SIPHack(isMicrosoft)

SJLabs, Inc. SJPhone SJphone/* no problem found

Polycom, Inc. Polycom IP Phone 3xx,5xx,6xx PolycomSoundPointIP/* "LCS-mode" requires epid dialog fields not a bug SIPHack(needsEpid)
BYE, REFER, NOTIFY requests use incorrect Authentication data bug SIPHack(BadByeAuth)

CounterPath Solutions, Inc. X-ten xten/* no problem found
EyeBeam eyeBeam* Presence Agent functionality crashes the client bug do not enable Presence

Grandstream Networks, Inc. BudgeTone-10x Grandstream BT* Contact transport and maddr fields are lost bug SIPHack(NoTCP,NoMaddr)
BudgeTone 48x Grandstream HT* Contact transport and maddr fields are lost bug SIPHack(NoTCP,NoMaddr)

Tangerine, Inc. (deceased) Tangerine Gateway 1.xx Tangerine-oSIP-UA/* When receiving multiple 1xx INVITE responses followed by a 2xx response, the gateway retreieves its dialog data from the first 1xx response bug direct all incoming calls from this gateway to a PBX application (to avoid forking)

ZyXEL Corp. P2000W Wi-Fi Loose Route parameter is specified as ;lr=, and not as ;lr (RFC3261: lr-param syntax violation) bug CommuniGate Pro compensates for this bug
maddr and transport parameters of the Contact URI are not remembered bug CommuniGate Pro compensates for this bug
Real name used in From/To fields are not enclosed into quote marks if they contain special (non-token) symbols (RFC3261: display-name syntax violation) bug some clients may reject packets as incorrectly formatted
The "magic cookie" string is incorrect: z9hG4bk instead of z9hG4bK (RFC3261: 8.1.1.7 violation) bug should not cause negative effects
BYE, CANCEL, etc. responses are sent with Record-Route fields not present in requests (copied from the dialog Route set) bug should not cause negative effects