SIP call test case results

[junction]

spreadsheet of issues:
http://spreadsheets.google.com/ccc?key=r7qtlQzIodAMfVLvyeDSMYg

some testing shows calls to SIP uris and SIP addresses fail. A trace with dbmon shows that the request goes out to the active-calls component with the username portion of of the to SIP uri missing

[rlangham]

I did some testing and it appears to mostly work for me. May need the trace or more details on how you are dialing and exactly what you are dialing.

I am assuming Windows Dialer. Windows Dialer always prepends "T" to the number being dialed. So, you have to dial using the "sip:" prefix. The number comes to the TAPI driver as "Tsip:......". This can be detected and remove the "T". If you dial without "sip:", then the TSP gets ... "Tname@domain.com". In this case, the TAPI driver will now (as of fix on 6/16/09) prepend sip to the number, so it will dial "sip:Tname@domain.com". It is not possible to know that the "T" was added by dialer.

If you use straight TAPI (e.g. TAPI browser), then either case should work. If number contains "@" then it is assumed to be SIP number. If no "sip:" prefix, then it will be added.

[rlangham]

I inspected the logs that you sent and see the problem. The main problem is that only "T" is being sent to TAPI to dial. It appears that an empty number is being dialed from Windows Dialer. It then prepends a "T" to everything, so I get "T" to dial. Since "T" does not contain a "@", I assume it is a phone number. I strip all non-numbers from it and what I get is an empty string. This is why you are seeing a SIP address without a username. Appears to be an issue with Windows Dialer not sending the value to dial.

[junction]

that was all done through outlook not windows dialer