I posted this on the mailing list. Here is a link that explains the issue
I tried to attach the OpenSIPS syslog debug but it was too big.
The only difference i see in your SIP trace is that for first call your media server sends 183 Early Media, while for second call (after 1st times out) your media server sends 180 Ringing instead of 183.
The difference between the two sip responses is that in case of 183 Early Media, remote ring back tone is sent by callee endpoint in form of inbound audio. While in case of 180 Ringing, there is no remote ring back tone and the caller endpoint suppose to play some local ring back tone to give audio feedback to the caller.
Therefore, it appears that your caller endpoint does not support local ring back tone, that's why you don't get any ring back.
For workaround, you can force your media server (if a media server is really involved), to send 183 early media instead of 180 ringing reply for each invite.
The issue is that I don't have a media server. This is all done with OpenSIPS relaying. Here is an example that kind of goes against what you say with the 180 and 183 messages.
In this example the Caller first calls a user local to OpenSIPS. Then the call is forked and a user out on the PSTN network is called. Finally another fork occurs and a local user is called.
local user 9012732009 Q = 90 Called First Caller hears ringing
PSTN user 90121X8X63 Q = 50 Called Second Caller hears ringing
local user 9013349019 Q = 40 Called Last Caller hears ringing
So you would think that on the last call the Caller would not hear ringing in his ear but he does.
So my first example had the following
Callee1 sends a 183
Callee2 sends a 180 <---- No ringing
My second example had the following
Callee1 sends a 180
Callee2 sends a 183
Callee3 sends a 180 <---- Caller can hear ring in ear just fine
So on my second scenario is it because the first callee sends a 180 that the third callee sending a 180 doesn't mess things up??? Perhaps this isn't a bug and we can move this conversation to the mailing list, but I figure OpenSIPS would need a way to fix this or else other people will run into this say issue when appending branches and calling out to PSTNs that send back 180 when the second callee sends a 183.
I tested the first scenario with Blink being the Caller and Blink was not able to hear ringing in the ear when the second callee was called.
Not sure if this is a bug. The discussion has moved to the mailing list.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.