Vonage ignoring comfort noise (CN)

Apologizing in advance for a long post…

Vonage is ignoring my Comfort Noise (CN) and dropping calls.

Here’s the background…

I developed a system for a client that plays prompts and records responses – aka a Third Party Verification system. This system is Asterisk 17.6.0 on CentOS 7.

The typical use case is an agent of my client’s customer will chat up their customer about how wonderful their utility service is and that they should switch from their current utility. Then the agent calls (SIP or PSTN) my client’s system which walks the agent+customer through a script, prompting and recording responses.

This all has been working well for almost 15 years.

Now my client has a new customer that uses the Plank CRM that uses Nexmo/Vonage for call origination.

This works fine if they configure the CRM to use PSTN, but if they use SIP, the calls drop if a recording is not completed within around 5 minutes. Typically this limit is exceeded if the customer has to hunt for their current utility bill.

Vonage says they drop calls with no packets received for something north of 4:30 minutes.

After playing the prompt, my AGI executes ‘record file’ so at that point, no packets are being sent from Asterisk. If the ‘record’ is not completed within 5 minutes, Vonage sends a BYE.

I enabled ‘transmit_silence = yes’ in asterisk.conf and ‘rtp_keepalive = 1’ in pjsip.conf for the endpoint. No joy.

I can see Comfort Noise packets both on the Asterisk console (rtp set debug on) and in PCAPs with Wireshark.

We sent a PCAP showing CN to Vonage and this is their reply:

“When reviewing the SIP traces, The RTP being sent is not in the agreed encoding exchanged in the SDP during the SIP Handshake, G711u with a payload of 0, but rather a payload of 13. At no point was a payload of 13 agreed in the SDP, only 0 and 101.

Could you please check the configuration on your side to include the payload 13

like : a=rtpmap:13 CN/8000

and then retest.

These are calls that originate from Vonage (216.147.x.x). Here’s the SDP from their INVITE:

o=Nexmo 1857134622 1857134622 IN IP4 216.147.x.x
c=IN IP4 216.147.x.x
t=0 0
m=audio 15530 RTP/AVP 8 0 97 18 9 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

and my (45.79.x.x) SDP from my OK:

o=- 1857134622 1857134624 IN IP4 45.79.x.x
c=IN IP4 45.79.x.x
t=0 0
m=audio 12098 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

I’ve never had to deal with CN before, but my limited understanding of SDP negotiation is that I can only agree to stuff they offer. Doesn’t Vonage have to offer before I can agree? Does CN have to be negotiated?

What are my options at this point?

You can offer to receive something that the other side hasn’t offered to receive. That happens all the time, as the initial offer is always made without knowledge of the other side’s offer.

RFC 3264 makes it clear that the answer can include formats not included in the offer:

For streams marked as sendrecv in the answer,
the “m=” line MUST contain at least one codec the answerer is willing
to both send and receive, from amongst those listed in the offer.
The stream MAY indicate additional media formats, not listed in the
corresponding stream in the offer, that the answerer is willing to
send or receive (of course, it will not be able to send them at this
time, since it was not listed in the offer).

One is generally advised not to use comfort noise with Asterisk, as it handles it, at best, poorly.

Unfortunately, I think Asterisk does insist that the codec was in the offer.

As Asterisk does not have a comfort noise generator, very difficult to give options.

It could and maybe does, handle it in pass through mode, like with G.709 and no licences.

How can I add ‘a=rtpmap:13 CN/8000’ to my SDP?

Asterisk is generating CN packets at 1 second intervals. What else would be needed for a ‘comfort noise generator?’

There is no ability to place “CN/8000” in the SDP out of the box. You’d have to make code modifications.

“Comfort noise generator” is probably referring to Asterisk generating a constant stream of audio with background noise, and not referring to sending CN packets themselves.

You also have to add the 13 to the m= line for the audio.

Whilst the RFC allows a UAS to add it unilaterally, UAS’ don’t have to provide that capability.

At the moment it is looking to me, although I may have missed something, that comfort noise frames are passed through even if CN isn’t in the SDP. That’s partly, because, although it can be considered a codec, internally it is treated as a special frame type, not as an audio frame.

As Joshua says, it can’t transcode out of of CN.

If Vonage offered CN in their SDP, would Asterisk accept it?

I think that is unlikely, as Asterisk doesn’t treat it as a codec, but I didn’t examine the code in enough detail to completely rule it out. It will only consider codecs in the allow list for the endpoint, so you could try and see if it accepts it there and includes it in outgoing INVITEs.

The original, bit mapped, codec identification system didn’t have a bit assigned to it.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.