Reorder tone can be used for many things, is there anything I've missed?
7.4.2 401 Unauthorized 78
7.4.4 403 Forbidden ... 78
7.4.5 404 Not Found ... 78
7.4.6 405 Method Not Allowed .. 78
7.4.7 406 Not Acceptable .. 79
7.4.11 410 Gone 79
7.4.16 420 Bad Extension ... 80
7.4.17 480 Temporarily Unavailable . 80
7.4.18 481 Call Leg/Transaction Does Not Exist . 81
7.4.19 482 Loop Detected ... 81
7.4.20 483 Too Many Hops ... 81
7.4.21 484 Address Incomplete .. 81
7.4.22 485 Ambiguous ... 81
7.4.23 486 Busy Here ... 82
7.5Server Failure 5xx .. 82
7.5.1 500 Server Internal Error ... 82
7.5.2 501 Not Implemented . 82
7.5.3 502 Bad Gateway . 82
7.5.4 503 Service Unavailable . 83
7.5.5 504 Gateway Time-out 83
7.5.6 505 Version Not Supported ... 83
7.6Global Failures 6xx . 83
7.6.1 600 Busy Everywhere . 83
7.6.2 603 Decline . 84
7.6.3 604 Does Not Exist Anywhere . 84
7.6.4 606 Not Acceptable .. 84
All of these are defined by RFC2543. 183 is not defined until 2 years later.
Do you have any examples where ringing is indicated and it should not be? I
would really like to know, I am not trying to say you are wrong, I've must
have never encountered such a situation, if a recorded message is played
from the far switch, the audio should be passed, if it tone is played that
is legacy pstn if its over the network or the near end such as a PBX
generating the tone, anything that is digitally interconnected to a proper
ss7 network, be it an ISDN line, PRI or SIP provider, should pass proper
progress out of band. If you are using analog lines then get rid of
progressinband configurations and do as Mr. Wieling suggests.
On 12/11/06, Douglas Garstang [EMAIL PROTECTED] wrote:
Andrew,
I don't think it's a Polycom issue. We took Asterisk out of the picture
and had our Polycom phones communicate directly with an Audiocodes PSTN
gateway. Unlike Asterisk, the audiocodes do not send 180 Ringing before
sending 183 Session Progress, and the polycom's play the correct tones in
this case.
We WANT Asterisk to send progress tones in band. In our case it IS needed.
What's the SIP response for a reorder then if we don't need in band progress
tones? There is none. In a situation where the PSTN end sends back a
reorder, or some other unusual tone, all the UA ends up hearing is the
closest SIP approximation, which is ringing, which is not correct.
I have tried to explain my issues in detail in this list in the past, and
I have invariably met with responses like 'I don't understand' or 'why would
you want to do that?'. I get much better understanding of my issues, and
therefore better replies, when I break the problem down and only explain the
relevant portions.
I really don't appreciate your tone.
Douglas.
-Original Message-
*From:* Andrew Joakimsen [mailto:[EMAIL PROTECTED]
*Sent:* Monday, December 11, 2006 4:40 PM
*To:* Asterisk Users Mailing List - Non-Commercial Discussion
*Subject:* Re: [asterisk-users] Asterisk Sends 180-RINGING to UA even
withprogressinband=yes
When we send 183, that means 'inband progress' is available. That does
_not_ necessarily mean that it is ringing, it could be any sort of progress
tone, or even audio from an IVR. If your ATA does not stop its own ringing
generator and start forwarding the audio, it is broken.
It is my understanding that Polycom's SIP implemenation does not currectly
handle these responses. See: http://bugs.digium.com/view.php?id=3129
In the future it would help that instead of nitpicking some little low
level technical detail you describe what your actual problem is, you would
get more input that way. progessinband=yes means that the call progress WILL
BE SEND INBAND, which in 99% of cases is not needed, and does not make
sense. You are also wasting additinal resources because asterisk must
generate progress tones too.
On 12/11/06, Douglas Garstang [EMAIL PROTECTED] wrote:
I have progressinband=yes in sip.conf, but Asterisk sends a 180-Ringing
