two dialogues withs the same contact

[532910]

I do not know how I achieved this or how to reproduce it. sip: address is exactly the same on both screens:

The messages are still on my phone and I have a root access so can do any checks.

[Viish]

The main reason this can happen is the following: You have configured 2 accounts on your device, so you have 2 chat rooms with this +79 correspondent (one with each account).

[532910]

The account the only one of course.

[Viish]

In this case you might have a parameter in the address of one of your chat rooms that causes the lib to think it's another address than the first chat room.

[532910]

Could you give an example of parameter you're talking about. How can I see it?

[Viish]

You can see it in the logs. For example gruu parameter.

[532910]

I just see same errors for both incoming messages in /data/data/org.linphone/files/linphone1.log:

2019-04-17 21:34:09:216 [linphone-android] ERROR java.lang.NullPointerException: Attempt to read from field 'int android.app.Fragment.mIndex' on a null object reference

2019-04-18 13:21:23:947 [linphone-android] ERROR java.lang.NullPointerException: Attempt to read from field 'int android.app.Fragment.mIndex' on a null object reference

[Viish]

There is no mIndex field in linphone-android app, at least in ours.

[532910]

I'm using Linphone from the GPlay, version 4.1, updated April 16.

[Viish]

This means it's a generic try/catch in the app that handles an Android exception. Don't worry about it.

[532910]

Anyway I see no parameters in the log. Should debug be switched on before?

[Viish]

No it should be enoough as-is. Enable debug logs and send logs after the start, we'll see each chat room address.

[532910]

OK, I can reproduce it now. Looks like it's due to different phone IPs.

peer is the same in both records below. The ony difference is that one message was received on wifi connection and another over cellular:

[liblinphone] MESSAGE Found chat room in DB: (peer=sip:<cellphone>@domain.tld, local=sip:sergio@<IP-A>).

[liblinphone] MESSAGE Found chat room in DB: (peer=sip:<cellphone>@domain.tld, local=sip:sergio@<IP-B>).

How should it be fixed?

[Viish]

This is probably a misconfiguration of your SIP proxy that rewrites the FROM with the IP instead of leaving the domain name of the account you're registered to.

[532910]

Could you explain, how FROM is related to incoming message?

The moment linphone receives the message:

MESSAGE sip:sergio@PHONE-IP:PORT;transport=TLS;app-id=ID;pn-type=firebase;pn-timeout=0;pn-tok=TOK;pn-silent=1 SIP/2.0
v: SIP/2.0/TLS SIP-SERVER-IP:5061;rport;branch=<branch>;alias
f: <sip:+CELLPHONE@MYDOMAIN.TLD>;tag=TAG
t: <sip:sergio@PHONE-IP;app-id=ID;pn-type=firebase;pn-timeout=0;pn-tok=TOK;pn-silent=1>
m: <sip:sergio@SIP-SERVER-IP:5061;transport=TLS>
i: I
CSeq: C MESSAGE
Max-Forwards: 70
User-Agent: Asterisk PBX 16.2.1~dfsg-1
c: text/plain
l:     4

test

And I have from_domain=MYDOMAIN.TLD in pjsip.conf endpoint section.

[Viish]

Sorry, I meant the TO. As you can see, the message is not directed to your configured account, but to a username@your-ip. This causes the chat room to be created with a local address of username@your-ip. So each time your IP changes, it will create a new chat room. Since you are using an account, it is way better to direct your messages to username@domain.tld, so no matter your IP you'll be using the same chat room.

[matthewkalantar]

Hi sergio did you solve the problem? I'm having the same issue. i don't have this issue with android version 4.0,1 but i have this problem with android 4.1

[532910]

No! I've asked asterisk-users: http://lists.digium.com/pipermail/asterisk-users/2019-April/293917.html But still no answer.

https://community.asterisk.org/t/asterisk-pjsip-how-to-force-using-domain-name-instead-of-ip-address-for-to-header/71898 Same unanswered question.

[532910]

I've asked #asterisk irc on freenode and Samot says it's impossible.

So this is not my misconfiguration but asterisk-linphone incompatibility.

[Viish]

For those who want to workaround that manually, here's how to do it: In https://github.com/BelledonneCommunications/linphone/blob/master/coreapi/chat.c#L192, check that the localAddress domain match the peerAddress domain and if not force the peerAddress domain in the localAddress...

[brianjmurrell]

@532910, @mehran22k : Yes, this is an issue that affects a number of us. Well, anyone using a SIP server like Asterisk instead of a proxy. The explanation I got was that Asterisk (as a SIP server), rather than simply forwarding messages around, creates new messages based on how they should be routed and the new messages get new "delivery" addresses based on where the message should be sent to.

So ultimately I guess linphone is simply incompatible with SIP servers. That seems like it could/should be a large population of linphone users. I suspect this issue is still looking like it's "niche" because not many SIP server users are using SIP MESSAGE (yet?).

I opened ASTERISK-28513 about this. I haven't really had time to try to implement the solution they are describing there.

[Viish]

@brianjmurrell As you said in the Asterisk ticket you opened

They quote RFC 3261 section 8.1.1.2 further in defending this behaviour. My reading of it doesn't leave me with much to argue against their defence.

So please stop bothering me on that matter.

[brianjmurrell]

Ahhh. I wasn't saying I thought you were right. I was saying I lacked the depth of understanding of the SIP RFCs to make an argument either way. Frankly I'm still not convinced you are right since other SIP clients DO NOT have this problem.

[matthewkalantar]

Guys,

you can solve the problem temporary by replacing just one line in sdk

In identity-address.cpp

IdentityAddress::IdentityAddress (const string &address) : ClonableObject(*new IdentityAddressPrivate) {
    L_D();
    shared_ptr<IdentityAddress> parsedAddress = IdentityAddressParser::getInstance()->parseAddress(address);
    if (parsedAddress != nullptr) {
        d->scheme = parsedAddress->getScheme();
        d->username = parsedAddress->getUsername();
        d->domain = parsedAddress->getDomain();
        d->gruu = parsedAddress->getGruu();
    } else {
        Address tmpAddress(address);
        if (tmpAddress.isValid() && ((tmpAddress.getScheme() == "sip") || (tmpAddress.getScheme() == "sips"))) {
            d->scheme = tmpAddress.getScheme();
            d->username = tmpAddress.getUsername();
                // Here
        //  d->domain = tmpAddress.getDomain();
            d->domain ="yourdomain.com";
            d->gruu = tmpAddress.getUriParamValue("gr");
        }
    }
}

Then rebuild the sdk locally

[brianjmurrell]

@mehran22k

you can solve the problem temporary by replacing just one line in sdk

Yes, that is possible. It has a couple of issues though. It means maintaining another package: fetching, merging, building, etc. on an ongoing basis but more importantly it makes your linphone-android client specific to your domain.

Then rebuild the sdk locally

Any instructions on how to actually do this? Is just a single git repo that needs rebuilding or does this open up a can of worms of having to build umpteen dependencies first?

[brianjmurrell]

Hrm. SDK fails to build for me here:

$ cmake .. -DLINPHONESDK_PLATFORM=Android
...
$ cmake --build . --parallel 8
...
linphone-sdk/build/linphone-sdk/desktop/android-arm64/lib/libbctoolbox.so: undefined reference to `__android_log_assert'
-- Configuring done
clang++: error: linker command failed with exit code 1 (use -v to see invocation)

[matthewkalantar]

@brianjmurrell

Yes, unfortunately it make my client specific to my domain... But now There's no other way

---

In linphone-sdk > linphone > src >address > identity-address.cpp need to add this line: d->domain ="yourdomain.com";

Please look at this screenshot (Red border area) :

just comment defined line and write your domain: Then rebuild the sdk(you may need to clone the sdk , modify this page and build it for first time) I guess rebuild for second time not work correctly sometimes or else you could clean it completely and then try it.

---

if you got error while building please share your identity-address.cpp or anything that you modified

[brianjmurrell]

@mehran22k Yes, I understand how to modify the source, thanks.

But the SDK doesn't build due to the error I pasted above. I have not (yet) modified any source. I wanted to be sure it builds first. It clearly does not.

[Apteryks]

I opened ASTERISK-28513 about this. I haven't really had time to try to implement the solution they are describing there.

For the record, while the issue linked above still exists, there were related changes that should make it possible for an Asterisk operator to support fixing the 'To' header to any value, see these commits from Asterisk:

commit c3654a995968d829e694b04851c0e7b4924c21f5
Author: George Joseph <redacted@digium.com>
Date:   Thu Apr 22 12:07:22 2021 -0600

    res_pjsip_messaging: Refactor outgoing URI processing

     * Implemented the new "to" parameter of the MessageSend()
       dialplan application.  This allows a user to specify
       a complete SIP "To" header separate from the Request URI.

     * Completely refactored the get_outbound_endpoint() function
       to actually handle all the destination combinations that
       we advertized as supporting.

     * We now also accept a destination in the same format
       as Dial()...  PJSIP/number@endpoint

     * Added lots of debugging.

    ASTERISK-29404
    Reported by Brian J. Murrell

    Change-Id: I67a485196d9199916468f7f98bfb9a0b993a4cce

commit 09303e8e227ece6da4253f55acf397c4f9bf2842
Author: George Joseph <redacted@digium.com>
Date:   Thu Apr 22 12:07:22 2021 -0600

    Updates for the MessageSend Dialplan App

    Enhancements:

     * The MessageSend dialplan application now takes an optional
       third argument that can set the message's "To" field on
       outgoing messages.  It's an alternative to using the
       MESSAGE(to) dialplan function.

       NOTE: No channel driver currently implements this field.  A
       follow-on commit for res_pjsip_messaging will implement it for
       the chan_pjsip channel driver.

     * To prevent confusion with the first argument, currently named
       "to", it's been renamed to "destination". Its function,
       creating the request URI, hasn't changed.

     * The documentation for MessageSend was updated to be
       more clear about the parameters and how they interact
       the MESSAGE() dialplan function.

     * With the rename of MessageSend's first parameter, and the fact
       that message.c references <info> elements in chan_sip.c,
       res_pjsip_messaging.c and res_xmpp, they each needed
       documentation updates to use MessageDestinationInfo instead of
       MessageToInfo.

     * appdocsxml.dtd was updated to include a missing element
       declaration for "dataType".  This was showing up as an error
       in Eclipse's dtd editor.

     * Despite the changes in this commit, there should be
       no impact to current users of MessageSend.

    Change-Id: I6fb5b569657a02866a66ea352fd53d30d8ac965a