[jitsi-users] CUSAX Incoming Contact Matching

Hi Emil,
Setting IS_PRESENCE_ENABLED=true for the SIP account makes it proceed, and presenceOpSet is no longer null.But then, findContactByID still does not find the contact.I can see the function being called for the imppAddress (without the protocol part).
-> contactsIter.hasNext() is false-> groupsIter.hasNext() is also false-> findContactByID returns null

    public ContactSipImpl findContactByID(String id) { (...) while(contactsIter.hasNext()) { ContactSipImpl mContact = (ContactSipImpl)contactsIter.next(); System.out.print ("--- address-> " + mContact.getAddress() + " ---\n");
            if( mContact.getAddress().equals(id) ) return mContact; }
        //if we didn't find it here, let's try in the subgroups Iterator<ContactGroup> groupsIter = subgroups();
        while( groupsIter.hasNext() ) { System.out.print ("--- groupsIter ---\n"); ContactGroupSipImpl mGroup = (ContactGroupSipImpl)groupsIter.next();
            ContactSipImpl mContact = mGroup.findContactByID(id);
            if (mContact != null) return mContact; }

Regards,Ricardo

···

From: emcho@jitsi.org
Date: Thu, 30 Jan 2014 12:14:30 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

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

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

Hey Ricardo,

I can't look into the code right now but I'll try to give you a few
pointers. Please excuse the vagueness.

Hi Emil,

Setting IS_PRESENCE_ENABLED=true for the SIP account makes it proceed, and
presenceOpSet is no longer null.

This is NOT the right way to go. When using CUSAX, the presence for
your SIP provider MUST be disabled or otherwise you are not doing
CUSAX at all.

In my previous mail I tried to explain that the "cusaxProvider"
reference should be pointing to the XMPP account. That's where
presence information MUST come from if you want CUSAX to work. It is
strange that the presence op set there is NULL because we never really
disable it. That's why I was asking if you could print more details on
the "cusaxProvider" in the above and see what it really points to.

Emil

···

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

But then, findContactByID still does not find the contact.
I can see the function being called for the imppAddress (without the
protocol part).

-> contactsIter.hasNext() is false
-> groupsIter.hasNext() is also false
-> findContactByID returns null

    public ContactSipImpl findContactByID(String id)
    {
    (...)
        while(contactsIter.hasNext())
        {
            ContactSipImpl mContact = (ContactSipImpl)contactsIter.next();
            System.out.print ("--- address-> " + mContact.getAddress() + "
---\n");

            if( mContact.getAddress().equals(id) )
                return mContact;
        }

        //if we didn't find it here, let's try in the subgroups
        Iterator<ContactGroup> groupsIter = subgroups();

        while( groupsIter.hasNext() )
        {
                 System.out.print ("--- groupsIter ---\n");
            ContactGroupSipImpl mGroup =
(ContactGroupSipImpl)groupsIter.next();

            ContactSipImpl mContact = mGroup.findContactByID(id);

            if (mContact != null)
                return mContact;
        }

Regards,
Ricardo

From: emcho@jitsi.org
Date: Thu, 30 Jan 2014 12:14:30 +0100

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

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

_______________________________________________
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

Hi Ricardo,

I've found a glitch in the cusax implementation, which may be related to your issues. Could you please try the attached patch and tell me how it works for you?

Cheers,
Yana

jitsi-cusax.patch (14.2 KB)

Hi Yana,
Can you please tell me against what code version should I apply the patch?It does not apply cleanly to github master or 2.4 latest src.
Regards,
Ricardo

···

From: yana@jitsi.org
Date: Thu, 30 Jan 2014 13:28:17 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hi Ricardo,

I've found a glitch in the cusax implementation, which may be related to your issues. Could you please try the attached patch and tell me how it works for you?

Cheers,
Yana

On 30 Jan 2014, at 12:24, Ricardo Duarte wrote:

Hi Emil,

Setting IS_PRESENCE_ENABLED=true for the SIP account makes it proceed, and presenceOpSet is no longer null.
But then, findContactByID still does not find the contact.
I can see the function being called for the imppAddress (without the protocol part).

-> contactsIter.hasNext() is false
-> groupsIter.hasNext() is also false
-> findContactByID returns null

    public ContactSipImpl findContactByID(String id)
    {
    (...)
        while(contactsIter.hasNext())
        {
            ContactSipImpl mContact = (ContactSipImpl)contactsIter.next();
            System.out.print ("--- address-> " + mContact.getAddress() + " ---\n");

            if( mContact.getAddress().equals(id) )
                return mContact;
        }

        //if we didn't find it here, let's try in the subgroups
        Iterator groupsIter = subgroups();

        while( groupsIter.hasNext() )
        {
                 System.out.print ("--- groupsIter ---\n");
            ContactGroupSipImpl mGroup = (ContactGroupSipImpl)groupsIter.next();

            ContactSipImpl mContact = mGroup.findContactByID(id);

            if (mContact != null)
                return mContact;
        }

Regards,
Ricardo

> From: emcho@jitsi.org
> Date: Thu, 30 Jan 2014 12:14:30 +0100
> To: users@jitsi.org
> Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching
>
> 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 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):
> >
> >
> >
> > {displayName}
> >
> >
> >
> > {mail}
> >
> > {name}
> >
> >
> > {homePostalAddress}
> > {homeZip}
> > {co}
> >
> >
> >
> > {streetAddress}
> > {l}
> > {st}
> > {postalCode}
> > {co}
> >
> >
> >
> >
> > {homePhone}
> >
> >
> >
> >
> > {mobile}
> >
> >
> >
> >
> > {telephoneNumber}
> >
> >
> >
> >
> > {mobile}
> >
> >
> >
> >
> > {facsimileTelephoneNumber}
> >
> >
> >
> >
> > {pager}
> >
> > {title}
> >
> > {department}
> >
> >
> >
> >
> > 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 > > >> 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 == 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 > > >> >> 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: ;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 > > >> >> >> wrote:
> >> >> >> > Hi,
> >> >> >> >Also, there is also a case of people calling extensions.
> >> >> >> > My Call-Info is:
> >> >> >> >
> >> >> >> > Call-Info: ;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
>
> _______________________________________________
> 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

Hi Ricardo,

Sorry about that. Could you please that one?

Cheers,
Yana

p.s. I'm creating the patch with Eclipse, so if it doesn't work you may want to check the paths inside the diff.

jitsi.patch (13.8 KB)

Hi Yana,

Unfortunately your patch is not applying cleanly.
Some failed hunks and "patch unexpectedly ends in middle of line".

Regards,
Ricardo

···

From: yana@jitsi.org
Date: Thu, 30 Jan 2014 14:47:56 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hi Ricardo,

Sorry about that. Could you please that one?

Cheers,
Yana

p.s. I'm creating the patch with Eclipse, so if it doesn't work you may want to check the paths inside the diff.

On 30 Jan 2014, at 13:45, Ricardo Duarte wrote:

Hi Yana,

Can you please tell me against what code version should I apply the patch?
It does not apply cleanly to github master or 2.4 latest src.

Regards,
Ricardo

From: yana@jitsi.org
Date: Thu, 30 Jan 2014 13:28:17 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hi Ricardo,

I've found a glitch in the cusax implementation, which may be related to your issues. Could you please try the attached patch and tell me how it works for you?

Cheers,
Yana

On 30 Jan 2014, at 12:24, Ricardo Duarte wrote: > Hi Emil, > > Setting IS_PRESENCE_ENABLED=true for the SIP account makes it proceed, and presenceOpSet is no longer null. > But then, findContactByID still does not find the contact. > I can see the function being called for the imppAddress (without the protocol part). > > -> contactsIter.hasNext() is false > -> groupsIter.hasNext() is also false > -> findContactByID returns null > > > > public ContactSipImpl findContactByID(String id) > { > (...) > while(contactsIter.hasNext()) > { > ContactSipImpl mContact = (ContactSipImpl)contactsIter.next(); > System.out.print ("--- address-> " + mContact.getAddress() + " ---\n"); > > if( mContact.getAddress().equals(id) ) > return mContact; > } > > //if we didn't find it here, let's try in the subgroups > Iterator groupsIter = subgroups(); > > while( groupsIter.hasNext() ) > { > System.out.print ("--- groupsIter ---\n"); > ContactGroupSipImpl mGroup = (ContactGroupSipImpl)groupsIter.next(); > > ContactSipImpl mContact = mGroup.findContactByID(id); > > if (mContact != null) > return mContact; > } > > > Regards, > Ricardo > > > > > From:emcho@jitsi.org > > Date: Thu, 30 Jan 2014 12:14:30 +0100 > > To: users@jitsi.org > > Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching > > > > 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 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): > > > > > > > > > > > > {displayName} > > > > > > > > > > > > {mail} > > > > > > {name} > > > > > > > > > {homePostalAddress} > > > {homeZip} > > > {co} > > > > > > > > > > > > {streetAddress} > > > {l} > > > {st} > > > {postalCode} > > > {co} > > > > > > > > > > > > > > > {homePhone} > > > > > > > > > > > > > > > {mobile} > > > > > > > > > > > > > > > {telephoneNumber} > > > > > > > > > > > > > > > {mobile} > > > > > > > > > > > > > > > {facsimileTelephoneNumber} > > > > > > > > > > > > > > > {pager} > > > > > > > > > > > > {department} > > > > > > > > > > > > > > > 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 > > >> 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 == 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 > > >> >> 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: ;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 > > >> >> >> wrote: > > >> >> >> > Hi, > > >> >> >> >Also, there is also a case of people calling extensions. > > >> >> >> > My Call-Info is: > > >> >> >> > > > >> >> >> > Call-Info: ;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 > > > > _______________________________________________ > > 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

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

Yana, we could maybe push that into a branch? Should make things easier.

--sent from my mobile

···

On 31 Jan 2014 11:33 AM, "Ricardo Duarte" <rjtd21@hotmail.com> wrote:

Hi Yana,

Unfortunately your patch is not applying cleanly.
Some failed hunks and "patch unexpectedly ends in middle of line".

Regards,
Ricardo

From: yana@jitsi.org
Date: Thu, 30 Jan 2014 14:47:56 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hi Ricardo,

Sorry about that. Could you please that one?

Cheers,
Yana

p.s. I'm creating the patch with Eclipse, so if it doesn't work you may want to check the paths inside the diff.

On 30 Jan 2014, at 13:45, Ricardo Duarte wrote: > Hi Yana, > > Can you
please tell me against what code version should I apply the patch? > It
does not apply cleanly to github master or 2.4 latest src. > > Regards, >
Ricardo > > > From: yana@jitsi.org > Date: Thu, 30 Jan 2014 13:28:17
+0100 > To: users@jitsi.org > Subject: Re: [jitsi-users] CUSAX Incoming
Contact Matching > > Hi Ricardo, > > I've found a glitch in the cusax
implementation, which may be related to your issues. Could you please try
the attached patch and tell me how it works for you? > > Cheers, > Yana > >
> On 30 Jan 2014, at 12:24, Ricardo Duarte wrote: > Hi Emil, > > Setting
IS_PRESENCE_ENABLED=true for the SIP account makes it proceed, and
presenceOpSet is no longer null. > But then, findContactByID still does not
find the contact. > I can see the function being called for the imppAddress
(without the protocol part). > > -> contactsIter.hasNext() is false > ->
groupsIter.hasNext() is also false > -> findContactByID returns null > > >
> public ContactSipImpl findContactByID(String id) > { > (...) >
while(contactsIter.hasNext()) > { > ContactSipImpl mContact =
(ContactSipImpl)contactsIter.next(); > System.out.print ("--- address-> " +
mContact.getAddress() + " ---\n"); > > if( mContact.getAddress().equals(id)
) > return mContact; > } > > //if we didn't find it here, let's try in the
subgroups > Iterator groupsIter = subgroups(); > > while(
groupsIter.hasNext() ) > { > System.out.print ("--- groupsIter ---\n"); >
ContactGroupSipImpl mGroup = (ContactGroupSipImpl)groupsIter.next(); > >
ContactSipImpl mContact = mGroup.findContactByID(id); > > if (mContact !=
null) > return mContact; > } > > > Regards, > Ricardo > > > > >
From:emcho@jitsi.org > > Date: Thu, 30 Jan 2014 12:14:30 +0100 > > To:
users@jitsi.org > > Subject: Re: [jitsi-users] CUSAX Incoming Contact
Matching > > > > 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 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): > > > > > >
> > > > > > {displayName} > > > > > > > > > > > > {mail} > > > > > > {name}
> > > > > > > > > {homePostalAddress} > > > {homeZip} > > > {co} > > > > >
> > > > > > > {streetAddress} > > > {l} > > > {st} > > > {postalCode} > > >
{co} > > > > > > > > > > > > > > > {homePhone} > > > > > > > > > > > > > >
> {mobile} > > > > > > > > > > > > > > > {telephoneNumber} > > > > > > > >
> > > > > > > {mobile} > > > > > > > > > > > > > > >
{facsimileTelephoneNumber} > > > > > > > > > > > > > > > {pager} > > > > >
> > > > > > > {department} > > > > > > > > > > > > > > > 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 > > >> 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 == 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 > > >> >> 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:
;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 > > >> >> >> wrote: > > >> >> >> > Hi, > > >> >> >> >Also, there is
also a case of people calling extensions. > > >> >> >> > My Call-Info is: >
> >> >> >> > > > >> >> >> > Call-Info: ;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.orgFAX: +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
_______________________________________________ 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

Yana, we could maybe push that into a branch? Should make things easier.

Yes, I'll do that today.

Ricardo, sorry for the lag, many of us were at Fosdem for the last few
days. I'll let you know as soon as I'm done with the branch.

Cheers,
Yana

--sent from my mobile

Hi Yana,

Unfortunately your patch is not applying cleanly.
Some failed hunks and "patch unexpectedly ends in middle of line".

Regards,
Ricardo

From: yana@jitsi.org
Date: Thu, 30 Jan 2014 14:47:56 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hi Ricardo,

Sorry about that. Could you please that one?

Cheers,
Yana

p.s. I'm creating the patch with Eclipse, so if it doesn't work you may

want to check the paths inside the diff.

On 30 Jan 2014, at 13:45, Ricardo Duarte wrote: > Hi Yana, > > Can you

please tell me against what code version should I apply the patch? > It
does not apply cleanly to github master or 2.4 latest src. > > Regards, >
Ricardo > > > From: yana@jitsi.org > Date: Thu, 30 Jan 2014 13:28:17 +0100

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

Matching > > Hi Ricardo, > > I've found a glitch in the cusax
implementation, which may be related to your issues. Could you please try
the attached patch and tell me how it works for you? > > Cheers, > Yana > >

On 30 Jan 2014, at 12:24, Ricardo Duarte wrote: > Hi Emil, > > Setting

IS_PRESENCE_ENABLED=true for the SIP account makes it proceed, and
presenceOpSet is no longer null. > But then, findContactByID still does not
find the contact. > I can see the function being called for the imppAddress
(without the protocol part). > > -> contactsIter.hasNext() is false > ->
groupsIter.hasNext() is also false > -> findContactByID returns null > > >

public ContactSipImpl findContactByID(String id) > { > (...) >

while(contactsIter.hasNext()) > { > ContactSipImpl mContact =
(ContactSipImpl)contactsIter.next(); > System.out.print ("--- address-> " +
mContact.getAddress() + " ---\n"); > > if( mContact.getAddress().equals(id)
) > return mContact; > } > > //if we didn't find it here, let's try in the
subgroups > Iterator groupsIter = subgroups(); > > while(
groupsIter.hasNext() ) > { > System.out.print ("--- groupsIter ---\n"); >
ContactGroupSipImpl mGroup = (ContactGroupSipImpl)groupsIter.next(); > >
ContactSipImpl mContact = mGroup.findContactByID(id); > > if (mContact !=
null) > return mContact; > } > > > Regards, > Ricardo > > > > >
users@jitsi.org > > Subject: Re: [jitsi-users] CUSAX Incoming Contact
Matching > > > > 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 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): > > > > > >

> > > > > {displayName} > > > > > > > > > > > > {mail} > > > > > > {name}
> > > > > > > > {homePostalAddress} > > > {homeZip} > > > {co} > > > > >
> > > > > > {streetAddress} > > > {l} > > > {st} > > > {postalCode} > > >

{co} > > > > > > > > > > > > > > > {homePhone} > > > > > > > > > > > > > >

{mobile} > > > > > > > > > > > > > > > {telephoneNumber} > > > > > > > >
> > > > > > {mobile} > > > > > > > > > > > > > > >

{facsimileTelephoneNumber} > > > > > > > > > > > > > > > {pager} > > > > >

> > > > > > {department} > > > > > > > > > > > > > > > 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 > > >>

Wed, Jan 29, 2014 at 5:13 PM, Ricardo Duarte > > >> 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 == 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 > > >> >> 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:

;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 > >

>> > > > >> >> >>

Contact Matching > > >> >> >> > > >> >> >> Hey Ricardo, > > >> >> >> > > >>

>> >> >> > Hi, > > >> >> >> >Also, there is also a case of people calling

extensions. > > >> >> >> > My Call-Info is: > > >> >> >> > > > >> >> >> >
Call-Info: ;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 > > > > _______________________________________________ >

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

_______________________________________________ users mailing list

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

···

On Feb 2, 2014 9:10 PM, "Emil Ivov" <emcho@jitsi.org> wrote:

On 31 Jan 2014 11:33 AM, "Ricardo Duarte" <rjtd21@hotmail.com> wrote:

From:emcho@jitsi.org > > Date: Thu, 30 Jan 2014 12:14:30 +0100 > > To:
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching > > >> > > >> On
To:users@jitsi.org > > >> >> >> Subject: Re: [jitsi-users] CUSAX Incoming

>> On Wed, Jan 29, 2014 at 3:55 PM, Ricardo Duarte > > >> >> >> wrote: >

_______________________________________________
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

Hi Ricardo,

The fix I've provided is now in a separate branch. Please check: https://github.com/jitsi/jitsi/tree/cusax-fix .

Let me know how this works for you.

Thanks!
Yana

···

On 03 Feb 2014, at 11:23, Yana Stamcheva <yana@jitsi.org> wrote:

On Feb 2, 2014 9:10 PM, "Emil Ivov" <emcho@jitsi.org> wrote:
>
> Yana, we could maybe push that into a branch? Should make things easier.
>

Yes, I'll do that today.

Ricardo, sorry for the lag, many of us were at Fosdem for the last few days. I'll let you know as soon as I'm done with the branch.

Cheers,
Yana

> --sent from my mobile
>
> On 31 Jan 2014 11:33 AM, "Ricardo Duarte" <rjtd21@hotmail.com> wrote:
>>
>> Hi Yana,
>>
>> Unfortunately your patch is not applying cleanly.
>> Some failed hunks and "patch unexpectedly ends in middle of line".
>>
>> Regards,
>> Ricardo
>>
>>
>> From: yana@jitsi.org
>> Date: Thu, 30 Jan 2014 14:47:56 +0100
>> To: users@jitsi.org
>> Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching
>>
>> Hi Ricardo,
>>
>> Sorry about that. Could you please that one?
>>
>>
>> Cheers,
>> Yana
>>
>> p.s. I'm creating the patch with Eclipse, so if it doesn't work you may want to check the paths inside the diff.
>>
>>
>>
>> On 30 Jan 2014, at 13:45, Ricardo Duarte wrote: > Hi Yana, > > Can you please tell me against what code version should I apply the patch? > It does not apply cleanly to github master or 2.4 latest src. > > Regards, > Ricardo > > > From: yana@jitsi.org > Date: Thu, 30 Jan 2014 13:28:17 +0100 > To: users@jitsi.org > Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching > > Hi Ricardo, > > I've found a glitch in the cusax implementation, which may be related to your issues. Could you please try the attached patch and tell me how it works for you? > > Cheers, > Yana > > > On 30 Jan 2014, at 12:24, Ricardo Duarte wrote: > Hi Emil, > > Setting IS_PRESENCE_ENABLED=true for the SIP account makes it proceed, and presenceOpSet is no longer null. > But then, findContactByID still does not find the contact. > I can see the function being called for the imppAddress (without the protocol part). > > -> contactsIter.hasNext() is false > -> groupsIter.hasNext() is also false > -> findContactByID returns null > > > > public ContactSipImpl findContactByID(String id) > { > (...) > while(contactsIter.hasNext()) > { > ContactSipImpl mContact = (ContactSipImpl)contactsIter.next(); > System.out.print ("--- address-> " + mContact.getAddress() + " ---\n"); > > if( mContact.getAddress().equals(id) ) > return mContact; > } > > //if we didn't find it here, let's try in the subgroups > Iterator groupsIter = subgroups(); > > while( groupsIter.hasNext() ) > { > System.out.print ("--- groupsIter ---\n"); > ContactGroupSipImpl mGroup = (ContactGroupSipImpl)groupsIter.next(); > > ContactSipImpl mContact = mGroup.findContactByID(id); > > if (mContact != null) > return mContact; > } > > > Regards, > Ricardo > > > > > From:emcho@jitsi.org > > Date: Thu, 30 Jan 2014 12:14:30 +0100 > > To: users@jitsi.org > > Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching > > > > 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 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): > > > > > > > > > > > > {displayName} > > > > > > > > > > > > {mail} > > > > > > {name} > > > > > > > > > {homePostalAddress} > > > {homeZip} > > > {co} > > > > > > > > > > > > {streetAddress} > > > {l} > > > {st} > > > {postalCode} > > > {co} > > > > > > > > > > > > > > > {homePhone} > > > > > > > > > > > > > > > {mobile} > > > > > > > > > > > > > > > {telephoneNumber} > > > > > > > > > > > > > > > {mobile} > > > > > > > > > > > > > > > {facsimileTelephoneNumber} > > > > > > > > > > > > > > > {pager} > > > > > > > > > > > > {department} > > > > > > > > > > > > > > > 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 > > >> 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 == 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 > > >> >> 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: ;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 > > >> >> >> wrote: > > >> >> >> > Hi, > > >> >> >> >Also, there is also a case of people calling extensions. > > >> >> >> > My Call-Info is: > > >> >> >> > > > >> >> >> > Call-Info: ;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 > > > > _______________________________________________ > > 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
>> _______________________________________________ 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

Hi Yana,
CUSAX functionality now works perfectly. I can match calls to chat windows and users.
But I still have one problem.At my place we use two kinds of numbers: DDI and internal "short" extension. My users have the DDI on they contact card, but when they call from internal phones the short number is used. In this situation, a match is never possible on Jitsi/CUSAX.Why not just match by Call-info, or make it optional?
Thanks,Ricardo

···

From: yana@jitsi.org
Date: Mon, 3 Feb 2014 16:31:36 +0100
To: users@jitsi.org
Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching

Hi Ricardo,

The fix I've provided is now in a separate branch. Please check: https://github.com/jitsi/jitsi/tree/cusax-fix .

Let me know how this works for you.

Thanks!
Yana

On 03 Feb 2014, at 11:23, Yana Stamcheva <yana@jitsi.org> wrote:

>
> On Feb 2, 2014 9:10 PM, "Emil Ivov" <emcho@jitsi.org> wrote:
> >
> > Yana, we could maybe push that into a branch? Should make things easier.
> >
>
> Yes, I'll do that today.
>
> Ricardo, sorry for the lag, many of us were at Fosdem for the last few days. I'll let you know as soon as I'm done with the branch.
>
> Cheers,
> Yana
>
> > --sent from my mobile
> >
> > On 31 Jan 2014 11:33 AM, "Ricardo Duarte" <rjtd21@hotmail.com> wrote:
> >>
> >> Hi Yana,
> >>
> >> Unfortunately your patch is not applying cleanly.
> >> Some failed hunks and "patch unexpectedly ends in middle of line".
> >>
> >> Regards,
> >> Ricardo
> >>
> >>
> >> From: yana@jitsi.org
> >> Date: Thu, 30 Jan 2014 14:47:56 +0100
> >> To: users@jitsi.org
> >> Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching
> >>
> >> Hi Ricardo,
> >>
> >> Sorry about that. Could you please that one?
> >>
> >>
> >> Cheers,
> >> Yana
> >>
> >> p.s. I'm creating the patch with Eclipse, so if it doesn't work you may want to check the paths inside the diff.
> >>
> >>
> >>
> >> On 30 Jan 2014, at 13:45, Ricardo Duarte wrote: > Hi Yana, > > Can you please tell me against what code version should I apply the patch? > It does not apply cleanly to github master or 2.4 latest src. > > Regards, > Ricardo > > > From: yana@jitsi.org > Date: Thu, 30 Jan 2014 13:28:17 +0100 > To: users@jitsi.org > Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching > > Hi Ricardo, > > I've found a glitch in the cusax implementation, which may be related to your issues. Could you please try the attached patch and tell me how it works for you? > > Cheers, > Yana > > > On 30 Jan 2014, at 12:24, Ricardo Duarte wrote: > Hi Emil, > > Setting IS_PRESENCE_ENABLED=true for the SIP account makes it proceed, and presenceOpSet is no longer null. > But then, findContactByID still does not find the contact. > I can see the function being called for the imppAddress (without the protocol part). > > -> contactsIter.hasNext() is false > -> groupsIter.hasNext() is also false > -> findContactByID returns null > > > > public ContactSipImpl findContactByID(String id) > { > (...) > while(contactsIter.hasNext()) > { > ContactSipImpl mContact = (ContactSipImpl)contactsIter.next(); > System.out.print ("--- address-> " + mContact.getAddress() + " ---\n"); > > if( mContact.getAddress().equals(id) ) > return mContact; > } > > //if we didn't find it here, let's try in the subgroups > Iterator groupsIter = subgroups(); > > while( groupsIter.hasNext() ) > { > System.out.print ("--- groupsIter ---\n"); > ContactGroupSipImpl mGroup = (ContactGroupSipImpl)groupsIter.next(); > > ContactSipImpl mContact = mGroup.findContactByID(id); > > if (mContact != null) > return mContact; > } > > > Regards, > Ricardo > > > > > From:emcho@jitsi.org > > Date: Thu, 30 Jan 2014 12:14:30 +0100 > > To: users@jitsi.org > > Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching > > > > 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 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): > > > > > > > > > > > > {displayName} > > > > > > > > > > > > {mail} > > > > > > {name} > > > > > > > > > {homePostalAddress} > > > {homeZip} > > > {co} > > > > > > > > > > > > {streetAddress} > > > {l} > > > {st} > > > {postalCode} > > > {co} > > > > > > > > > > > > > > > {homePhone} > > > > > > > > > > > > > > > {mobile} > > > > > > > > > > > > > > > {telephoneNumber} > > > > > > > > > > > > > > > {mobile} > > > > > > > > > > > > > > > {facsimileTelephoneNumber} > > > > > > > > > > > > > > > {pager} > > > > > > > > > > > > {department} > > > > > > > > > > > > > > > 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 > > >> 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 == 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 > > >> >> 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: ;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 > > >> >> >> wrote: > > >> >> >> > Hi, > > >> >> >> >Also, there is also a case of people calling extensions. > > >> >> >> > My Call-Info is: > > >> >> >> > > > >> >> >> > Call-Info: ;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 > > > > _______________________________________________ > > 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
> >> _______________________________________________ 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

Hey Ricardo,

Hi Yana,

CUSAX functionality now works perfectly. I can match calls to chat windows
and users.

But I still have one problem.
At my place we use two kinds of numbers: DDI and internal "short" extension.
My users have the DDI on they contact card, but when they call from internal
phones the short number is used. In this situation, a match is never
possible on Jitsi/CUSAX.

Entering the short extension in one of the other phone fields should
sort that out.

Why not just match by Call-info, or make it optional?

Because it introduces a very serious vulnerability making it very easy
to impersonate anyone on your contact list.

Emil

···

On Mon, Feb 3, 2014 at 11:17 PM, Ricardo Duarte <rjtd21@hotmail.com> wrote:

Thanks,
Ricardo

From: yana@jitsi.org
Date: Mon, 3 Feb 2014 16:31:36 +0100

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

Hi Ricardo,

The fix I've provided is now in a separate branch. Please check:
https://github.com/jitsi/jitsi/tree/cusax-fix .

Let me know how this works for you.

Thanks!
Yana

On 03 Feb 2014, at 11:23, Yana Stamcheva <yana@jitsi.org> wrote:

>
> On Feb 2, 2014 9:10 PM, "Emil Ivov" <emcho@jitsi.org> wrote:
> >
> > Yana, we could maybe push that into a branch? Should make things
> > easier.
> >
>
> Yes, I'll do that today.
>
> Ricardo, sorry for the lag, many of us were at Fosdem for the last few
> days. I'll let you know as soon as I'm done with the branch.
>
> Cheers,
> Yana
>
> > --sent from my mobile
> >
> > On 31 Jan 2014 11:33 AM, "Ricardo Duarte" <rjtd21@hotmail.com> wrote:
> >>
> >> Hi Yana,
> >>
> >> Unfortunately your patch is not applying cleanly.
> >> Some failed hunks and "patch unexpectedly ends in middle of line".
> >>
> >> Regards,
> >> Ricardo
> >>
> >>
> >> From: yana@jitsi.org
> >> Date: Thu, 30 Jan 2014 14:47:56 +0100
> >> To: users@jitsi.org
> >> Subject: Re: [jitsi-users] CUSAX Incoming Contact Matching
> >>
> >> Hi Ricardo,
> >>
> >> Sorry about that. Could you please that one?
> >>
> >>
> >> Cheers,
> >> Yana
> >>
> >> p.s. I'm creating the patch with Eclipse, so if it doesn't work you
> >> may want to check the paths inside the diff.
> >>
> >>
> >>
> >> On 30 Jan 2014, at 13:45, Ricardo Duarte wrote: > Hi Yana, > > Can
> >> you please tell me against what code version should I apply the patch? > It
> >> does not apply cleanly to github master or 2.4 latest src. > > Regards, >
> >> Ricardo > > > From: yana@jitsi.org > Date: Thu, 30 Jan 2014 13:28:17 +0100 >
> >> To: users@jitsi.org > Subject: Re: [jitsi-users] CUSAX Incoming Contact
> >> Matching > > Hi Ricardo, > > I've found a glitch in the cusax
> >> implementation, which may be related to your issues. Could you please try
> >> the attached patch and tell me how it works for you? > > Cheers, > Yana > >
> >> > On 30 Jan 2014, at 12:24, Ricardo Duarte wrote: > Hi Emil, > > Setting
> >> IS_PRESENCE_ENABLED=true for the SIP account makes it proceed, and
> >> presenceOpSet is no longer null. > But then, findContactByID still does not
> >> find the contact. > I can see the function being called for the imppAddress
> >> (without the protocol part). > > -> contactsIter.hasNext() is false > ->
> >> groupsIter.hasNext() is also false > -> findContactByID returns null > > > >
> >> public ContactSipImpl findContactByID(String id) > { > (...) >
> >> while(contactsIter.hasNext()) > { > ContactSipImpl mContact =
> >> (ContactSipImpl)contactsIter.next(); > System.out.print ("--- address-> " +
> >> mContact.getAddress() + " ---\n"); > > if( mContact.getAddress().equals(id)
> >> ) > return mContact; > } > > //if we didn't find it here, let's try in the
> >> subgroups > Iterator groupsIter = subgroups(); > > while(
> >> groupsIter.hasNext() ) > { > System.out.print ("--- groupsIter ---\n"); >
> >> ContactGroupSipImpl mGroup = (ContactGroupSipImpl)groupsIter.next(); > >
> >> ContactSipImpl mContact = mGroup.findContactByID(id); > > if (mContact !=
> >> null) > return mContact; > } > > > Regards, > Ricardo > > > > >
> >> From:emcho@jitsi.org > > Date: Thu, 30 Jan 2014 12:14:30 +0100 > > To:
> >> users@jitsi.org > > Subject: Re: [jitsi-users] CUSAX Incoming Contact
> >> Matching > > > > 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 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): > > > > > > > > > > > >
> >> {displayName} > > > > > > > > > > > > {mail} > > > > > > {name} > > > > > >
> >> > > > {homePostalAddress} > > > {homeZip} > > > {co} > > > > > > > > > > > >
> >> {streetAddress} > > > {l} > > > {st} > > > {postalCode} > > > {co} > > > > >
> >> > > > > > > > > > > {homePhone} > > > > > > > > > > > > > > > {mobile} > > >
> >> > > > > > > > > > > > > {telephoneNumber} > > > > > > > > > > > > > > >
> >> {mobile} > > > > > > > > > > > > > > > {facsimileTelephoneNumber} > > > > >
> >> > > > > > > > > > > {pager} > > > > > > > > > > > > {department} > > > > > >
> >> > > > > > > > > > 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 > > >> 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 == 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 > > >> >> 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: ;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 > > >> >> >> wrote: > > >> >> >> > Hi, > > >> >> >> >Also, there is
> >> also a case of people calling extensions. > > >> >> >> > My Call-Info is: >
> >> > >> >> >> > > > >> >> >> > Call-Info: ;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 > > > > _______________________________________________ >
> >> > 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
> >> _______________________________________________ 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

_______________________________________________
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