[jitsi-users] CUSAX Incoming Contact Matching


#1

Hi,
I'm trying to setup CUSAX with Jitsi 2.4.4997, and followed the instructions at https://jitsi.org/Documentation/CUSAX .I also changed my SIP server configuration so that it adds the proper Call-Info header, and made sure it is working properly by using wireshark.But when I receive a call, Jitsi does not match it to the xmpp contact or an active chat session. Also, on the call window there is no "chat" button.Any idea what I could be doing wrong?
Thanks,Ricardo


#2

It sounds as if Jitsi doesn't know your two accounts are related.
Could you please show us how you provision them?

Emil

···

On Tue, Jan 28, 2014 at 1:14 PM, Ricardo Duarte <rjtd21@hotmail.com> wrote:

Hi,

I'm trying to setup CUSAX with Jitsi 2.4.4997, and followed the instructions
at https://jitsi.org/Documentation/CUSAX .
I also changed my SIP server configuration so that it adds the proper
Call-Info header, and made sure it is working properly by using wireshark.
But when I receive a call, Jitsi does not match it to the xmpp contact or an
active chat session. Also, on the call window there is no "chat" button.
Any idea what I could be doing wrong?

Thanks,
Ricardo

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#3

I’ve sent a dozen emails to the list since this last one appearing in the archive:

http://lists.jitsi.org/pipermail/users/2014-January/006225.html

but do not see them in the archive. Was there any problem with delivery?

Unfortunately, I am mostly sending via webmail which does not have a ‘sent’ folder, so they are probably gone.

Can anyone confirm if that was really the last one email from us?

figoli

___________________________________ NOCC, http://nocc.sourceforge.net


#4

Hi,

My provisioned configuration is the following:

net.java.sip.communicator.impl.protocol.sip=false
net.java.sip.communicator.util.dns.BACKUP_RESOLVER_ENABLED=false
net.java.sip.communicator.packetlogging.PACKET_LOGGING_ENABLED=false
net.java.sip.communicator.impl.gui.accounts.accMyCompany=SIP\:<%= @user.sip_extension %>@192.168.1.1
net.java.sip.communicator.impl.gui.accounts.accMyCompany.accountIndex=0
net.java.sip.communicator.impl.gui.accounts.accMyCompany.wizard=net_java_sip_communicator_plugin_sipaccregwizz_SIPAccountRegistrationWizard
net.java.sip.communicator.impl.protocol.sip.accMyCompany=accMyCompany
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ACCOUNT_ICON_PATH=resources/images/protocol/sip/sip32x32.png
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ACCOUNT_UID=SIP\:<%= @user.sip_extension %>@192.168.1.1
net.java.sip.communicator.impl.protocol.sip.accMyCompany.DEFAULT_ENCRYPTION=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.DEFAULT_SIPZRTP_ATTRIBUTE=true
net.java.sip.communicator.impl.protocol.sip.accMyCompany.DISPLAY_NAME=<%= @user.display_name %>
net.java.sip.communicator.impl.protocol.sip.accMyCompany.DTMF_METHOD=AUTO_DTMF
net.java.sip.communicator.impl.protocol.sip.accMyCompany.DTMF_MINIMAL_TONE_DURATION=70
net.java.sip.communicator.impl.protocol.sip.accMyCompany.PASSWORD=<%= @user.sip_secret %>
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL.ENCRYPTION_PROTOCOL.ZRTP=0
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL.SDES=1
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL.ZRTP=0
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL_STATUS.ENCRYPTION_PROTOCOL_STATUS.ZRTP=true
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL_STATUS.SDES=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL_STATUS.ZRTP=true
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.G722/8000=705
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.G723/8000=150
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.GSM/8000=450
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.H263-1998/90000=0
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.H264/90000=1100
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.PCMA/8000=600
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.PCMU/8000=650
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.SILK/12000=0
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.SILK/16000=703
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.SILK/24000=704
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.SILK/8000=0
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.VP8/90000=0
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.iLBC/8000=500
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.opus/48000=750
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.speex/16000=700
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.speex/32000=701
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.speex/8000=352
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.telephone-event/8000=1
net.java.sip.communicator.impl.protocol.sip.accMyCompany.FORCE_P2P_MODE=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.IS_ACCOUNT_DISABLED=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.IS_PRESENCE_ENABLED=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.KEEP_ALIVE_INTERVAL=25
net.java.sip.communicator.impl.protocol.sip.accMyCompany.KEEP_ALIVE_METHOD=OPTIONS
net.java.sip.communicator.impl.protocol.sip.accMyCompany.OVERRIDE_ENCODINGS=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.POLLING_PERIOD=30
net.java.sip.communicator.impl.protocol.sip.accMyCompany.PROTOCOL_NAME=SIP
net.java.sip.communicator.impl.protocol.sip.accMyCompany.PROXY_AUTO_CONFIG=true
net.java.sip.communicator.impl.protocol.sip.accMyCompany.SAVP_OPTION=0
net.java.sip.communicator.impl.protocol.sip.accMyCompany.SDES_CIPHER_SUITES=AES_CM_128_HMAC_SHA1_80,AES_CM_128_HMAC_SHA1_32
net.java.sip.communicator.impl.protocol.sip.accMyCompany.SERVER_ADDRESS=192.168.1.1
net.java.sip.communicator.impl.protocol.sip.accMyCompany.SERVER_PORT=5060
net.java.sip.communicator.impl.protocol.sip.accMyCompany.SUBSCRIPTION_EXPIRATION=3600
net.java.sip.communicator.impl.protocol.sip.accMyCompany.USER_ID=<%= @user.sip_extension %>@192.168.1.1
net.java.sip.communicator.impl.protocol.sip.accMyCompany.VOICEMAIL_ENABLED=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.XCAP_ENABLE=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.XIVO_ENABLE=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.cusax.XMPP_ACCOUNT_ID=accMyCompanyXMPP
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP=accMyCompanyXMPP
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ACCOUNT_UID=Jabber\:<%= @user_name %>@xmpp.mycompany.local
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ALLOW_NON_SECURE=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.AUTO_DISCOVER_JINGLE_NODES=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.AUTO_DISCOVER_STUN=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.AUTO_GENERATE_RESOURCE=true
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.BYPASS_GTALK_CAPABILITIES=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.CALLING_DISABLED=true
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.DEFAULT_ENCRYPTION=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.DEFAULT_SIPZRTP_ATTRIBUTE=true
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.DTMF_METHOD=AUTO_DTMF
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.DTMF_MINIMAL_TONE_DURATION=70
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.PASSWORD=<%= @user_password %>
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ENCRYPTION_PROTOCOL.SDES=1
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ENCRYPTION_PROTOCOL.ZRTP=0
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ENCRYPTION_PROTOCOL_STATUS.SDES=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ENCRYPTION_PROTOCOL_STATUS.ZRTP=true
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.GMAIL_NOTIFICATIONS_ENABLED=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.GOOGLE_CONTACTS_ENABLED=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.GTALK_ICE_ENABLED=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ICE_ENABLED=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.IS_PREFERRED_PROTOCOL=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.IS_SERVER_OVERRIDDEN=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.JINGLE_NODES_ENABLED=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.OVERRIDE_ENCODINGS=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.PROTOCOL_NAME=Jabber
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.RESOURCE=jitsi
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.RESOURCE_PRIORITY=30
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.SERVER_ADDRESS=xmpp.mycompany.local
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.SERVER_PORT=5222
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.UPNP_ENABLED=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.USER_ID=<%= @user_name %>@xmpp.mycompany.local
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.USE_DEFAULT_STUN_SERVER=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.CALLING_DISABLED=true

Regards,
Ricardo

···

From: emcho@jitsi.org
Date: Tue, 28 Jan 2014 18:44:01 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

It sounds as if Jitsi doesn't know your two accounts are related.
Could you please show us how you provision them?

Emil

On Tue, Jan 28, 2014 at 1:14 PM, Ricardo Duarte <rjtd21@hotmail.com> wrote:
> Hi,
>
> I'm trying to setup CUSAX with Jitsi 2.4.4997, and followed the instructions
> at https://jitsi.org/Documentation/CUSAX .
> I also changed my SIP server configuration so that it adds the proper
> Call-Info header, and made sure it is working properly by using wireshark.
> But when I receive a call, Jitsi does not match it to the xmpp contact or an
> active chat session. Also, on the call window there is no "chat" button.
> Any idea what I could be doing wrong?
>
> Thanks,
> Ricardo
>
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#5

Oops, I meant a different email! Between http://lists.jitsi.org/pipermail/users/2014-January/006268.html and http://lists.jitsi.org/pipermail/users/2014-January/006305.html I sent lots of emails to the list. They are not appearing in archive and I did not receive them as I normally do a minute after posting. That’s the correct range. figoli Info@dressmaker.ca wrote : > > > I’ve > sent a dozen emails to the list since this last one appearing in the > archive: > > > > http://lists.jitsi.org/pipermail/users/2014-January/006225.html > > > > but do not see them in the archive. Was there any problem with delivery? > > Unfortunately, I am mostly sending via webmail which does not have a > ‘sent’ folder, so they are probably gone. > > Can anyone confirm if that was really the last one email from us? > > > > figoli > > > > ___________________________________ > NOCC, http://nocc.sourceforge.net
___________________________________ NOCC, http://nocc.sourceforge.net


#6

As some of my older emails missed the list, I’ll try to describe the issues by memory here. First, it looks like Jitsi does require port translation at least on one side for voice to work. I finally had a user who was not behind a router, and myself behind a router could use voice and share screen in both directions with them. They called me and I called them and everything worked. Never tried video for lack of webcams on both ends though. There was lots of echo at times (the calls seem to start fine, but then echo creeps in and grows, then after a while it goes away), but otherwise everything worked Okay. But whenever we tried with the other users who are, like my office, behind a router, then calls would be dropped for ‘ICE error’ every time. Can anyone make any suggestions as to what ports need to be translated? On our office side we are only translating the ports used by OpenFire: 5222, 5223, 3478, 3479, 10000-20000. How would other side behind a router get a voice call request but not voice stream? That’s one issue. Another issue is that when I am in a voice call with that first user, and they share screen with me, then stop sharing, then voice encryption turns off and stays off for the rest of the call. We had to drop the call and re-connect to get encryption again. This is 100% reproducible. I was under Fedora 19 64bit and they are under WinXP 32bit half world away. We immediately tried that on the LAN instead and the result was different: encryption stayed on. Tried WAN again and it turned off. The last issue is what I reported earlier about UI freezing under Linux - I can confirm that this only occurs under KDE in my tests. When I switched desktop to Mate, everything worked fine, no freezing. KDE will freeze every time basically when I used any UI outside the chat window. It’s enough to start 2nd chat, or open Tools/Options and it will freeze. Once frozen, it will sometimes come back to life when main window is resized, but most of the time Jitsi will have to be killed (tray icon would be non-responsive too). figoli
___________________________________ NOCC, http://nocc.sourceforge.net


#7

Hey Ricardo,

That part seems OK. Are you sure that the URI from Call-Info points to
a contact whose vcard contains the source SIP URI? Jitsi wouldn't make
the association other wise for security reasons.

Emil

···

On Wed, Jan 29, 2014 at 10:32 AM, Ricardo Duarte <rjtd21@hotmail.com> wrote:

Hi,

My provisioned configuration is the following:

net.java.sip.communicator.impl.protocol.sip=false
net.java.sip.communicator.util.dns.BACKUP_RESOLVER_ENABLED=false
net.java.sip.communicator.packetlogging.PACKET_LOGGING_ENABLED=false
net.java.sip.communicator.impl.gui.accounts.accMyCompany=SIP\:<%=
@user.sip_extension %>@192.168.1.1
net.java.sip.communicator.impl.gui.accounts.accMyCompany.accountIndex=0
net.java.sip.communicator.impl.gui.accounts.accMyCompany.wizard=net_java_sip_communicator_plugin_sipaccregwizz_SIPAccountRegistrationWizard
net.java.sip.communicator.impl.protocol.sip.accMyCompany=accMyCompany
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ACCOUNT_ICON_PATH=resources/images/protocol/sip/sip32x32.png
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ACCOUNT_UID=SIP\:<%=
@user.sip_extension %>@192.168.1.1
net.java.sip.communicator.impl.protocol.sip.accMyCompany.DEFAULT_ENCRYPTION=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.DEFAULT_SIPZRTP_ATTRIBUTE=true
net.java.sip.communicator.impl.protocol.sip.accMyCompany.DISPLAY_NAME=<%=
@user.display_name %>
net.java.sip.communicator.impl.protocol.sip.accMyCompany.DTMF_METHOD=AUTO_DTMF
net.java.sip.communicator.impl.protocol.sip.accMyCompany.DTMF_MINIMAL_TONE_DURATION=70
net.java.sip.communicator.impl.protocol.sip.accMyCompany.PASSWORD=<%=
@user.sip_secret %>
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL.ENCRYPTION_PROTOCOL.ZRTP=0
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL.SDES=1
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL.ZRTP=0
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL_STATUS.ENCRYPTION_PROTOCOL_STATUS.ZRTP=true
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL_STATUS.SDES=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL_STATUS.ZRTP=true
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.G722/8000=705
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.G723/8000=150
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.GSM/8000=450
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.H263-1998/90000=0
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.H264/90000=1100
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.PCMA/8000=600
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.PCMU/8000=650
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.SILK/12000=0
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.SILK/16000=703
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.SILK/24000=704
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.SILK/8000=0
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.VP8/90000=0
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.iLBC/8000=500
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.opus/48000=750
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.speex/16000=700
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.speex/32000=701
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.speex/8000=352
net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.telephone-event/8000=1
net.java.sip.communicator.impl.protocol.sip.accMyCompany.FORCE_P2P_MODE=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.IS_ACCOUNT_DISABLED=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.IS_PRESENCE_ENABLED=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.KEEP_ALIVE_INTERVAL=25
net.java.sip.communicator.impl.protocol.sip.accMyCompany.KEEP_ALIVE_METHOD=OPTIONS
net.java.sip.communicator.impl.protocol.sip.accMyCompany.OVERRIDE_ENCODINGS=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.POLLING_PERIOD=30
net.java.sip.communicator.impl.protocol.sip.accMyCompany.PROTOCOL_NAME=SIP
net.java.sip.communicator.impl.protocol.sip.accMyCompany.PROXY_AUTO_CONFIG=true
net.java.sip.communicator.impl.protocol.sip.accMyCompany.SAVP_OPTION=0
net.java.sip.communicator.impl.protocol.sip.accMyCompany.SDES_CIPHER_SUITES=AES_CM_128_HMAC_SHA1_80,AES_CM_128_HMAC_SHA1_32
net.java.sip.communicator.impl.protocol.sip.accMyCompany.SERVER_ADDRESS=192.168.1.1
net.java.sip.communicator.impl.protocol.sip.accMyCompany.SERVER_PORT=5060
net.java.sip.communicator.impl.protocol.sip.accMyCompany.SUBSCRIPTION_EXPIRATION=3600
net.java.sip.communicator.impl.protocol.sip.accMyCompany.USER_ID=<%=
@user.sip_extension %>@192.168.1.1
net.java.sip.communicator.impl.protocol.sip.accMyCompany.VOICEMAIL_ENABLED=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.XCAP_ENABLE=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.XIVO_ENABLE=false
net.java.sip.communicator.impl.protocol.sip.accMyCompany.cusax.XMPP_ACCOUNT_ID=accMyCompanyXMPP
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP=accMyCompanyXMPP
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ACCOUNT_UID=Jabber\:<%=
@user_name %>@xmpp.mycompany.local
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ALLOW_NON_SECURE=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.AUTO_DISCOVER_JINGLE_NODES=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.AUTO_DISCOVER_STUN=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.AUTO_GENERATE_RESOURCE=true
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.BYPASS_GTALK_CAPABILITIES=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.CALLING_DISABLED=true
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.DEFAULT_ENCRYPTION=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.DEFAULT_SIPZRTP_ATTRIBUTE=true
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.DTMF_METHOD=AUTO_DTMF
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.DTMF_MINIMAL_TONE_DURATION=70
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.PASSWORD=<%=
@user_password %>
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ENCRYPTION_PROTOCOL.SDES=1
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ENCRYPTION_PROTOCOL.ZRTP=0
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ENCRYPTION_PROTOCOL_STATUS.SDES=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ENCRYPTION_PROTOCOL_STATUS.ZRTP=true
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.GMAIL_NOTIFICATIONS_ENABLED=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.GOOGLE_CONTACTS_ENABLED=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.GTALK_ICE_ENABLED=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ICE_ENABLED=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.IS_PREFERRED_PROTOCOL=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.IS_SERVER_OVERRIDDEN=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.JINGLE_NODES_ENABLED=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.OVERRIDE_ENCODINGS=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.PROTOCOL_NAME=Jabber
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.RESOURCE=jitsi
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.RESOURCE_PRIORITY=30
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.SERVER_ADDRESS=xmpp.mycompany.local
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.SERVER_PORT=5222
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.UPNP_ENABLED=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.USER_ID=<%=
@user_name %>@xmpp.mycompany.local
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.USE_DEFAULT_STUN_SERVER=false
net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.CALLING_DISABLED=true

Regards,
Ricardo

From: emcho@jitsi.org
Date: Tue, 28 Jan 2014 18:44:01 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

It sounds as if Jitsi doesn't know your two accounts are related.
Could you please show us how you provision them?

Emil

On Tue, Jan 28, 2014 at 1:14 PM, Ricardo Duarte <rjtd21@hotmail.com> >> wrote:
> Hi,
>
> I'm trying to setup CUSAX with Jitsi 2.4.4997, and followed the
> instructions
> at https://jitsi.org/Documentation/CUSAX .
> I also changed my SIP server configuration so that it adds the proper
> Call-Info header, and made sure it is working properly by using
> wireshark.
> But when I receive a call, Jitsi does not match it to the xmpp contact
> or an
> active chat session. Also, on the call window there is no "chat" button.
> Any idea what I could be doing wrong?
>
> Thanks,
> Ricardo
>
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#8

UPnP/NAT-PMP works for port translation. If the XMPP server being used has a
functioning jingle node (or both parties have a jingle node manually
configured in Jitsi, I believe) that should work too.

···

On Tuesday 28 January 2014 13:25:04 info@dressmaker.ca wrote:

As some of my older emails missed the list, I'll try to describe the issues
by memory here. First, it looks like Jitsi does require port translation at
least on one side for voice to work. I finally had a user who was not
behind a router, and myself behind a router could use voice and share
screen in both directions with them. They called me and I called them and
everything worked. Never tried video for lack of webcams on both ends
though. There was lots of echo at times (the calls seem to start fine, but
then echo creeps in and grows, then after a while it goes away), but
otherwise everything worked Okay. But whenever we tried with the other
users who are, like my office, behind a router, then calls would be dropped
for 'ICE error' every time. Can anyone make any suggestions as to what
ports need to be translated? On our office side we are only translating the
ports used by OpenFire: 5222, 5223, 3478, 3479, 10000-20000. How would
other side behind a router get a voice call request but not voice stream?
That's one issue. Another issue is that when I am in a voice call with that
first user, and they share screen with me, then stop sharing, then voice
encryption turns off and stays off for the rest of the call. We had to drop
the call and re-connect to get encryption again. This is 100% reproducible.
I was under Fedora 19 64bit and they are under WinXP 32bit half world away.
We immediately tried that on the LAN instead and the result was different:
encryption stayed on. Tried WAN again and it turned off. The last issue is
what I reported earlier about UI freezing under Linux - I can confirm that
this only occurs under KDE in my tests. When I switched desktop to Mate,
everything worked fine, no freezing. KDE will freeze every time basically
when I used any UI outside the chat window. It's enough to start 2nd chat,
or open Tools/Options and it will freeze. Once frozen, it will sometimes
come back to life when main window is resized, but most of the time Jitsi
will have to be killed (tray icon would be non-responsive too). figoli
___________________________________ NOCC, http://nocc.sourceforge.net


#9

Hey there,

As some of my older emails missed the list, I'll try to describe the issues
by memory here. First, it looks like Jitsi does require port translation at
least on one side for voice to work.

If you are referring to manual port translation then no, this is not
the case. Jitsi either uses ICE or relies on servers to do latching.
Manual port translation is in no way a requirement (and most of the
time it's not even helpful).

I finally had a user who was not behind
a router, and myself behind a router could use voice and share screen in
both directions with them. They called me and I called them and everything
worked. Never tried video for lack of webcams on both ends though.

What servers did you use?

There was
lots of echo at times (the calls seem to start fine, but then echo creeps in
and grows, then after a while it goes away), but otherwise everything worked
Okay. But whenever we tried with the other users who are, like my office,
behind a router, then calls would be dropped for 'ICE error' every time.

Jitsi requires a fallback relaying mechanism like Jingle Nodes or
TURN. That server needs to run on a public IP address.
It also currently requires UDP to be allowed for all users.

Can
anyone make any suggestions as to what ports need to be translated? On our
office side we are only translating the ports used by OpenFire: 5222, 5223,
3478, 3479, 10000-20000. How would other side behind a router get a voice
call request but not voice stream? That's one issue.

If you have no server on the public Internet to provide you with media
relaying then it is likely that some calls will fail.

Another issue is that
when I am in a voice call with that first user, and they share screen with
me, then stop sharing, then voice encryption turns off and stays off for the
rest of the call.

That's just a visual indication problem.

We had to drop the call and re-connect to get encryption
again. This is 100% reproducible. I was under Fedora 19 64bit and they are
under WinXP 32bit half world away. We immediately tried that on the LAN
instead and the result was different: encryption stayed on. Tried WAN again
and it turned off. The last issue is what I reported earlier about UI
freezing under Linux - I can confirm that this only occurs under KDE in my
tests. When I switched desktop to Mate, everything worked fine, no freezing.
KDE will freeze every time basically when I used any UI outside the chat
window. It's enough to start 2nd chat, or open Tools/Options and it will
freeze. Once frozen, it will sometimes come back to life when main window is
resized, but most of the time Jitsi will have to be killed (tray icon would
be non-responsive too). figoli

Thanks for reporting this. Could you please open a ticket?

Emil

···

On Tue, Jan 28, 2014 at 7:25 PM, <info@dressmaker.ca> wrote:

___________________________________ NOCC, http://nocc.sourceforge.net
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#10

Hi,

My Call-Info is:
Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=imppThis is what my Freeswitch IP PBX sends on the SIP INVITE message, and I start the call from jitsi I can also see the same information on the it's SIP INVITE.
My XMPP domain is xmpp.mycompany.local, that is also my xmpp server name.
I can see user@xmpp.mycompany.local on the contact card on jitsi as well.

Any ideas?

Regards,
Ricardo

···

From: emcho@jitsi.org
Date: Wed, 29 Jan 2014 14:42:07 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hey Ricardo,

That part seems OK. Are you sure that the URI from Call-Info points to
a contact whose vcard contains the source SIP URI? Jitsi wouldn't make
the association other wise for security reasons.

Emil

On Wed, Jan 29, 2014 at 10:32 AM, Ricardo Duarte <rjtd21@hotmail.com> wrote:
> Hi,
>
> My provisioned configuration is the following:
>
> net.java.sip.communicator.impl.protocol.sip=false
> net.java.sip.communicator.util.dns.BACKUP_RESOLVER_ENABLED=false
> net.java.sip.communicator.packetlogging.PACKET_LOGGING_ENABLED=false
> net.java.sip.communicator.impl.gui.accounts.accMyCompany=SIP\:<%=
> @user.sip_extension %>@192.168.1.1
> net.java.sip.communicator.impl.gui.accounts.accMyCompany.accountIndex=0
> net.java.sip.communicator.impl.gui.accounts.accMyCompany.wizard=net_java_sip_communicator_plugin_sipaccregwizz_SIPAccountRegistrationWizard
> net.java.sip.communicator.impl.protocol.sip.accMyCompany=accMyCompany
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.ACCOUNT_ICON_PATH=resources/images/protocol/sip/sip32x32.png
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.ACCOUNT_UID=SIP\:<%=
> @user.sip_extension %>@192.168.1.1
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.DEFAULT_ENCRYPTION=false
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.DEFAULT_SIPZRTP_ATTRIBUTE=true
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.DISPLAY_NAME=<%=
> @user.display_name %>
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.DTMF_METHOD=AUTO_DTMF
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.DTMF_MINIMAL_TONE_DURATION=70
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.PASSWORD=<%=
> @user.sip_secret %>
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL.ENCRYPTION_PROTOCOL.ZRTP=0
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL.SDES=1
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL.ZRTP=0
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL_STATUS.ENCRYPTION_PROTOCOL_STATUS.ZRTP=true
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL_STATUS.SDES=false
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.ENCRYPTION_PROTOCOL_STATUS.ZRTP=true
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.G722/8000=705
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.G723/8000=150
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.GSM/8000=450
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.H263-1998/90000=0
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.H264/90000=1100
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.PCMA/8000=600
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.PCMU/8000=650
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.SILK/12000=0
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.SILK/16000=703
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.SILK/24000=704
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.SILK/8000=0
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.VP8/90000=0
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.iLBC/8000=500
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.opus/48000=750
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.speex/16000=700
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.speex/32000=701
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.speex/8000=352
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.Encodings.telephone-event/8000=1
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.FORCE_P2P_MODE=false
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.IS_ACCOUNT_DISABLED=false
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.IS_PRESENCE_ENABLED=false
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.KEEP_ALIVE_INTERVAL=25
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.KEEP_ALIVE_METHOD=OPTIONS
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.OVERRIDE_ENCODINGS=false
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.POLLING_PERIOD=30
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.PROTOCOL_NAME=SIP
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.PROXY_AUTO_CONFIG=true
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.SAVP_OPTION=0
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.SDES_CIPHER_SUITES=AES_CM_128_HMAC_SHA1_80,AES_CM_128_HMAC_SHA1_32
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.SERVER_ADDRESS=192.168.1.1
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.SERVER_PORT=5060
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.SUBSCRIPTION_EXPIRATION=3600
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.USER_ID=<%=
> @user.sip_extension %>@192.168.1.1
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.VOICEMAIL_ENABLED=false
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.XCAP_ENABLE=false
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.XIVO_ENABLE=false
> net.java.sip.communicator.impl.protocol.sip.accMyCompany.cusax.XMPP_ACCOUNT_ID=accMyCompanyXMPP
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP=accMyCompanyXMPP
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ACCOUNT_UID=Jabber\:<%=
> @user_name %>@xmpp.mycompany.local
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ALLOW_NON_SECURE=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.AUTO_DISCOVER_JINGLE_NODES=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.AUTO_DISCOVER_STUN=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.AUTO_GENERATE_RESOURCE=true
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.BYPASS_GTALK_CAPABILITIES=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.CALLING_DISABLED=true
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.DEFAULT_ENCRYPTION=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.DEFAULT_SIPZRTP_ATTRIBUTE=true
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.DTMF_METHOD=AUTO_DTMF
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.DTMF_MINIMAL_TONE_DURATION=70
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.PASSWORD=<%=
> @user_password %>
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ENCRYPTION_PROTOCOL.SDES=1
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ENCRYPTION_PROTOCOL.ZRTP=0
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ENCRYPTION_PROTOCOL_STATUS.SDES=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ENCRYPTION_PROTOCOL_STATUS.ZRTP=true
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.GMAIL_NOTIFICATIONS_ENABLED=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.GOOGLE_CONTACTS_ENABLED=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.GTALK_ICE_ENABLED=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.ICE_ENABLED=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.IS_PREFERRED_PROTOCOL=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.IS_SERVER_OVERRIDDEN=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.JINGLE_NODES_ENABLED=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.OVERRIDE_ENCODINGS=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.PROTOCOL_NAME=Jabber
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.RESOURCE=jitsi
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.RESOURCE_PRIORITY=30
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.SERVER_ADDRESS=xmpp.mycompany.local
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.SERVER_PORT=5222
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.UPNP_ENABLED=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.USER_ID=<%=
> @user_name %>@xmpp.mycompany.local
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.USE_DEFAULT_STUN_SERVER=false
> net.java.sip.communicator.impl.protocol.jabber.accMyCompanyXMPP.CALLING_DISABLED=true
>
> Regards,
> Ricardo
>
>> From: emcho@jitsi.org
>> Date: Tue, 28 Jan 2014 18:44:01 +0100
>> To: users@jitsi.org
>> Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching
>
>>
>> It sounds as if Jitsi doesn't know your two accounts are related.
>> Could you please show us how you provision them?
>>
>> Emil
>>
>> On Tue, Jan 28, 2014 at 1:14 PM, Ricardo Duarte <rjtd21@hotmail.com> > >> wrote:
>> > Hi,
>> >
>> > I'm trying to setup CUSAX with Jitsi 2.4.4997, and followed the
>> > instructions
>> > at https://jitsi.org/Documentation/CUSAX .
>> > I also changed my SIP server configuration so that it adds the proper
>> > Call-Info header, and made sure it is working properly by using
>> > wireshark.
>> > But when I receive a call, Jitsi does not match it to the xmpp contact
>> > or an
>> > active chat session. Also, on the call window there is no "chat" button.
>> > Any idea what I could be doing wrong?
>> >
>> > Thanks,
>> > Ricardo
>> >
>> > _______________________________________________
>> > users mailing list
>> > users@jitsi.org
>> > Unsubscribe instructions and other list options:
>> > http://lists.jitsi.org/mailman/listinfo/users
>>
>>
>>
>> --
>> Emil Ivov, Ph.D. 67000 Strasbourg,
>> Project Lead France
>> Jitsi
>> emcho@jitsi.org PHONE: +33.1.77.62.43.30
>> https://jitsi.org FAX: +33.1.77.62.47.31
>>
>> _______________________________________________
>> users mailing list
>> users@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/users
>
>
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#11

Hey Ricardo,

···

On Wed, Jan 29, 2014 at 3:55 PM, Ricardo Duarte <rjtd21@hotmail.com> wrote:

Hi,

My Call-Info is:

Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp

My questions was more about: what does the "From:" header in the above
INVITE contain? Is the URI from the "From" header present in the vcard
for the "xmpp:user@xmpp.mycompany.local" contact ?

--
https://jitsi.org


#12

In data martedì 28 gennaio 2014 19:36:32, Emil Ivov ha scritto:

> We had to drop the call and re-connect to get encryption
> again. This is 100% reproducible. I was under Fedora 19 64bit and they are
> under WinXP 32bit half world away. We immediately tried that on the LAN
> instead and the result was different: encryption stayed on. Tried WAN
> again
> and it turned off. The last issue is what I reported earlier about UI
> freezing under Linux - I can confirm that this only occurs under KDE in my
> tests. When I switched desktop to Mate, everything worked fine, no
> freezing. KDE will freeze every time basically when I used any UI outside
> the chat window. It's enough to start 2nd chat, or open Tools/Options and
> it will freeze. Once frozen, it will sometimes come back to life when
> main window is resized, but most of the time Jitsi will have to be killed
> (tray icon would be non-responsive too). figoli

Thanks for reporting this. Could you please open a ticket?

Emil

Is jitsi the only java swing-based application that freezes? Are you using
oracle jre or openjdk jre? I hit this kind of bug with both jre when using
oxygen-gtk as the theme for gtk apps under KDE. Be sure to use another (I'm
using adwaita, but others like adwaita works just as fine).


#13

Hi,

The "From" is the SIP user identifier, as it's not XMPP that is doing the call, but SIP.
And I guess the glue between both XMPP and SIP is the Call-Info field.

So, in this case:

  Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp

PS.: USEREXTENSION actually matches user phone on vcard.

Regards,
Ricardo

···

From: USEREXTENSION@192.168.1.1

From: emcho@jitsi.org
Date: Wed, 29 Jan 2014 16:00:29 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hey Ricardo,

On Wed, Jan 29, 2014 at 3:55 PM, Ricardo Duarte <rjtd21@hotmail.com> wrote:
> Hi,
>
> My Call-Info is:
>
> Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp

My questions was more about: what does the "From:" header in the above
INVITE contain? Is the URI from the "From" header present in the vcard
for the "xmpp:user@xmpp.mycompany.local" contact ?

--
https://jitsi.org

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#14

Hey Ricardo,

Hi,

The "From" is the SIP user identifier, as it's not XMPP that is doing the
call, but SIP.

Yes, I got that. That's how CUSAX works.

And I guess the glue between both XMPP and SIP is the Call-Info field.

That's what I am trying to say. It is not *only* the Call-Info.
There's a second verification against the XMPP vcard. Absent that
verification, it would be very easy for me to call you and pretend
that I am your banker.

So, in this case:

  From: USEREXTENSION@192.168.1.1
  Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp

PS.: USEREXTENSION actually matches user phone on vcard.

OK, that's what I needed to know. Does it appear in the exact same
format? That is, is it a perfect match of the entire URI? Or maybe
just the user part of the URI? I think that something is most likely
blocking there. We just need to find out exactly what it is and then
decide where to fix it.

Emil

···

On Wed, Jan 29, 2014 at 4:34 PM, Ricardo Duarte <rjtd21@hotmail.com> wrote:

Regards,
Ricardo

From: emcho@jitsi.org
Date: Wed, 29 Jan 2014 16:00:29 +0100

To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hey Ricardo,

On Wed, Jan 29, 2014 at 3:55 PM, Ricardo Duarte <rjtd21@hotmail.com> >> wrote:
> Hi,
>
> My Call-Info is:
>
> Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp

My questions was more about: what does the "From:" header in the above
INVITE contain? Is the URI from the "From" header present in the vcard
for the "xmpp:user@xmpp.mycompany.local" contact ?

--
https://jitsi.org

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#15

Hi Emil,

I can see I don't have anything on the "Phone:" field of the vcard, but only on the Extended tab as Work Phone. Maybe that could be the problem.

Can you describe the match that you do?
Is it something like <sip address before the @> == Phone on vcard ? Other?

Thanks,
Ricardo

···

From: emcho@jitsi.org
Date: Wed, 29 Jan 2014 16:40:57 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hey Ricardo,

On Wed, Jan 29, 2014 at 4:34 PM, Ricardo Duarte <rjtd21@hotmail.com> wrote:
> Hi,
>
> The "From" is the SIP user identifier, as it's not XMPP that is doing the
> call, but SIP.

Yes, I got that. That's how CUSAX works.

> And I guess the glue between both XMPP and SIP is the Call-Info field.

That's what I am trying to say. It is not *only* the Call-Info.
There's a second verification against the XMPP vcard. Absent that
verification, it would be very easy for me to call you and pretend
that I am your banker.

> So, in this case:
>
> From: USEREXTENSION@192.168.1.1
> Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp
>
> PS.: USEREXTENSION actually matches user phone on vcard.

OK, that's what I needed to know. Does it appear in the exact same
format? That is, is it a perfect match of the entire URI? Or maybe
just the user part of the URI? I think that something is most likely
blocking there. We just need to find out exactly what it is and then
decide where to fix it.

Emil

>
> Regards,
> Ricardo
>
>> From: emcho@jitsi.org
>> Date: Wed, 29 Jan 2014 16:00:29 +0100
>
>> To: users@jitsi.org
>> Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching
>>
>> Hey Ricardo,
>>
>> On Wed, Jan 29, 2014 at 3:55 PM, Ricardo Duarte <rjtd21@hotmail.com> > >> wrote:
>> > Hi,
>> >
>> > My Call-Info is:
>> >
>> > Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp
>>
>> My questions was more about: what does the "From:" header in the above
>> INVITE contain? Is the URI from the "From" header present in the vcard
>> for the "xmpp:user@xmpp.mycompany.local" contact ?
>>
>> --
>> https://jitsi.org
>>
>> _______________________________________________
>> users mailing list
>> users@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/users
>
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#16

Hi Emil,

I can see I don't have anything on the "Phone:" field of the vcard, but only
on the Extended tab as Work Phone. Maybe that could be the problem.

Work phone should also work.

Can you describe the match that you do?
Is it something like <sip address before the @> == Phone on vcard ? Other?

Currently it's an exact match with the *entire* URI and not just the
user part. Could this be the issue? Yana should commit a "contains"
comparison in a few minutes.

Emil

···

On Wed, Jan 29, 2014 at 5:13 PM, Ricardo Duarte <rjtd21@hotmail.com> wrote:

Thanks,
Ricardo

From: emcho@jitsi.org
Date: Wed, 29 Jan 2014 16:40:57 +0100

To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hey Ricardo,

On Wed, Jan 29, 2014 at 4:34 PM, Ricardo Duarte <rjtd21@hotmail.com> >> wrote:
> Hi,
>
> The "From" is the SIP user identifier, as it's not XMPP that is doing
> the
> call, but SIP.

Yes, I got that. That's how CUSAX works.

> And I guess the glue between both XMPP and SIP is the Call-Info field.

That's what I am trying to say. It is not *only* the Call-Info.
There's a second verification against the XMPP vcard. Absent that
verification, it would be very easy for me to call you and pretend
that I am your banker.

> So, in this case:
>
> From: USEREXTENSION@192.168.1.1
> Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp
>
> PS.: USEREXTENSION actually matches user phone on vcard.

OK, that's what I needed to know. Does it appear in the exact same
format? That is, is it a perfect match of the entire URI? Or maybe
just the user part of the URI? I think that something is most likely
blocking there. We just need to find out exactly what it is and then
decide where to fix it.

Emil

>
> Regards,
> Ricardo
>
>> From: emcho@jitsi.org
>> Date: Wed, 29 Jan 2014 16:00:29 +0100
>
>> To: users@jitsi.org
>> Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching
>>
>> Hey Ricardo,
>>
>> On Wed, Jan 29, 2014 at 3:55 PM, Ricardo Duarte <rjtd21@hotmail.com> >> >> wrote:
>> > Hi,
>> >
>> > My Call-Info is:
>> >
>> > Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp
>>
>> My questions was more about: what does the "From:" header in the above
>> INVITE contain? Is the URI from the "From" header present in the vcard
>> for the "xmpp:user@xmpp.mycompany.local" contact ?
>>
>> --
>> https://jitsi.org
>>
>> _______________________________________________
>> users mailing list
>> users@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/users
>
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#17

Hi,

Can you provide me a small example of the kind of vcard you require, and where the match is made?
I can quickly change that on my XMPP server and test.
This is mine (so, I only have tags for real telephone numbers):

<vCard xmlns="vcard-temp">
  <N>
    <GIVEN>{displayName}</GIVEN>
  </N>
  <EMAIL>
    <INTERNET/>
    <USERID>{mail}</USERID>
  </EMAIL>
  <FN>{name}</FN>
  <ADR>
    <HOME/>
    <STREET>{homePostalAddress}</STREET>
    <PCODE>{homeZip}</PCODE>
    <CTRY>{co}</CTRY>
  </ADR>
  <ADR>
    <WORK/>
    <STREET>{streetAddress}</STREET>
    <LOCALITY>{l}</LOCALITY>
    <REGION>{st}</REGION>
    <PCODE>{postalCode}</PCODE>
    <CTRY>{co}</CTRY>
  </ADR>
  <TEL>
    <HOME/>
    <VOICE/>
    <NUMBER>{homePhone}</NUMBER>
  </TEL>
  <TEL>
    <HOME/>
    <CELL/>
    <NUMBER>{mobile}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <VOICE/>
    <NUMBER>{telephoneNumber}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <CELL/>
    <NUMBER>{mobile}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <FAX/>
    <NUMBER>{facsimileTelephoneNumber}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <PAGER/>
    <NUMBER>{pager}</NUMBER>
  </TEL>
  <TITLE>{title}</TITLE>
  <ORG>
    <ORGUNIT>{department}</ORGUNIT>
  </ORG>
</vCard>

Another thing. What's the case when people dial short extensions, say, in an office (ex: number is 222222XXX, people dial XXX, caller id will be XXX)? You would also not match them.

As it is the SIP server that controls call-info, why is it not enough to use it as glue? Maybe you could add that as an option (only use call-info to match CUSAX).

Thanks,
Ricardo

···

From: emcho@jitsi.org
Date: Wed, 29 Jan 2014 17:16:22 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

On Wed, Jan 29, 2014 at 5:13 PM, Ricardo Duarte <rjtd21@hotmail.com> wrote:
> Hi Emil,
>
> I can see I don't have anything on the "Phone:" field of the vcard, but only
> on the Extended tab as Work Phone. Maybe that could be the problem.

Work phone should also work.

> Can you describe the match that you do?
> Is it something like <sip address before the @> == Phone on vcard ? Other?

Currently it's an exact match with the *entire* URI and not just the
user part. Could this be the issue? Yana should commit a "contains"
comparison in a few minutes.

Emil
>
> Thanks,
> Ricardo
>
>> From: emcho@jitsi.org
>> Date: Wed, 29 Jan 2014 16:40:57 +0100
>
>> To: users@jitsi.org
>> Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching
>>
>> Hey Ricardo,
>>
>> On Wed, Jan 29, 2014 at 4:34 PM, Ricardo Duarte <rjtd21@hotmail.com> > >> wrote:
>> > Hi,
>> >
>> > The "From" is the SIP user identifier, as it's not XMPP that is doing
>> > the
>> > call, but SIP.
>>
>> Yes, I got that. That's how CUSAX works.
>>
>> > And I guess the glue between both XMPP and SIP is the Call-Info field.
>>
>> That's what I am trying to say. It is not *only* the Call-Info.
>> There's a second verification against the XMPP vcard. Absent that
>> verification, it would be very easy for me to call you and pretend
>> that I am your banker.
>>
>> > So, in this case:
>> >
>> > From: USEREXTENSION@192.168.1.1
>> > Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp
>> >
>> > PS.: USEREXTENSION actually matches user phone on vcard.
>>
>> OK, that's what I needed to know. Does it appear in the exact same
>> format? That is, is it a perfect match of the entire URI? Or maybe
>> just the user part of the URI? I think that something is most likely
>> blocking there. We just need to find out exactly what it is and then
>> decide where to fix it.
>>
>> Emil
>>
>>
>> >
>> > Regards,
>> > Ricardo
>> >
>> >> From: emcho@jitsi.org
>> >> Date: Wed, 29 Jan 2014 16:00:29 +0100
>> >
>> >> To: users@jitsi.org
>> >> Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching
>> >>
>> >> Hey Ricardo,
>> >>
>> >> On Wed, Jan 29, 2014 at 3:55 PM, Ricardo Duarte <rjtd21@hotmail.com> > >> >> wrote:
>> >> > Hi,
>> >> >Also, there is also a case of people calling extensions.
>> >> > My Call-Info is:
>> >> >
>> >> > Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp
>> >>
>> >> My questions was more about: what does the "From:" header in the above
>> >> INVITE contain? Is the URI from the "From" header present in the vcard
>> >> for the "xmpp:user@xmpp.mycompany.local" contact ?
>> >>
>> >> --
>> >> https://jitsi.org
>> >>
>> >> _______________________________________________
>> >> users mailing list
>> >> users@jitsi.org
>> >> Unsubscribe instructions and other list options:
>> >> http://lists.jitsi.org/mailman/listinfo/users
>> >
>> > _______________________________________________
>> > users mailing list
>> > users@jitsi.org
>> > Unsubscribe instructions and other list options:
>> > http://lists.jitsi.org/mailman/listinfo/users
>>
>>
>>
>> --
>> Emil Ivov, Ph.D. 67000 Strasbourg,
>> Project Lead France
>> Jitsi
>> emcho@jitsi.org PHONE: +33.1.77.62.43.30
>> https://jitsi.org FAX: +33.1.77.62.47.31
>>
>> _______________________________________________
>> users mailing list
>> users@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/users
>
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#18

Hi,
I changed the function doesDetailBelong to always return true (looks like it would then ignore the telephone number check), but still no match is made.
Regards,Ricardo

···

From: rjtd21@hotmail.com
To: users@jitsi.org
Date: Wed, 29 Jan 2014 16:24:32 +0000
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hi,

Can you provide me a small example of the kind of vcard you require, and where the match is made?
I can quickly change that on my XMPP server and test.
This is mine (so, I only have tags for real telephone numbers):

<vCard xmlns="vcard-temp">
  <N>
    <GIVEN>{displayName}</GIVEN>
  </N>
  <EMAIL>
    <INTERNET/>
    <USERID>{mail}</USERID>
  </EMAIL>
  <FN>{name}</FN>
  <ADR>
    <HOME/>
    <STREET>{homePostalAddress}</STREET>
    <PCODE>{homeZip}</PCODE>
    <CTRY>{co}</CTRY>
  </ADR>
  <ADR>
    <WORK/>
    <STREET>{streetAddress}</STREET>
    <LOCALITY>{l}</LOCALITY>
    <REGION>{st}</REGION>
    <PCODE>{postalCode}</PCODE>
    <CTRY>{co}</CTRY>
  </ADR>
  <TEL>
    <HOME/>
    <VOICE/>
    <NUMBER>{homePhone}</NUMBER>
  </TEL>
  <TEL>
    <HOME/>
    <CELL/>
    <NUMBER>{mobile}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <VOICE/>
    <NUMBER>{telephoneNumber}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <CELL/>
    <NUMBER>{mobile}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <FAX/>
    <NUMBER>{facsimileTelephoneNumber}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <PAGER/>
    <NUMBER>{pager}</NUMBER>
  </TEL>
  <TITLE>{title}</TITLE>
  <ORG>
    <ORGUNIT>{department}</ORGUNIT>
  </ORG>
</vCard>

Another thing. What's the case when people dial short extensions, say, in an office (ex: number is 222222XXX, people dial XXX, caller id will be XXX)? You would also not match them.

As it is the SIP server that controls call-info, why is it not enough to use it as glue? Maybe you could add that as an option (only use call-info to match CUSAX).

Thanks,
Ricardo

From: emcho@jitsi.org
Date: Wed, 29 Jan 2014 17:16:22 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

On Wed, Jan 29, 2014 at 5:13 PM, Ricardo Duarte <rjtd21@hotmail.com> wrote:
> Hi Emil,
>
> I can see I don't have anything on the "Phone:" field of the vcard, but only
> on the Extended tab as Work Phone. Maybe that could be the problem.

Work phone should also work.

> Can you describe the match that you do?
> Is it something like <sip address before the @> == Phone on vcard ? Other?

Currently it's an exact match with the *entire* URI and not just the
user part. Could this be the issue? Yana should commit a "contains"
comparison in a few minutes.

Emil
>
> Thanks,
> Ricardo
>
>> From: emcho@jitsi.org
>> Date: Wed, 29 Jan 2014 16:40:57 +0100
>
>> To: users@jitsi.org
>> Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching
>>
>> Hey Ricardo,
>>
>> On Wed, Jan 29, 2014 at 4:34 PM, Ricardo Duarte <rjtd21@hotmail.com> > >> wrote:
>> > Hi,
>> >
>> > The "From" is the SIP user identifier, as it's not XMPP that is doing
>> > the
>> > call, but SIP.
>>
>> Yes, I got that. That's how CUSAX works.
>>
>> > And I guess the glue between both XMPP and SIP is the Call-Info field.
>>
>> That's what I am trying to say. It is not *only* the Call-Info.
>> There's a second verification against the XMPP vcard. Absent that
>> verification, it would be very easy for me to call you and pretend
>> that I am your banker.
>>
>> > So, in this case:
>> >
>> > From: USEREXTENSION@192.168.1.1
>> > Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp
>> >
>> > PS.: USEREXTENSION actually matches user phone on vcard.
>>
>> OK, that's what I needed to know. Does it appear in the exact same
>> format? That is, is it a perfect match of the entire URI? Or maybe
>> just the user part of the URI? I think that something is most likely
>> blocking there. We just need to find out exactly what it is and then
>> decide where to fix it.
>>
>> Emil
>>
>>
>> >
>> > Regards,
>> > Ricardo
>> >
>> >> From: emcho@jitsi.org
>> >> Date: Wed, 29 Jan 2014 16:00:29 +0100
>> >
>> >> To: users@jitsi.org
>> >> Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching
>> >>
>> >> Hey Ricardo,
>> >>
>> >> On Wed, Jan 29, 2014 at 3:55 PM, Ricardo Duarte <rjtd21@hotmail.com> > >> >> wrote:
>> >> > Hi,
>> >> >Also, there is also a case of people calling extensions.
>> >> > My Call-Info is:
>> >> >
>> >> > Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp
>> >>
>> >> My questions was more about: what does the "From:" header in the above
>> >> INVITE contain? Is the URI from the "From" header present in the vcard
>> >> for the "xmpp:user@xmpp.mycompany.local" contact ?
>> >>
>> >> --
>> >> https://jitsi.org
>> >>
>> >> _______________________________________________
>> >> users mailing list
>> >> users@jitsi.org
>> >> Unsubscribe instructions and other list options:
>> >> http://lists.jitsi.org/mailman/listinfo/users
>> >
>> > _______________________________________________
>> > users mailing list
>> > users@jitsi.org
>> > Unsubscribe instructions and other list options:
>> > http://lists.jitsi.org/mailman/listinfo/users
>>
>>
>>
>> --
>> Emil Ivov, Ph.D. 67000 Strasbourg,
>> Project Lead France
>> Jitsi
>> emcho@jitsi.org PHONE: +33.1.77.62.43.30
>> https://jitsi.org FAX: +33.1.77.62.47.31
>>
>> _______________________________________________
>> users mailing list
>> users@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/users
>
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#19

Hi,
Made some further debug and my findings are the following:
imppAddress is being read properly from the SIP INVITE.getPeerContact is called, but returns null.The null is due to presenceOpSet being null.

private static Contact getPeerContact( CallPeer callPeer, ProtocolProviderService cusaxProvider, String alternativePeerAddress){ OperationSetPresence presenceOpSet = cusaxProvider.getOperationSet(OperationSetPresence.class);
  if (presenceOpSet == null) { return null; }
  (...)
Regards,Ricardo

···

From: rjtd21@hotmail.com
To: users@jitsi.org
Date: Thu, 30 Jan 2014 10:22:19 +0000
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hi,
I changed the function doesDetailBelong to always return true (looks like it would then ignore the telephone number check), but still no match is made.
Regards,Ricardo

From: rjtd21@hotmail.com
To: users@jitsi.org
Date: Wed, 29 Jan 2014 16:24:32 +0000
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hi,

Can you provide me a small example of the kind of vcard you require, and where the match is made?
I can quickly change that on my XMPP server and test.
This is mine (so, I only have tags for real telephone numbers):

<vCard xmlns="vcard-temp">
  <N>
    <GIVEN>{displayName}</GIVEN>
  </N>
  <EMAIL>
    <INTERNET/>
    <USERID>{mail}</USERID>
  </EMAIL>
  <FN>{name}</FN>
  <ADR>
    <HOME/>
    <STREET>{homePostalAddress}</STREET>
    <PCODE>{homeZip}</PCODE>
    <CTRY>{co}</CTRY>
  </ADR>
  <ADR>
    <WORK/>
    <STREET>{streetAddress}</STREET>
    <LOCALITY>{l}</LOCALITY>
    <REGION>{st}</REGION>
    <PCODE>{postalCode}</PCODE>
    <CTRY>{co}</CTRY>
  </ADR>
  <TEL>
    <HOME/>
    <VOICE/>
    <NUMBER>{homePhone}</NUMBER>
  </TEL>
  <TEL>
    <HOME/>
    <CELL/>
    <NUMBER>{mobile}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <VOICE/>
    <NUMBER>{telephoneNumber}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <CELL/>
    <NUMBER>{mobile}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <FAX/>
    <NUMBER>{facsimileTelephoneNumber}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <PAGER/>
    <NUMBER>{pager}</NUMBER>
  </TEL>
  <TITLE>{title}</TITLE>
  <ORG>
    <ORGUNIT>{department}</ORGUNIT>
  </ORG>
</vCard>

Another thing. What's the case when people dial short extensions, say, in an office (ex: number is 222222XXX, people dial XXX, caller id will be XXX)? You would also not match them.

As it is the SIP server that controls call-info, why is it not enough to use it as glue? Maybe you could add that as an option (only use call-info to match CUSAX).

Thanks,
Ricardo

From: emcho@jitsi.org
Date: Wed, 29 Jan 2014 17:16:22 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

On Wed, Jan 29, 2014 at 5:13 PM, Ricardo Duarte <rjtd21@hotmail.com> wrote:
> Hi Emil,
>
> I can see I don't have anything on the "Phone:" field of the vcard, but only
> on the Extended tab as Work Phone. Maybe that could be the problem.

Work phone should also work.

> Can you describe the match that you do?
> Is it something like <sip address before the @> == Phone on vcard ? Other?

Currently it's an exact match with the *entire* URI and not just the
user part. Could this be the issue? Yana should commit a "contains"
comparison in a few minutes.

Emil
>
> Thanks,
> Ricardo
>
>> From: emcho@jitsi.org
>> Date: Wed, 29 Jan 2014 16:40:57 +0100
>
>> To: users@jitsi.org
>> Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching
>>
>> Hey Ricardo,
>>
>> On Wed, Jan 29, 2014 at 4:34 PM, Ricardo Duarte <rjtd21@hotmail.com> > >> wrote:
>> > Hi,
>> >
>> > The "From" is the SIP user identifier, as it's not XMPP that is doing
>> > the
>> > call, but SIP.
>>
>> Yes, I got that. That's how CUSAX works.
>>
>> > And I guess the glue between both XMPP and SIP is the Call-Info field.
>>
>> That's what I am trying to say. It is not *only* the Call-Info.
>> There's a second verification against the XMPP vcard. Absent that
>> verification, it would be very easy for me to call you and pretend
>> that I am your banker.
>>
>> > So, in this case:
>> >
>> > From: USEREXTENSION@192.168.1.1
>> > Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp
>> >
>> > PS.: USEREXTENSION actually matches user phone on vcard.
>>
>> OK, that's what I needed to know. Does it appear in the exact same
>> format? That is, is it a perfect match of the entire URI? Or maybe
>> just the user part of the URI? I think that something is most likely
>> blocking there. We just need to find out exactly what it is and then
>> decide where to fix it.
>>
>> Emil
>>
>>
>> >
>> > Regards,
>> > Ricardo
>> >
>> >> From: emcho@jitsi.org
>> >> Date: Wed, 29 Jan 2014 16:00:29 +0100
>> >
>> >> To: users@jitsi.org
>> >> Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching
>> >>
>> >> Hey Ricardo,
>> >>
>> >> On Wed, Jan 29, 2014 at 3:55 PM, Ricardo Duarte <rjtd21@hotmail.com> > >> >> wrote:
>> >> > Hi,
>> >> >Also, there is also a case of people calling extensions.
>> >> > My Call-Info is:
>> >> >
>> >> > Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp
>> >>
>> >> My questions was more about: what does the "From:" header in the above
>> >> INVITE contain? Is the URI from the "From" header present in the vcard
>> >> for the "xmpp:user@xmpp.mycompany.local" contact ?
>> >>
>> >> --
>> >> https://jitsi.org
>> >>
>> >> _______________________________________________
>> >> users mailing list
>> >> users@jitsi.org
>> >> Unsubscribe instructions and other list options:
>> >> http://lists.jitsi.org/mailman/listinfo/users
>> >
>> > _______________________________________________
>> > users mailing list
>> > users@jitsi.org
>> > Unsubscribe instructions and other list options:
>> > http://lists.jitsi.org/mailman/listinfo/users
>>
>>
>>
>> --
>> Emil Ivov, Ph.D. 67000 Strasbourg,
>> Project Lead France
>> Jitsi
>> emcho@jitsi.org PHONE: +33.1.77.62.43.30
>> https://jitsi.org FAX: +33.1.77.62.47.31
>>
>> _______________________________________________
>> users mailing list
>> users@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/users
>
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#20

Great progress! The findings are weird though ... I don't see how the
presence op set could possibly be null for the XMPP account. Not being
able to find the XMPP account would have made more sense and would
have suggested a problem with provisioning, but if that was the case,
cusaxProvider would have been null. So it's very weird that we
actually have one but it doesn't have a presence op set (it's weird
because we never turn off presence for xmpp).

Could you please try to print debug info on "cusaxProvider" there and
see what it points to?

Emil

···

On Thu, Jan 30, 2014 at 12:06 PM, Ricardo Duarte <rjtd21@hotmail.com> wrote:

Hi,

Made some further debug and my findings are the following:

imppAddress is being read properly from the SIP INVITE.
getPeerContact is called, but returns null.
The null is due to presenceOpSet being null.

private static Contact getPeerContact( CallPeer callPeer,
                                ProtocolProviderService cusaxProvider,
                                String alternativePeerAddress)
{
OperationSetPresence presenceOpSet
   = cusaxProvider.getOperationSet(OperationSetPresence.class);

if (presenceOpSet == null) {
           return null;
}

(...)

Regards,
Ricardo

________________________________
From: rjtd21@hotmail.com
To: users@jitsi.org
Date: Thu, 30 Jan 2014 10:22:19 +0000

Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hi,

I changed the function doesDetailBelong to always return true (looks like it
would then ignore the telephone number check), but still no match is made.

Regards,
Ricardo

________________________________
From: rjtd21@hotmail.com
To: users@jitsi.org
Date: Wed, 29 Jan 2014 16:24:32 +0000
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hi,

Can you provide me a small example of the kind of vcard you require, and
where the match is made?
I can quickly change that on my XMPP server and test.
This is mine (so, I only have tags for real telephone numbers):

<vCard xmlns="vcard-temp">
  <N>
    <GIVEN>{displayName}</GIVEN>
  </N>
  <EMAIL>
    <INTERNET/>
    <USERID>{mail}</USERID>
  </EMAIL>
  <FN>{name}</FN>
  <ADR>
    <HOME/>
    <STREET>{homePostalAddress}</STREET>
    <PCODE>{homeZip}</PCODE>
    <CTRY>{co}</CTRY>
  </ADR>
  <ADR>
    <WORK/>
    <STREET>{streetAddress}</STREET>
    <LOCALITY>{l}</LOCALITY>
    <REGION>{st}</REGION>
    <PCODE>{postalCode}</PCODE>
    <CTRY>{co}</CTRY>
  </ADR>
  <TEL>
    <HOME/>
    <VOICE/>
    <NUMBER>{homePhone}</NUMBER>
  </TEL>
  <TEL>
    <HOME/>
    <CELL/>
    <NUMBER>{mobile}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <VOICE/>
    <NUMBER>{telephoneNumber}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <CELL/>
    <NUMBER>{mobile}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <FAX/>
    <NUMBER>{facsimileTelephoneNumber}</NUMBER>
  </TEL>
  <TEL>
    <WORK/>
    <PAGER/>
    <NUMBER>{pager}</NUMBER>
  </TEL>
  <TITLE>{title}</TITLE>
  <ORG>
    <ORGUNIT>{department}</ORGUNIT>
  </ORG>
</vCard>

Another thing. What's the case when people dial short extensions, say, in an
office (ex: number is 222222XXX, people dial XXX, caller id will be XXX)?
You would also not match them.

As it is the SIP server that controls call-info, why is it not enough to use
it as glue? Maybe you could add that as an option (only use call-info to
match CUSAX).

Thanks,
Ricardo

From: emcho@jitsi.org
Date: Wed, 29 Jan 2014 17:16:22 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

On Wed, Jan 29, 2014 at 5:13 PM, Ricardo Duarte <rjtd21@hotmail.com> >> wrote:
> Hi Emil,
>
> I can see I don't have anything on the "Phone:" field of the vcard, but
> only
> on the Extended tab as Work Phone. Maybe that could be the problem.

Work phone should also work.

> Can you describe the match that you do?
> Is it something like <sip address before the @> == Phone on vcard ?
> Other?

Currently it's an exact match with the *entire* URI and not just the
user part. Could this be the issue? Yana should commit a "contains"
comparison in a few minutes.

Emil
>
> Thanks,
> Ricardo
>
>> From: emcho@jitsi.org
>> Date: Wed, 29 Jan 2014 16:40:57 +0100
>
>> To: users@jitsi.org
>> Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching
>>
>> Hey Ricardo,
>>
>> On Wed, Jan 29, 2014 at 4:34 PM, Ricardo Duarte <rjtd21@hotmail.com> >> >> wrote:
>> > Hi,
>> >
>> > The "From" is the SIP user identifier, as it's not XMPP that is doing
>> > the
>> > call, but SIP.
>>
>> Yes, I got that. That's how CUSAX works.
>>
>> > And I guess the glue between both XMPP and SIP is the Call-Info
>> > field.
>>
>> That's what I am trying to say. It is not *only* the Call-Info.
>> There's a second verification against the XMPP vcard. Absent that
>> verification, it would be very easy for me to call you and pretend
>> that I am your banker.
>>
>> > So, in this case:
>> >
>> > From: USEREXTENSION@192.168.1.1
>> > Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp
>> >
>> > PS.: USEREXTENSION actually matches user phone on vcard.
>>
>> OK, that's what I needed to know. Does it appear in the exact same
>> format? That is, is it a perfect match of the entire URI? Or maybe
>> just the user part of the URI? I think that something is most likely
>> blocking there. We just need to find out exactly what it is and then
>> decide where to fix it.
>>
>> Emil
>>
>>
>> >
>> > Regards,
>> > Ricardo
>> >
>> >> From: emcho@jitsi.org
>> >> Date: Wed, 29 Jan 2014 16:00:29 +0100
>> >
>> >> To: users@jitsi.org
>> >> Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching
>> >>
>> >> Hey Ricardo,
>> >>
>> >> On Wed, Jan 29, 2014 at 3:55 PM, Ricardo Duarte <rjtd21@hotmail.com> >> >> >> wrote:
>> >> > Hi,
>> >> >Also, there is also a case of people calling extensions.
>> >> > My Call-Info is:
>> >> >
>> >> > Call-Info: <xmpp:user@xmpp.mycompany.local> ;purpose=impp
>> >>
>> >> My questions was more about: what does the "From:" header in the
>> >> above
>> >> INVITE contain? Is the URI from the "From" header present in the
>> >> vcard
>> >> for the "xmpp:user@xmpp.mycompany.local" contact ?
>> >>
>> >> --
>> >> https://jitsi.org
>> >>
>> >> _______________________________________________
>> >> users mailing list
>> >> users@jitsi.org
>> >> Unsubscribe instructions and other list options:
>> >> http://lists.jitsi.org/mailman/listinfo/users
>> >
>> > _______________________________________________
>> > users mailing list
>> > users@jitsi.org
>> > Unsubscribe instructions and other list options:
>> > http://lists.jitsi.org/mailman/listinfo/users
>>
>>
>>
>> --
>> Emil Ivov, Ph.D. 67000 Strasbourg,
>> Project Lead France
>> Jitsi
>> emcho@jitsi.org PHONE: +33.1.77.62.43.30
>> https://jitsi.org FAX: +33.1.77.62.47.31
>>
>> _______________________________________________
>> users mailing list
>> users@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/users
>
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________ users mailing list
users@jitsi.org Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________ users mailing list
users@jitsi.org Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31