Ask Your Question

SMS over SIP trunk does not work

asked 2020-09-18 13:03:57 +0000

JasMan gravatar image

updated 2020-09-18 13:09:51 +0000

Since we've switched our telephone line from an PRI line to an SIP trunk we're not able to send SMS anymore. The SMS is send by an server with fax and SMS functionality, which is connected to our PBX via SIP, to the SMS gateway of Deutsche Telekom. As long as the telephone line was an PRI line, everything worked fine. Now it looks like that the the SMS server is not recognizing that the SMS gateway waits for an data transmission, until the SMS gateway answers with an voice announcement, which you can also hear when you call the SMS gateway by phone.

During troubleshooting I've switched the Fax/SMS servers SIP connection to an AVM Fritz!Box, which is connected to an Deutsche Telekom AllIP line (also SIP, but for privat use), and the server is able to send SMS over this connection. So in generally it works. I'm not very familiar with SIP at the moment. The provider says it's an PBX or SMS server issue, the PBX manufacturer says it's an provider or SMS server issue, and the SMS server manufacture says.....just guess :)

So I did an packet capture on our Fax/SMS server for the SIP connection to the SMS gateway for the working- and the non-working-scenario. According to the captures I've understood the flows like this:

Working scenario (SMS_FritzBox_Working.pcapng)

  1. SIP call established (G.711A)
  2. SMS gateway sends an "beep" to signalize, that he's ready to receive an data/SMS transmission
  3. SMS server answers with an "beep" as well, and transmits data/the SMS
  4. SMS gateway sends "beep" and data (guess acknowledgement that he received the SMS)
  5. SMS server sends another "beep" as acknowledgement
  6. SIP goodbye

Non-working scenario (SMS_PBX_Non-Working.pcapng)

  1. SIP call established (G.711A)
  2. SMS gateway sends an "beep" to signalize, that he's ready to receive an data/SMS transmission
  3. SMS server did not recognize the "beep" of the gateway
  4. After 10 seconds the SMS gateway response with an audio announcment (according to Deutsche Telekom this is a normal behaviour)
  5. After another 9 seconds, the SMS server sends a "beep" (like "Hello? Is there someone who want's to talk with me?")
  6. SIP goodbye after audio announcment

SMS Server (, PBX (, Fritz!Box ( Download

I can't find any differences in the SIP negotioation and the protocol of the both captures. But according to the Wireshark RTP stream graph, the audio volume level of the first incoming "beep" from the SMS gateway in the non-working-scenario is much lower, than the one in the working-scenario. Not sure if this is really the reason for this issue, or if I missunderstood this graph only. But it would be an good explanation for me why our SMS server is not recognizing the SMS gateway. Could something like noise reduction or silence detection be the issue?

I did another capture on the session border controller, the ... (more)

edit retag flag offensive close merge delete


But have you captured from the FritzBox over it's AIIIP line? What does the SMS gateway beep look like there?

Jaap gravatar imageJaap ( 2020-09-18 15:06:56 +0000 )edit

No, I haven't captured the traffic on the Fritz!Box so far. The capture function of this box is creepy, frames are often mixed up. So your idea is to do another capture of the WAN line on the Fritz!Box to compare, if the audio volume level is as low as the one from the capture of the SBC? But if this is the case it would mean, that the Fritz!Box increases the volume for internal SIP clients. Is that something that the box does? I will try.

JasMan gravatar imageJasMan ( 2020-09-18 15:29:21 +0000 )edit

Are you able to capture on the PBX? That way you can see how the RTP comes in from the SMS-gateway and how it is forwarded to the SMS-server. Before moving from PRI to SIP trunk, was the SMS-server connecting to the PBX through SIP as well? Or did that part of the configuration change too?

SYN-bit gravatar imageSYN-bit ( 2020-09-18 16:07:05 +0000 )edit

@SYN-bit Capturing on the PBX is not possible. But as I wrote I did an capture on the SBC, and the protocols and audio volume levels of the incoming connection / "beep" from outside, and the ones that are going to the PBX, are the same as the ones, that arrives finaly on the SMS server. The connection from the SMS server to the PBX hasn't changed. It was already a SIP connection before we moved from PRI to SIP.

JasMan gravatar imageJasMan ( 2020-09-18 20:46:07 +0000 )edit

Extract the the RTP audio (as .au files) for the Forward Streams from both the Working and Non-Working using Telephony -> RTP -> Stream Analysis dialog's [Save] button. Using Audacity examine the initial SMS "beep" signal for these .au files. If you zoom into the initial "beep" in both .au files the Non-Working version appears to show a dropout where the working one does not. Could this possible dropout be the reason?

Jim Young gravatar imageJim Young ( 2020-09-19 05:24:27 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2021-01-25 08:59:11 +0000

JasMan gravatar image

The SBC gateway of the SIP trunk provider did some G.711 transcoding, which destroyed the initial "beep" at the start of the data communication. Therefore our SMS server was not able to recognize that the other side is ready to receive its data.

The provider has disabled the transcoding today and now SMS works fine again.

edit flag offensive delete link more


Didn't I say "fragile as ๐Ÿ’ฉ"? Glad they were willing to work with you and tweak the system to make it work ๐Ÿ˜€

Jaap gravatar imageJaap ( 2021-01-25 10:55:46 +0000 )edit

Yep, you did :-)

I asked the provider if there's no default profile which has been already tested with all services. They told me, that they having not default profile until now, because they're still "testing" which settings are the best for the customers. That's why SMS and fax are working for some customers and for the others not. I will never ever touch this device again.

JasMan gravatar imageJasMan ( 2021-01-26 06:27:01 +0000 )edit

Good to hear it has been resolved, took some time to convince them apparently...

SYN-bit gravatar imageSYN-bit ( 2021-01-26 17:22:55 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2020-09-18 13:03:57 +0000

Seen: 115 times

Last updated: Jan 25