No ringback tone is heard in some calls

I have quite a wierd problem when I calling via my SIP trunk to provider.
Sometimes happend that I can’t hear ringback tone on some outgoing calls but after the call is picked up by callee, everything is fine and both sides can hear each other. So problem is only in generating/reecieving that ringback tone before the call is picked up.
It is not regular problem - mostly everytime works just fine except on few calls where this problem happened.

I did some analysis via Wireshark of good call and bad call.
Basicly they are the same:
I send INVITE with SDP
I receieve TRYING , 183 SESSION PROGRESS with SDP , 180 RINGING, 200 OK (INVITE) with SDP

Only difference is in received 183 SESSION PROGRESS and 200 OK SDPs’ from provider in bad call.
In both messages Provider send:

Media Description, name and address (m): audio 52126 RTP/AVP 8 101
            Media Attribute (a): rtpmap:101 telephone-event/8000
            Media Attribute (a): maxptime:30
            Media Attribute (a): sendrecv
            Media Attribute (a): ptime:20

So there is no Media Attribute for PCMA and there is sendrecv. Is that a reason for not hearing the ringback tone?

I’m not sure how it works - who sending or generating ringback tone…
I assume that if I receive 183 SESSION PROGRESS before 180 RINGING from provider so the provider send me ringback tone too.
But if there is no ringback tone sended my Asterisk or phone should generate own ringback tone.
Or Am I completely wrong?

Thanks for explain how it works

There have been suggestions that you need to, explicitly, call Progres(), but I’m not sure if that is still true if Progress was received from the other side.

Another possibility is that you are behind NAT and are not sending the correct media public address, or the router is mangling the media port number, and the other side ar relying on symmetric RTP to work out your true media address.

I was also struggling with ringback problems, networks that send an 183 without SDP or sending 180 after 183 and so on.
In fact I never understood how we got into this situation. Years ago there was only 180 RINGING and everything was fine…

However, somewhere between asterisk 18 and asterisk 18.15 the pjsip.conf parameter allow_sending_180_after_183 was introduced and somehow it solved all these issues for me. Maybe you want to give that a try.

type = global

Thank you both, for response… As I read about Progress, it looks like it is more for sending ringback tone to the other side than receiving, but I can give it a try.

For now I trying to understood RFC´s which describes SDP offer/answer exchange but not so succesfullly.

So is my assuming about difference between 183 and 180 at first posst correct or it isn´t that clear?

P.S.: Sorry for my english

I wanted to solve this issue by add r parameter to Dial() fnc.
Howewer right before I started do anything, I tested this problem again from same line to same number and everything is fine… ringback tone had been heard. So I looked into wireshark what happened (if SDP were negotiated correctly at this time) and to my suprise it is all the same wierd as before - 183 Session Progress with same missing atributes - 180 Ringing sended after that - etc.

So this is not causing that problem…

I looked on the RTP stream in wireshark and if everything is correct i can see (and hear) ringbacktone in stream from callee IP address to my PBX´s IP address.

When I look on bad call I don´t see any ringback tone in stream.
So Asterisk should generate ti´s own ringback tone at this situation, isn´t it?
Should I enable this somewhere because clearly now it is not enadbled?

We also had this issue. Seemed to only affect outbound calls on Inteliquent. We switched SBC’s on Inteliquent’s side and the problem went away. I can’t explain it but I’m glad it’s gone.

Just from a “how it works” perspective - Asterisk forwards the stream as-is. It doesn’t examine it. It doesn’t inject ringing if the stream is silence.

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