SMS over SIP trunk does not work
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)
- SIP call established (G.711A)
- SMS gateway sends an "beep" to signalize, that he's ready to receive an data/SMS transmission
- SMS server answers with an "beep" as well, and transmits data/the SMS
- SMS gateway sends "beep" and data (guess acknowledgement that he received the SMS)
- SMS server sends another "beep" as acknowledgement
- SIP goodbye
Non-working scenario (SMS_PBX_Non-Working.pcapng)
- SIP call established (G.711A)
- SMS gateway sends an "beep" to signalize, that he's ready to receive an data/SMS transmission
- SMS server did not recognize the "beep" of the gateway
- After 10 seconds the SMS gateway response with an audio announcment (according to Deutsche Telekom this is a normal behaviour)
- After another 9 seconds, the SMS server sends a "beep" (like "Hello? Is there someone who want's to talk with me?")
- SIP goodbye after audio announcment
SMS Server (10.3.129.38), PBX (10.3.129.42), Fritz!Box (10.3.129.10) 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 ...
But have you captured from the FritzBox over it's AIIIP line? What does the SMS gateway beep look like there?
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.
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 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.
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?
Simply zooming in in the RTP player window shows that the waveform in the non-working capture is a distorted version of the waveform (a sync pattern probably) in the working example, due to its low amplitude. Not sure if that matches with this dropout that you see.
@Jim Young@Jaap Great hints! Looks really that a part of the transmission is missing or at least the amplitude is too low. I compared also the SBC audio and it looks nearly the same as the one of the PBX (see screenshot in dowload folder). So.....any idea what could cause this?
Back to systems level then. The SMS gateway exists in the PSTN domain, where the PRI was connected also. In this domain the SMS gateway analogue signal was digitised at the PSTN edge and switched along a 3.1 kHz bearer channel (probably) to the PBX. The media converter in the PBX packetised this bearer signal into RTP for the SIP session with the SMS server. Note that these conversions have to be properly tuned to maintain audio level, while suppressing echo.
In the new setup the media conversion happens outside the PBX, at the edge of the SIP network where the interconnect to the PSTN is made. For the PBX SIP trunk and the FritzBox SIP line there's probably another interconnect involved, hence a different media gateway. Perhaps the one behind the SIP trunk isn't very capable of handling modem signals. Or the packet stream is going ...(more)
@Jaap That was also my conclusion, that the root cause is somewhere at the provider side, and not our PBX or SMS server. I will ask them. I hope they will support us. In the past they were not really helpful. They just said "Some customers are able to send SMS over their SIP trunks, so no fault at our side.". I had the feeling that they have no idea how SIP works, and that they are just happy that it works at all...mostly :) Thank you again. I will post the solution, if there's one.
One things that always strikes me as odd is that this is in fact a digital technology (SMS) put on a analogue carrier (modulated tones), put on a packet network (RTP), converted to a synchronous bearer (PRI), to be interpreted digitally (DSP) in the analogue domain (modulated tones) to retrieve the data for the SMS service. It's fragile as 💩 and a miracle if this works at all...
I can't shake the feeling the use of a SMS gateway API over the internet would be a more suitable implementation of the service in this day and age, using the communication technologies for what they were intended. But that is not for me to decide.
@JasMan Has the issue been resolved? And if so, what was the root-cause of the issue?