Incoming SIP Text Messages logged as received, but not displayed

Support in English
1

I am working with an American residential SIP provider (happy to give the name if it isn’t against the rules) to help me get a Jami SIP account working with their service.

So far I can send calls and texts, but can only receive calls in Jami. We cannot get Jami to receive SIP text messages.

I opened a log session and sent some texts.

The logs appear to show Jami received the SIP text, which agrees with what the provider’s logs are showing, but the messages never shows up in the Jami’s message display.

Can anyone help a beginner out with this?

Thanks in advance,
Harry

Log:

[1640039815.326|45410|manager.cpp :933 ] ############## START MONITORING ##############
[1640039815.326|45410|manager.cpp :934 ] Using PJSIP version 2.11 for x86_64-pc-linux-gnu
[1640039815.326|45410|manager.cpp :935 ] Using GnuTLS version 3.7.1
[1640039815.326|45410|manager.cpp :936 ] Using OpenDHT version 2.3.0
[1640039815.326|45410|manager.cpp :942 ] Opened files: 162
[1640039815.326|45410|jamiaccount.cpp :4121 ] [Account ################] Monitor connections
[1640039815.326|45410|connectionmanager.cpp:1102 ] ConnectionManager for account ################] (jami:#######), current status:
[1640039815.326|45410|connectionmanager.cpp:1109 ] ConnectionManager for account ################] (jami:#######), end status.
[1640039815.326|45410|manager.cpp :951 ] ############## END MONITORING ##############
[1640039826.592|45451|upnp_context.cpp :645 ] Mapping status [TCP] - overall 4: 4 open (4 ready + 0 in use), 0 pending, 0 in-progress, 0 failed
[1640039826.592|45451|upnp_context.cpp :645 ] Mapping status [UDP] - overall 10: 10 open (8 ready + 2 in use), 0 pending, 0 in-progress, 0 failed
[1640039856.593|45451|upnp_context.cpp :645 ] Mapping status [TCP] - overall 4: 4 open (4 ready + 0 in use), 0 pending, 0 in-progress, 0 failed
[1640039856.593|45451|upnp_context.cpp :645 ] Mapping status [UDP] - overall 10: 10 open (8 ready + 2 in use), 0 pending, 0 in-progress, 0 failed
[1640039879.927|45454|sipvoiplink.cpp :776 ] username = ##########, server = ###.###.###.###, from = ###.###.###.###
[1640039879.946|45454|sipaccount.cpp :1863 ] Matching account id in request is a fullmatch ##########@###.###.###.###
[1640039879.946|45454|sipaccountbase.cpp:464 ] Text message received from ##########@###.###.###.###, 1 part(s)
[1640039886.594|45451|upnp_context.cpp :645 ] Mapping status [TCP] - overall 4: 4 open (4 ready + 0 in use), 0 pending, 0 in-progress, 0 failed
[1640039886.594|45451|upnp_context.cpp :645 ] Mapping status [UDP] - overall 10: 10 open (8 ready + 2 in use), 0 pending, 0 in-progress, 0 failed
[1640039916.595|45451|upnp_context.cpp :645 ] Mapping status [TCP] - overall 4: 4 open (4 ready + 0 in use), 0 pending, 0 in-progress, 0 failed
[1640039916.595|45451|upnp_context.cpp :645 ] Mapping status [UDP] - overall 10: 10 open (8 ready + 2 in use), 0 pending, 0 in-progress, 0 failed
[1640039946.595|45451|upnp_context.cpp :645 ] Mapping status [TCP] - overall 4: 4 open (4 ready + 0 in use), 0 pending, 0 in-progress, 0 failed
[1640039946.595|45451|upnp_context.cpp :645 ] Mapping status [UDP] - overall 10: 10 open (8 ready + 2 in use), 0 pending, 0 in-progress, 0 failed
[1640039976.595|45451|upnp_context.cpp :645 ] Mapping status [TCP] - overall 4: 4 open (4 ready + 0 in use), 0 pending, 0 in-progress, 0 failed
[1640039976.595|45451|upnp_context.cpp :645 ] Mapping status [UDP] - overall 10: 10 open (8 ready + 2 in use), 0 pending, 0 in-progress, 0 failed
[1640040006.596|45451|upnp_context.cpp :645 ] Mapping status [TCP] - overall 4: 4 open (4 ready + 0 in use), 0 pending, 0 in-progress, 0 failed
[1640040006.596|45451|upnp_context.cpp :645 ] Mapping status [UDP] - overall 10: 10 open (8 ready + 2 in use), 0 pending, 0 in-progress, 0 failed
[1640040036.596|45451|upnp_context.cpp :645 ] Mapping status [TCP] - overall 4: 4 open (4 ready + 0 in use), 0 pending, 0 in-progress, 0 failed
[1640040036.596|45451|upnp_context.cpp :645 ] Mapping status [UDP] - overall 10: 10 open (8 ready + 2 in use), 0 pending, 0 in-progress, 0 failed
[1640040059.322|45454|sipvoiplink.cpp :776 ] username = ##########, server = ###.###.###.###, from = ###.###.###.###
[1640040059.333|45454|sipaccount.cpp :1863 ] Matching account id in request is a fullmatch ##########@###.###.###.###
[1640040059.334|45454|sipaccountbase.cpp:464 ] Text message received from ##########@###.###.###.###, 1 part(s)
[1640040066.597|45451|upnp_context.cpp :645 ] Mapping status [TCP] - overall 4: 4 open (4 ready + 0 in use), 0 pending, 0 in-progress, 0 failed
[1640040066.597|45451|upnp_context.cpp :645 ] Mapping status [UDP] - overall 10: 10 open (8 ready + 2 in use), 0 pending, 0 in-progress, 0 failed
2

I just received an update from the SIP provider tech.

He said that the problem may be that Jami is not recognizing the received text because it comes from a different IP address as my SIP server.

So in the lines:

"username = ##########, server = ###.###.###.###, from = ###.###.###.###:

“server” and “from” are different IP addresses.

Could this be the root of my problem, and is there a way I can configure Jami to display SIP texts from IP addresses different from my SIP account server?

4

I have done a little more research and it seems this is a widely known problem where the linux SIP libraries that support many soft phones all have this problem and are in a Mexican stand off with VoIP providers. Each side says the other is doing it wrong and us users can all go pound sand.

Rant:

In a larger context this utter lack of pragmatism is exactly the kind of thing that turns off new linux users who have to go back to windows to use software that actually works instead of “but standards” arguments that leaves linux software with limited utility to much of the computer using world.

5

Hi @hkindle, welcome :slight_smile:, and sorry for the slow reply.

I’m sorry to hear you’re experiencing issues with Jami’s SIP while messaging. Is that all the details Jami gave you in the logs? Did you start the Jami daemon with the -d flag so as to be sure Jami would give most detailed/verbose logs?

Jami does indeed use the well-known and widely-used PJSIP family of libraries for its media communication and SIP functionalities, so it may well be the case that a behaviour experienced in Jami’s SIP functions might show up in other SIP clients as well.

Though Jami developers are for the most part based in Canada, it may be helpful if you mention which ISP’s SIP service you’re using, along with more details such as your distro (and its version), the version of Jami you’re using, and perhaps even the name and version of the SIP server software on your SIP provider’s side if you could share that as well. It’d be great if you could open a bug report at https://git.jami.net/savoirfairelinux/jami-daemon/-/issues with as much details as possible (cf bug report guide) so we could keep track of the issue.

Thanks!