Summary:ASTERISK-15852: When using another SIP Trunk, Asterisk generates the initial ring RING as a response to "SIP SESSION PROGRESS"
Reporter:Alex Oniciuc (alex oniciuc)Labels:
Date Opened:2010-03-22 05:43:57Date Closed:
Versions:Frequency of
Environment:Attachments:( 0) Asterisk_Debug.txt
( 1) debug_session_progress.txt
( 2) debug-verbose.txt
Description:I’m having a strange problem with the VoIP Gateway that I’m using to go on the PSTN: if the number on the other end is busy or unavailable I hear an initial RING, generated by Asterisk from what I’m seeing and after that the line goes down with busy signal:

Here is the scenario:

   Softphone    *ASTERISK                PATTON                   PSTN [BUSY]

1   INVITE     >  INVITE              >   INVITE
2.                              <   SIP/2.0 100 Trying
3.  RING      <  SIP/2.0 180 Ringing  <   SIP/2.0 183 Session Progress
4.      <  SIP/2.0 603 Declined <   SIP/2.0 406 Not Acceptable

Is this regular? Asterisk isn’t supposed to generate the RING  only after the first one received from the PATTON?

This can be very annoying because the calling party may have the impression that the remote party hang up.


Asterisk version:
Comments:By: Elazar Broad (ebroad) 2010-03-22 11:09:35

Per the bug guidelines(http://www.asterisk.org/developers/bug-guidelines), please post(or attach, preferably) a full sip debug. You may obscure anything that your feel is too identifiable.

By: Alex Oniciuc (alex oniciuc) 2010-03-22 11:29:47

I've attached the log from Asterisk and a PATTON SN 4961. This version of Asterisk has the same issue: generates the RING after SESSION PROGRESS.

To test this I've removed the battery from my cell phone, this way my mobile operator returns the voicemail after 15 secs of silence. If I call with a mobile phone or another PBX (Cisco) I'm getting 15 seconds of silence and the voicemail after.
Passing thru Asterisk I'm getting 3 "RING"'s (during these 15 seconds) and the voicemail.

By: Elazar Broad (ebroad) 2010-03-22 12:16:08

The 183(Session Progress) from the Patton has no SDP information, which might be why Asterisk is generating its own ringing. What do you have prematuremedia and progressinband set to?

By: Alex Oniciuc (alex oniciuc) 2010-03-22 13:24:17

progressinband and prematuremedia are using the default values: "never" for progressinband and "no" for prematuremedia.

By: Elazar Broad (ebroad) 2010-03-22 13:36:08

Can you post a trace with:
core set verbose 10
core set debug 10
enabled? Additionally, are you passing 'r' to Dial()?

By: Alex Oniciuc (alex oniciuc) 2010-03-22 14:03:55

I'm not passing arguments to the Dial app.: Dial(${TRUNK}/${EXTEN},60).
What should be the settings for the two parameters above in this case? (When the remote device sends empty SIP 183)
Tomorow (now it's 8pm in Italy) I will post the rest of log you required. Thanks again.

By: Elazar Broad (ebroad) 2010-03-22 21:37:32

Take a look at http://www.voip-info.org/wiki/index.php?page=Asterisk+sip+progressinband

Try setting progressinband=no.

By: Alex Oniciuc (alex oniciuc) 2010-03-23 07:46:49

I've attached the debug log you requested.
In sip.conf, [general] I enabled progressinband=no with no luck. I even tried to put the param in the peer section but it didn't worked.

By: Leif Madsen (lmadsen) 2010-03-23 09:37:50

Acknowledging for now, but any additional debugging you guys can work through would be appreciated.

By: Elazar Broad (ebroad) 2010-03-23 10:30:04

Looks like this is by design, in chap_sip.c(SVN tag, line 15856) we have this chunk of code:
/* Alcatel PBXs are known to send 183s with no SDP after sending
* a 100 Trying response. We're just going to treat this sort of thing
* the same as we would treat a 180 Ringing
if (!req->ignore && p->owner) {
ast_queue_control(p->owner, AST_CONTROL_RINGING);

Which basically translates to "interpret a 183 Session Progress with no SDP as a 180 Ringing." I guess the original developer felt it was better to ring than have dead air for those gateways that send 183 but don't do early media. In theory the Patton should send a 180 instead.

With that said, I can post a patch removing that code which would resolve the issue for you, however the ultimate question is whether that code should remain in altogether, as ringing followed by a busy signal is quite confusing. That question is best left to an Asterisk developer.

By: Alex Oniciuc (alex oniciuc) 2010-03-23 11:25:02

I agree about the confusing part. There is no problem for me to update to a newer version if the issue will be resolved in the future. I prefer the minor version update to the patch.

By: Elazar Broad (ebroad) 2010-03-23 12:10:49

This same code is in SVN trunk as well, so it is currently in all versions.

By: Alex Oniciuc (alex oniciuc) 2010-03-23 12:24:18

If removing this
if (!req->ignore && p->owner) {
   ast_queue_control(p->owner, AST_CONTROL_RINGING);
piece of code solves the problem and if the Asterisk developers will choose to stick to the code above and not consider to remove it in the future releases then I think it may be better to choose the patch.

Can you kindly post the patch too? Maybe I need it after all...
Thank you again for the support.

By: Alex Oniciuc (alex oniciuc) 2010-03-24 03:18:20

OK, I've commented this part

else {
    Alcatel PBXs are known to send 183s with no SDP after sending
    * a 100 Trying response. We're just going to treat this sort of thing
    * the same as we would treat a 180 Ringing

    if (!req->ignore && p->owner) {
        ast_queue_control(p->owner, AST_CONTROL_RINGING);

and now it's working like a charm.

The developer that implemented this didn't consider that the Alcatel PBX could return a Busy/Unreachable state after SIP 183.

It would be nice to have this part removed from the official release though.

By: Leif Madsen (lmadsen) 2010-03-24 12:00:18

This needs to be discussed on the asterisk-dev mailing list to determine how this issue should be handled. Some people may be relying on this.

By: Elazar Broad (ebroad) 2010-03-24 14:18:12

People expect IP PBX's to work like a traditional PSTN based PBX, in most respects. We(humans) distinguish line state based on audible tones, i.e. ringing, busy, disconnected etc. When a gateway/PBX in an IP based system sends a caller call progress information without any way of establishing a media path in order for the person on the line to determine the line state(and the PBX for that matter), then the calling PBX, in this case, Asterisk, needs to make assumptions, which is a very slippery slope; basically damned if you, damned if you don't.

By: Birger "WIMPy" Harzenetter (wimpy) 2010-03-25 00:38:01

I think, that hum with a few clicking noises would be the appropriate sample in that case.

By: Leif Madsen (lmadsen) 2010-03-25 09:53:07

I'm not sure if that last note was serious or sarcastic, but it made me laugh regardless ;)

By: Birger "WIMPy" Harzenetter (wimpy) 2010-03-25 16:45:48


I often hear that same hum triple-click noise at call setup time. And as there's surely no mechanical equipment involved, that must be a sample played in response to proceeding and/or progress messages without inband information.
That's when using ordinary telco services.

By: Elazar Broad (ebroad) 2010-03-26 00:53:37

Spinning harddisks, you won't get it with SSD's ;<)

By: Leif Madsen (lmadsen) 2010-03-26 15:14:52

Hehehe, well what wimpy says could be a solution. I wonder the best way of generating that.

By: John Todd (jtodd) 2010-04-01 09:13:33

The answer is that this should be configurable, if we are going to do anything at all that is "non-standard".  Can the patch be written in such a way that it takes a value from sip.conf under the peer for something like "ringbacknosdp" or something like that?  If we're damned if we do and damned if we don't, then let's let the users damn themselves.  :-)

By: Alex Oniciuc (alex oniciuc) 2010-04-14 03:41:58

I'm trying a new box from Wildix (which is based on callweaver) and this one too sends 183 session progress with no RING. The phone connected to the box is ringing but now, after the modification to the source code, the caller doesn't hear the ring.

This might be a side effect of commenting the rows described above.

I agree with jtodd, implementing a new parameter would permit to enable the feature for some peers, like the Patton who generates too many RINGS, or by other PBXs (Alcatel or other models) who don't generate any.

I’ve attached the SIP debug log containing the session between Asterisk and the Wildix PBX.

By: Elazar Broad (ebroad) 2010-04-14 14:26:00

Make sure JUST:
if (!req->ignore && p->owner) {
ast_queue_control(p->owner, AST_CONTROL_RINGING);
is commented, nothing else.

jtodd: I fully agree, my next project: finding time to write a patch :)

By: Leif Madsen (lmadsen) 2010-04-15 12:22:07

Dropping this down to Acknowledged since there is nothing to try out here (i.e. patch).