asterisk users - Dec 2006 - Asterisk Sends 180-RINGING to UA even withprogressinband=yes

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:joakimsen@gmail.com]
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 < dgarstang@oneeighty.com> wrote: 

I have progressinband=yes in sip.conf, but Asterisk sends a 180-Ringing to my
polycom phones and then it also sends 183-Session Progress. That doesn't
seem to make sense. Shouldn't Asterisk NOT send 180-Ringing if
progressinband=yes ?

Doug.
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit: 
   http://lists.digium.com/mailman/listinfo/asterisk-users



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20061211/3cb74f54/attachment.htm

Douglas Garstang 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.
Have you tried an Answer() before your Dial?  That should FORCE inband 
progress tones.  You'll have to have a /etc/asterisk/indications.conf of 
course.

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.5        Server 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.6        Global 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 <dgarstang@oneeighty.com>
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:joakimsen@gmail.com]
> *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 <dgarstang@oneeighty.com> wrote:
> >
> > I have progressinband=yes in sip.conf, but Asterisk sends a
180-Ringing
> > to my polycom phones and then it also sends 183-Session Progress. That
> > doesn't seem to make sense. Shouldn't Asterisk NOT send
180-Ringing if
> > progressinband=yes ?
> >
> > Doug.
> > _______________________________________________
> > --Bandwidth and Colocation provided by Easynews.com --
> >
> > asterisk-users mailing list
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-users
> >
>
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20061211/bff8ae01/attachment.htm