Hello all, first of all, thank you for such a wonderful plugin for Pidgin. Us Linux users have it hard in a Windows dominated corporate world. :)
After inserting all of the configuration, I get the following error message:
"Not Found: Destination URI either not enabled for SIP or does not exist. Please, contact with your Administrator"
I thought that this was a problem with the server side, but a Windows client works. Maybe my configuration is wrong. I have the following:
Protocol: Microsoft LCS/OCS
Username: <username>@<windows domain>
Login: <username>
Password: <password>
Use proxy: Checked
Proxy server: <OCS server address>
Use non-standard port: Checked
Port: 5061
Connection Type: SSL/TLS
User Agent: <default pidgin>
Can you help?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well, 404 response at least signifies that your credentials (Login + password) were correct. SIPE has validated server signature as well.
Formally it complains on your URI:
sip:kthermos@velti.net
Can you take logs from your official client and post them? Turn on logging Tools->Options->General->Logging->Turn on Logging in Communicator
and get logs in
C:\Documents and Settings\<YOU>\Tracing
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Further from SIP spec (RFC3261, 21.4.5):
"404 Not Found
The server has definitive information that the user does not exist at
the domain specified in the Request-URI. This status is also
returned if the domain in the Request-URI does not match any of the
domains handled by the recipient of the request."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
maybe your SIP URI is different on the server from what you have provided. That's way I'd like to compare with logs from official client - Office Communicator.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, the log is quite large to be put on here (wall of text), the only difference I noticed is that the domain uses .com in the OCS client where I used .net. It didn't make a difference though because I got a wrong password error.
Reading from both logs, everything is going at about the same pace, except the 404 error for SIPE.
I'll try uploading the log to Google Docs, otherwise I'll talk to my IT dept and see if they can help (although I doubt it, they're quite strict about not supporting what they didn't install)
Thanks for help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well, your server said true last time (404) - it has no idea about velti.net SIP domain. It does not serve it.
Your username should be in form (This is 100%). Same as in Communicator:
user@velti.com
The same as in Office Communicator.
Now to authentication fields - Login+Password.
Since I see Communicator uses Kerberos, you are inside your domain. Also probably you have never explicitly entered your credentials to Communicator. It this case your login to domain credentials are used behind the scene. So I'm saying, as credentials in this case you should use your domain, login and password you use to login to your PC.
Try different forms for login:
DOMAIN\user
user@domain.com
user@domain.net
And most IMPORTANTLY, your server is (note .COM there; this is where Communicator connects):
ocs.company.com
TLS, port 5061
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This problems sounds like a problem with permissions in the AD (SIP part) of the Domain Controller.
I remember one partner here could connect to the server because he always got a 404 error.
I went to the AD administrator to see what could be the problem, and we found the can permission to use SIP services ... he gave him that permissions and now he can use SIPE.
I don't know if the problem is the same ... but I think the problem is in the server side.
Regards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello all, first of all, thank you for such a wonderful plugin for Pidgin. Us Linux users have it hard in a Windows dominated corporate world. :)
After inserting all of the configuration, I get the following error message:
"Not Found: Destination URI either not enabled for SIP or does not exist. Please, contact with your Administrator"
I thought that this was a problem with the server side, but a Windows client works. Maybe my configuration is wrong. I have the following:
Protocol: Microsoft LCS/OCS
Username: <username>@<windows domain>
Login: <username>
Password: <password>
Use proxy: Checked
Proxy server: <OCS server address>
Use non-standard port: Checked
Port: 5061
Connection Type: SSL/TLS
User Agent: <default pidgin>
Can you help?
I also wanted to add the following log which contains a 404 error:
(18:30:37) sipe: sipe_login - using specified SIP proxy
(18:30:37) sipe: create_connection - using specified SIP port
(18:30:37) sipe: create_connection - hostname: ocs1.velti.net port: 5061
(18:30:37) sipe: using SSL
(18:30:37) sipe: not adding auth header to msg w/ method REGISTER
(18:30:37) sipe:
sending - Wed Jul 29 18:30:37 2009
######
REGISTER sip:velti.net SIP/2.0
Via: SIP/2.0/tls 192.168.60.128:33529;branch=z9hG4bK60C0848CFDAA4D951D7C
From: <sip:kthermos@velti.net>;tag=198617548;epid=000C29A913F7
To: <sip:kthermos@velti.net>
Max-Forwards: 70
CSeq: 1 REGISTER
User-Agent: Purple/1.5.0
Call-ID: 5301g63F1aE145i60C0m848CtFDAAb4D95x1D7Cx
Contact: <sip:192.168.60.128:33529;transport=tls;ms-opaque=d3470f2e1d>;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:bbbe6457-9dc0-5e6c-8278-c173da28cf59>"
Supported: gruu-10, adhoclist, msrtc-event-categories, com.microsoft.msrtc.presence
Event: registration
Allow-Events: presence
ms-keep-alive: UAC;hop-hop=yes
Content-Length: 0
######
(18:30:37) sipe: sipe_input_cb_ssl: new input buffer length 4096
(18:30:37) sipe:
received - Wed Jul 29 18:30:37 2009
######
SIP/2.0 401 Unauthorized
Date: Wed, 29 Jul 2009 15:31:35 GMT
WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="ocs1.velti.net", version=4
WWW-Authenticate: Kerberos realm="SIP Communications Service", targetname="sip/ocs1.velti.net", version=4
From: <sip:kthermos@velti.net>;tag=198617548;epid=000C29A913F7
To: <sip:kthermos@velti.net>;tag=3C91FC5ACCD875E196E84C69A0824457
Call-ID: 5301g63F1aE145i60C0m848CtFDAAb4D95x1D7Cx
CSeq: 1 REGISTER
Via: SIP/2.0/tls 192.168.60.128:33529;branch=z9hG4bK60C0848CFDAA4D951D7C;received=10.1.2.101;ms-received-port=4393;ms-received-cid=630000
Content-Length: 0
#######
(18:30:37) sipe: msg->response(401),msg->method(REGISTER)
(18:30:37) sipe: RE-REGISTER CSeq: 1
(18:30:37) sipe: process_input_message - we have a transaction callback
(18:30:37) sipe: process_register_response: got response to REGISTER; expires = 0
(18:30:37) sipe: REGISTER retries 1
(18:30:37) sipe: process_register_response - Auth header: NTLM realm="SIP Communications Service", targetname="ocs1.velti.net", version=4
(18:30:37) sipe: fill_auth: type NTLM
(18:30:37) sipe:
sending - Wed Jul 29 18:30:37 2009
######
REGISTER sip:velti.net SIP/2.0
Via: SIP/2.0/tls 192.168.60.128:33529;branch=z9hG4bK60C0848CFDAA4D951D7C
From: <sip:kthermos@velti.net>;tag=198617548;epid=000C29A913F7
To: <sip:kthermos@velti.net>
Max-Forwards: 70
CSeq: 2 REGISTER
User-Agent: Purple/1.5.0
Call-ID: 5301g63F1aE145i60C0m848CtFDAAb4D95x1D7Cx
Contact: <sip:192.168.60.128:33529;transport=tls;ms-opaque=d3470f2e1d>;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:bbbe6457-9dc0-5e6c-8278-c173da28cf59>"
Supported: gruu-10, adhoclist, msrtc-event-categories, com.microsoft.msrtc.presence
Event: registration
Allow-Events: presence
ms-keep-alive: UAC;hop-hop=yes
Content-Length: 0
Authorization: NTLM qop="auth", realm="SIP Communications Service", targetname="ocs1.velti.net", gssapi-data=""
######
(18:30:37) sipe: process_input_message - removing CSeq 2
(18:30:37) sipe:
received - Wed Jul 29 18:30:37 2009
######
SIP/2.0 401 Unauthorized
Date: Wed, 29 Jul 2009 15:31:35 GMT
WWW-Authenticate: NTLM opaque="F4A176A6", gssapi-data="TlRMTVNTUAACAAAAAAAAADgAAADzgpjiV9qG9nty5dUAAAAAAAAAAHYAdgA4AAAABgBxFwAAAA8CAAoAVgBFAEwAVABJAAEACABPAEMAUwAxAAQAEgB2AGUAbAB0AGkALgBuAGUAdAADABwAbwBjAHMAMQAuAHYAZQBsAHQAaQAuAG4AZQB0AAUAEgB2AGUAbAB0AGkALgBuAGUAdAAHAAgAAMZqqGEQygEAAAAA", targetname="ocs1.velti.net", realm="SIP Communications Service", version=4
From: <sip:kthermos@velti.net>;tag=198617548;epid=000C29A913F7
To: <sip:kthermos@velti.net>;tag=3C91FC5ACCD875E196E84C69A0824457
Call-ID: 5301g63F1aE145i60C0m848CtFDAAb4D95x1D7Cx
CSeq: 2 REGISTER
Via: SIP/2.0/tls 192.168.60.128:33529;branch=z9hG4bK60C0848CFDAA4D951D7C;received=10.1.2.101;ms-received-port=4393;ms-received-cid=630000
Content-Length: 0
#######
(18:30:37) sipe: msg->response(401),msg->method(REGISTER)
(18:30:37) sipe: RE-REGISTER CSeq: 2
(18:30:37) sipe: process_input_message - we have a transaction callback
(18:30:37) sipe: process_register_response: got response to REGISTER; expires = 0
(18:30:37) sipe: REGISTER retries 2
(18:30:37) sipe: process_register_response - Auth header: NTLM opaque="F4A176A6", gssapi-data="TlRMTVNTUAACAAAAAAAAADgAAADzgpjiV9qG9nty5dUAAAAAAAAAAHYAdgA4AAAABgBxFwAAAA8CAAoAVgBFAEwAVABJAAEACABPAEMAUwAxAAQAEgB2AGUAbAB0AGkALgBuAGUAdAADABwAbwBjAHMAMQAuAHYAZQBsAHQAaQAuAG4AZQB0AAUAEgB2AGUAbAB0AGkALgBuAGUAdAAHAAgAAMZqqGEQygEAAAAA", targetname="ocs1.velti.net", realm="SIP Communications Service", version=4
(18:30:37) sipe: fill_auth: type NTLM
(18:30:37) sipe: sip_sec_init_sec_context__ntlm: in use
(18:30:37) sipe: sip_sec_init_sec_context__ntlm: in use
(18:30:37) sipe: received NTLM NegotiateFlags = E29882F3; OK? 1
(18:30:37) sipe: Generated NTLM AUTHENTICATE message (qozARfEB2z7OE8vfEsihMw==)
(18:30:37) sipe:
sending - Wed Jul 29 18:30:37 2009
######
REGISTER sip:velti.net SIP/2.0
Via: SIP/2.0/tls 192.168.60.128:33529;branch=z9hG4bK60C0848CFDAA4D951D7C
From: <sip:kthermos@velti.net>;tag=198617548;epid=000C29A913F7
To: <sip:kthermos@velti.net>
Max-Forwards: 70
CSeq: 3 REGISTER
User-Agent: Purple/1.5.0
Call-ID: 5301g63F1aE145i60C0m848CtFDAAb4D95x1D7Cx
Contact: <sip:192.168.60.128:33529;transport=tls;ms-opaque=d3470f2e1d>;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:bbbe6457-9dc0-5e6c-8278-c173da28cf59>"
Supported: gruu-10, adhoclist, msrtc-event-categories, com.microsoft.msrtc.presence
Event: registration
Allow-Events: presence
ms-keep-alive: UAC;hop-hop=yes
Content-Length: 0
Authorization: NTLM qop="auth", opaque="F4A176A6", realm="SIP Communications Service", targetname="ocs1.velti.net", gssapi-data="TlRMTVNTUAADAAAAGAAYAIQAAAAYABgAnAAAABIAEgBAAAAAEAAQAFIAAAAiACIAYgAAABAAEAC0AAAAUYIAQHYAZQBsAHQAaQAuAG4AZQB0AGsAdABoAGUAcgBtAG8AcwBtAG8AcgBnAG8AdABoAC4AdgBlAGwAdABpAC4AbgBlAHQAM8toEz50VZYDRZC1RkGnitw3yfxOa7wfG6pKBfsLMKw4XZXLrrIsLa9DV70lABrEY4KMPCDrviiWx2E9XnR1jg=="
######
(18:30:37) sipe: process_input_message - removing CSeq 3
(18:30:37) sipe:
received - Wed Jul 29 18:30:37 2009
######
SIP/2.0 404 Not Found
Authentication-Info: NTLM rspauth="01000000000000005A74A3D4CB1651B9", srand="362F2D41", snum="1", opaque="F4A176A6", qop="auth", targetname="ocs1.velti.net", realm="SIP Communications Service"
From: <sip:kthermos@velti.net>;tag=198617548;epid=000C29A913F7
To: <sip:kthermos@velti.net>;tag=3C91FC5ACCD875E196E84C69A0824457
Call-ID: 5301g63F1aE145i60C0m848CtFDAAb4D95x1D7Cx
CSeq: 3 REGISTER
Via: SIP/2.0/tls 192.168.60.128:33529;branch=z9hG4bK60C0848CFDAA4D951D7C;received=10.1.2.101;ms-received-port=4393;ms-received-cid=630000
ms-diagnostics: 4005;reason="Destination URI either not enabled for SIP or does not exist";source="ocs1.velti.net"
Content-Length: 0
#######
(18:30:37) sipe: incoming message's signature validated
(18:30:37) sipe: msg->response(404),msg->method(REGISTER)
(18:30:37) sipe: RE-REGISTER CSeq: 3
(18:30:37) sipe: process_input_message - we have a transaction callback
(18:30:37) sipe: process_register_response: got response to REGISTER; expires = 0
(18:30:37) sipe: process_input_message - removing CSeq 3
(18:30:37) sipe:
sending - Wed Jul 29 18:30:37 2009
######
REGISTER sip:velti.net SIP/2.0
Via: SIP/2.0/tls 192.168.60.128:33529;branch=z9hG4bK60C0848CFDAA4D951D7C
From: <sip:kthermos@velti.net>;tag=198617548;epid=000C29A913F7
To: <sip:kthermos@velti.net>
Max-Forwards: 70
CSeq: 4 REGISTER
User-Agent: Purple/1.5.0
Call-ID: 5301g63F1aE145i60C0m848CtFDAAb4D95x1D7Cx
Contact: <sip:192.168.60.128:33529;transport=tls;ms-opaque=d3470f2e1d>;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:bbbe6457-9dc0-5e6c-8278-c173da28cf59>"
Supported: gruu-10, adhoclist, msrtc-event-categories, com.microsoft.msrtc.presence
Event: registration
Allow-Events: presence
ms-keep-alive: UAC;hop-hop=yes
Expires: 0
Content-Length: 0
Authorization: NTLM qop="auth", opaque="F4A176A6", realm="SIP Communications Service", targetname="ocs1.velti.net", crand="eea95fe7", cnum="1", response="01000000000000007E9A6084CB1651B9"
######
well, 404 response at least signifies that your credentials (Login + password) were correct. SIPE has validated server signature as well.
Formally it complains on your URI:
sip:kthermos@velti.net
Can you take logs from your official client and post them? Turn on logging Tools->Options->General->Logging->Turn on Logging in Communicator
and get logs in
C:\Documents and Settings\<YOU>\Tracing
Further from SIP spec (RFC3261, 21.4.5):
"404 Not Found
The server has definitive information that the user does not exist at
the domain specified in the Request-URI. This status is also
returned if the domain in the Request-URI does not match any of the
domains handled by the recipient of the request."
Hmm does that mean that I don't exist? I'll gather some logs from there and let you know.
maybe your SIP URI is different on the server from what you have provided. That's way I'd like to compare with logs from official client - Office Communicator.
Username should be in form:
user@domain.com
Login should be in form:
DOMAIN\user
Thanks for the reply pier11.
I tried that as well but to no success. Same issue as before.
Well, the log is quite large to be put on here (wall of text), the only difference I noticed is that the domain uses .com in the OCS client where I used .net. It didn't make a difference though because I got a wrong password error.
Reading from both logs, everything is going at about the same pace, except the 404 error for SIPE.
I'll try uploading the log to Google Docs, otherwise I'll talk to my IT dept and see if they can help (although I doubt it, they're quite strict about not supporting what they didn't install)
Thanks for help.
Link to log: http://docs.google.com/Doc?docid=0AfAaqsJckAW3ZGdqcnZ6MjZfMmM0cjQ5OGc4&hl=en
well, your server said true last time (404) - it has no idea about velti.net SIP domain. It does not serve it.
Your username should be in form (This is 100%). Same as in Communicator:
user@velti.com
The same as in Office Communicator.
Now to authentication fields - Login+Password.
Since I see Communicator uses Kerberos, you are inside your domain. Also probably you have never explicitly entered your credentials to Communicator. It this case your login to domain credentials are used behind the scene. So I'm saying, as credentials in this case you should use your domain, login and password you use to login to your PC.
Try different forms for login:
DOMAIN\user
user@domain.com
user@domain.net
And most IMPORTANTLY, your server is (note .COM there; this is where Communicator connects):
ocs.company.com
TLS, port 5061
This problems sounds like a problem with permissions in the AD (SIP part) of the Domain Controller.
I remember one partner here could connect to the server because he always got a 404 error.
I went to the AD administrator to see what could be the problem, and we found the can permission to use SIP services ... he gave him that permissions and now he can use SIPE.
I don't know if the problem is the same ... but I think the problem is in the server side.
Regards.
Sorry, I wrote very fast ... I mean "we found he didn't have permissions to use SIP services"
pier eleven: I'll try several versions of the username login. Are you sure the server is ocs.company.com and not ocs1.comapny.com?
FixXxeR: I'll have to contact them to see if that's the issue. It sounds very close to what my problem could be.
your Communicator's log say that it connects to ocs.company.com