Has anyone used Jitsi as a client for Reuters Messaging (RM)?
RM works a bit like MSN, it is SIP based - a quick Google search shows
that Pidgin claims to work as a client for RM
If the product you´re talking about is based on open standards like
SIP then of course it´d work. You only need to figure out the name of
the servers it connects to.
FC
···
On Thu, Apr 5, 2012 at 19:24, Daniel Pocock <daniel@pocock.com.au> wrote:
Has anyone used Jitsi as a client for Reuters Messaging (RM)?
RM works a bit like MSN, it is SIP based - a quick Google search shows
that Pidgin claims to work as a client for RM
--
During times of Universal Deceit, telling the truth becomes a revolutionary act
Durante épocas de Engaño Universal, decir la verdad se convierte en un
Acto Revolucionario
- George Orwell
It's SIP/SIMPLE protocol.
···
On Thu, 5 Apr 2012 20:00:39 -0300 Fernando Cassia <fcassia@gmail.com> wrote:
If the product you´re talking about is based on open standards like
SIP then of course it´d work.
--
Not so SIMPLE though... they do some unusual things mapping/rewriting
the username that you log in with
···
On 06/04/12 01:16, Bzzz wrote:
On Thu, 5 Apr 2012 20:00:39 -0300 > Fernando Cassia <fcassia@gmail.com> wrote:
If the product you´re talking about is based on open standards like
SIP then of course it´d work.It's SIP/SIMPLE protocol.
Hmm, and what about checking if pidgin is really operative w/
reuters, then make a capture of the exchanges and submit it to
jitski gurus?
···
On Fri, 06 Apr 2012 18:16:09 +0200 Daniel Pocock <daniel@pocock.com.au> wrote:
Not so SIMPLE though... they do some unusual things mapping/rewriting
the username that you log in with
--
Anarchy may not be a better form of government, but it's better
than no government at all.
Not so SIMPLE though... they do some unusual things mapping/rewriting
the username that you log in withHmm, and what about checking if pidgin is really operative w/
reuters, then make a capture of the exchanges and submit it to
jitski gurus?
Here are some observations:
a) public users of the service connect to sip.reuters.net 443 (using SIP
over the HTTPS port)
b) the server expects the SIP protocol to have CRLF line termination, or
it drops the connection after the first message is sent
c) the client creates a sip address by mapping the login ID. E.g. if
user types in `bob@example.com', then the SIP ID will be
bob.example.org@reuters.net
d) the client sends a register advertising various features:
REGISTER sip:reuters.net SIP/2.0
Max-Forwards: 70
From: <sip:bob.example.org@reuters.net>
Call-ID: 12345
CSeq: 1 REGISTER
Contact: <sip:192.168.1.2:1112;transport=tls>;methods="INVITE, MESSAGE,
INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER,
BENOTIFY";proxy=replace
User-Agent: RTC/1.3.5369 (FM/1.0;MA/1.0;RMC_D/ 8.0.1.2)
Supported: com.microsoft.msrtc.presence, adhoclist
ms-keep-alive: UAC;hop-hop=yes
Event: registration
Allow-Events: presence
Content-Length: 0
e) the server expects NTLM auth:
SIP/2.0 401 Unauthorized
WWW-Authenticate: NTLM realm="SIP Communications Service",
targetname="something.Reuters.net"
Does Jitsi support everything in that session?
···
These appear to be the suspicious looking things in this SIP variation,
are they common to MSN or other protocols? Can Jitsi be told to work in
a particular MS SIP compatibility mode, or does this require some
development?
···
b) the server expects the SIP protocol to have CRLF line termination, or
it drops the connection after the first message is sent
Contact: <sip:192.168.1.2:1112;transport=tls>;methods="INVITE, MESSAGE,
INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER,
BENOTIFY";proxy=replace
Supported: com.microsoft.msrtc.presence, adhoclist
ms-keep-alive: UAC;hop-hop=yes
Event: registration
Allow-Events: presence
e) the server expects NTLM auth:
SIP/2.0 401 Unauthorized
WWW-Authenticate: NTLM realm="SIP Communications Service",
targetname="something.Reuters.net"
Thanks for the analysis Jake!
Comments inline:
Not so SIMPLE though... they do some unusual things mapping/rewriting
the username that you log in withHmm, and what about checking if pidgin is really operative w/
reuters, then make a capture of the exchanges and submit it to
jitski gurus?Here are some observations:
a) public users of the service connect to sip.reuters.net 443 (using SIP
over the HTTPS port)
Does the actual communication happen over https? Or is it simply TLS? Or
maybe even plain TCP?
b) the server expects the SIP protocol to have CRLF line termination, or
it drops the connection after the first message is sent
Not sure I got this. What else could it expect other than CRLF line
termination?
c) the client creates a sip address by mapping the login ID. E.g. if
user types in `bob@example.com', then the SIP ID will be
bob.example.org@reuters.net
Users can configure the authorization user name they for any account so
this shouldn't be a problem.
d) the client sends a register advertising various features:
REGISTER sip:reuters.net SIP/2.0
Max-Forwards: 70
From: <sip:bob.example.org@reuters.net>
To: <sip:bob.example.com@reuters.net>
Call-ID: 12345
CSeq: 1 REGISTER
Contact: <sip:192.168.1.2:1112;transport=tls>;methods="INVITE, MESSAGE,
INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER,
BENOTIFY";proxy=replace
User-Agent: RTC/1.3.5369 (FM/1.0;MA/1.0;RMC_D/ 8.0.1.2)
Supported: com.microsoft.msrtc.presence, adhoclist
ms-keep-alive: UAC;hop-hop=yes
Event: registration
Allow-Events: presence
Content-Length: 0
We have neither com.microsoft.msrtc.presence nor adhoclist. The
ms-keep-alive thing is also not supported.
e) the server expects NTLM auth:
SIP/2.0 401 Unauthorized
WWW-Authenticate: NTLM realm="SIP Communications Service",
targetname="something.Reuters.net"
This we don't have either.
Thanks again,
Emil
Thanks for the analysis Jake!
Comments inline:
Not so SIMPLE though... they do some unusual things mapping/rewriting
the username that you log in withHmm, and what about checking if pidgin is really operative w/
reuters, then make a capture of the exchanges and submit it to
jitski gurus?Here are some observations:
a) public users of the service connect to sip.reuters.net 443 (using SIP
over the HTTPS port)Does the actual communication happen over https? Or is it simply TLS? Or
maybe even plain TCP?
Just TLS (using the HTTPS port). This is a common scenario to help
people stuck on highly restrictive corporate networks, as their HTTP
proxy will allow them to connect to external HTTPS servers using the
HTTP CONNECT method.
On the server side, it is just a SIPS server listening on 443 instead of
the default 5061
Some Jabber providers do exactly the same thing, configuring their
server to listen for TLS connections on 443
For the chat client (RM, Jitsi or whatever) to have the maximum benefit
from this arrangement, it needs to
a) try and connect directly on port 443
b) if that is blocked by the firewall, try and find the proxy (using
WPAD or DHCP discovery, looking at browser settings, environment
variables, whatever)
c) connect to the proxy
d) send the CONNECT instruction to the proxy, asking to connect to the
external host on port 443
Does Jitsi support that algorithm?
b) the server expects the SIP protocol to have CRLF line termination, or
it drops the connection after the first message is sentNot sure I got this. What else could it expect other than CRLF line
termination?
UNIX uses LF only
Mac uses CR only
Now I understand the SIP RFC demands CRLF for all platforms.
When you use gnutls-cli to probe a TLS server, it uses UNIX LF
termination by default. Running
gnutls-cli --crlf <hostname>
makes it work with CRLF
c) the client creates a sip address by mapping the login ID. E.g. if
user types in `bob@example.com', then the SIP ID will be
bob.example.org@reuters.netUsers can configure the authorization user name they for any account so
this shouldn't be a problem.
If Jitsi was to offer a quick-setup option for users on corporate
networks (RM or any similar service), then it would probably have to
help them do this translation.
d) the client sends a register advertising various features:
REGISTER sip:reuters.net SIP/2.0
Max-Forwards: 70
From: <sip:bob.example.org@reuters.net>
To: <sip:bob.example.com@reuters.net>
Call-ID: 12345
CSeq: 1 REGISTER
Contact: <sip:192.168.1.2:1112;transport=tls>;methods="INVITE, MESSAGE,
INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER,
BENOTIFY";proxy=replace
User-Agent: RTC/1.3.5369 (FM/1.0;MA/1.0;RMC_D/ 8.0.1.2)
Supported: com.microsoft.msrtc.presence, adhoclist
ms-keep-alive: UAC;hop-hop=yes
Event: registration
Allow-Events: presence
Content-Length: 0We have neither com.microsoft.msrtc.presence nor adhoclist. The
ms-keep-alive thing is also not supported.
Are those common to other Microsoft platforms? Lync?
e) the server expects NTLM auth:
SIP/2.0 401 Unauthorized
WWW-Authenticate: NTLM realm="SIP Communications Service",
targetname="something.Reuters.net"This we don't have either.
Does the Jitsi API make it easy to add an authentication system? Could
you maybe give a pointer where to look?
NTLM just appears to be a variant of HTTP DIGEST, it is based on a nonce
and a hash of the password:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa378749(v=vs.85).aspx
The same problem has been studied by the Pidgin community:
http://blog.truecrux.org/post/vi
···
On 10/04/12 12:32, Emil Ivov wrote:
On 08.04.12 22:34, Jake wrote:
Thanks for the analysis Jake!
Comments inline:
Not so SIMPLE though... they do some unusual things mapping/rewriting
the username that you log in withHmm, and what about checking if pidgin is really operative w/
reuters, then make a capture of the exchanges and submit it to
jitski gurus?Here are some observations:
a) public users of the service connect to sip.reuters.net 443 (using SIP
over the HTTPS port)Does the actual communication happen over https? Or is it simply TLS? Or
maybe even plain TCP?Just TLS (using the HTTPS port).
OK, good to know!
This is a common scenario to help
people stuck on highly restrictive corporate networks, as their HTTP
proxy will allow them to connect to external HTTPS servers using the
HTTP CONNECT method.On the server side, it is just a SIPS server listening on 443 instead of
the default 5061Some Jabber providers do exactly the same thing, configuring their
server to listen for TLS connections on 443For the chat client (RM, Jitsi or whatever) to have the maximum benefit
from this arrangement, it needs toa) try and connect directly on port 443
b) if that is blocked by the firewall, try and find the proxy (using
WPAD or DHCP discovery, looking at browser settings, environment
variables, whatever)
c) connect to the proxy
d) send the CONNECT instruction to the proxy, asking to connect to the
external host on port 443
One can configure a custom port for SIP of course, but we don't do the rest.
Does Jitsi support that algorithm?
b) the server expects the SIP protocol to have CRLF line termination, or
it drops the connection after the first message is sentNot sure I got this. What else could it expect other than CRLF line
termination?UNIX uses LF only
Mac uses CR only
True, but neither of these are valid for SIP.
Now I understand the SIP RFC demands CRLF for all platforms.
Right.
When you use gnutls-cli to probe a TLS server, it uses UNIX LF
termination by default. Runninggnutls-cli --crlf <hostname>
makes it work with CRLF
c) the client creates a sip address by mapping the login ID. E.g. if
user types in `bob@example.com', then the SIP ID will be
bob.example.org@reuters.netUsers can configure the authorization user name they for any account so
this shouldn't be a problem.If Jitsi was to offer a quick-setup option for users on corporate
networks (RM or any similar service), then it would probably have to
help them do this translation.
In the corporate network case, this can already be handled through
provisioning.
d) the client sends a register advertising various features:
REGISTER sip:reuters.net SIP/2.0
Max-Forwards: 70
From: <sip:bob.example.org@reuters.net>
To: <sip:bob.example.com@reuters.net>
Call-ID: 12345
CSeq: 1 REGISTER
Contact: <sip:192.168.1.2:1112;transport=tls>;methods="INVITE, MESSAGE,
INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER,
BENOTIFY";proxy=replace
User-Agent: RTC/1.3.5369 (FM/1.0;MA/1.0;RMC_D/ 8.0.1.2)
Supported: com.microsoft.msrtc.presence, adhoclist
ms-keep-alive: UAC;hop-hop=yes
Event: registration
Allow-Events: presence
Content-Length: 0We have neither com.microsoft.msrtc.presence nor adhoclist. The
ms-keep-alive thing is also not supported.Are those common to other Microsoft platforms? Lync?
No idea. I would suppose (with no evidence to back it up) that this is
just an MS Office Communicator deployment so I'd guess it's normal for Lync.
e) the server expects NTLM auth:
SIP/2.0 401 Unauthorized
WWW-Authenticate: NTLM realm="SIP Communications Service",
targetname="something.Reuters.net"This we don't have either.
Does the Jitsi API make it easy to add an authentication system?
You won't be able to do this as a plugin but it wouldn't be that hard
nonetheless.
Could you maybe give a pointer where to look?
You may want to have a look at:
net.java.sip.communicator.impl.protocol.sip.security
Everything starts in SipSecurityManager.java and it then uses a few
other classes that handle DIGEST authentication.
Cheers,
Emil
···
On 10.04.12 15:48, Jake wrote:
On 10/04/12 12:32, Emil Ivov wrote:
On 08.04.12 22:34, Jake wrote: