cannot login due to sipAccountConnectionFailedEventHandlerThreadSafe

[sorin]

(error) 12:44:19 [Common] SipAccount::discoverForSIP: cannot connect via UDP
(error) 12:44:19 [Common] SipAccount::discoverNetwork: error while discovering network for SIP
(error) 12:44:24 [Common] SipAccount::discoverForSIP: cannot connect via UDP
(error) 12:44:24 [Common] SipAccount::discoverNetwork: error while discovering network for SIP
(error) 12:44:29 [Common] SipAccount::discoverForSIP: cannot connect via UDP
(error) 12:44:29 [Common] SipAccount::discoverNetwork: error while discovering network for SIP
(error) 12:44:34 [Common] UserProfileHandler::sipAccountConnectionFailedEventHandlerThreadSafe: error: 5

This is happening on a intranet, all the connection parameters are properly set, tested with xlite client, still quotcom is failing to connect.

[laurent]

QuteCom sends a sip-ping with a fake register,
your server should answer to this packet.
If not QuteCom considers your sip-server offline ...

[sorin]

Is this part of the SIP specification?

Can I enable more verbose logging for debugging this or should I use the wireshark?

[laurent]

you could check with Wireshark

[sorin]

I used wireshark and now I do have two filtered logs: one with qutecom where it fails to register and another one with xlite where it does succeed.

I think that that cause could be related to the realm, how can I set the realm in quotecom?

[laurent]

Sorin, It is QuteCom not quotecom.

You can set the realm in the login window .

[nikita]

In the log, I'm reading for the same sip uri :

• Digest Username="83571" for qutecom
• Digest Username="ssbarnea" for xlite

Have you checked it ?

[laurent]

Sorin i cannot read your captures.
Can you re-post with zip or other compressed file format ?

[sorin]

It could be something related to configuration parameters but I don't exactly understand how to map them to the ones provided by qutecom config. I already found another SIP client that is working: Zoiper.

So far these are the working settings (still not working in qutecom):

authentication: <your-ldap-username>
passwd: <your-voip-password>
domain/server = 10.128.128.40
username/extension/caller id= <your-extension-no>
use rport: checked
use rport media: checked

I assumed that for qutecom:
login/username: the username from generic config
displayname: authentication field from generic config
accountname: not-important

Also I tried to swap login with displayname but the result was the same.

[sorin]

as zip in case the pcam file were destroyed by the server

[laurent]

look at packets :
-no=7 in sip_qutecom_fail_with_401_new.pcap => username=83571
-no=4 in sip_xlite_sucess_new.pcap => username=ssbarnea

as Nikita pointed, the username is misconfigured in QuteCom.
=> the server responds with 404 user not found.

[laurent]

you must fill "ssbarnea" in login field

[sorin]

As I said before I tried both approaches. I think it is important to note that server is returning initially returning 401 and after that it will return 404.

I attached a PNG file with the comparison of the first packet between xlite and quecom. This should show the differences.

[laurent]

Replying to sorin:

I think it is important to note that server is returning initially returning 401 and after that it will return 404.

401 is correct. The server asks clients to send password.

I attached a PNG file with the comparison of the first packet between xlite and quecom. This should show the differences.

This comparaison is not interesting ( xlite register has no digest and qutecom register is a fake register to ping sip-server). you should diff register packets after 401 ( with digest auth )

[chris-mac]

my two cents: would it be difficult to change fake REGISTER QuteCom currently uses to ping SIP server, to OPTIONS?

IMHO OPTIONS is much better suited to ping a remote SIP server (or I would even say, OPTIONS is exactly the request to use in this case).