Hi, The descriptions of Progress() and Proceeding() are really vague. Progress(): ---cut---------------- [Synopsis] Indicate progress [Description] Progress(): This application will request that in-band progress information be provided to the calling channel. ---cut---------------- Proceeding(): ---cut---------------- [Synopsis] Indicate proceeding [Description] Proceeding(): This application will request that a proceeding message be provided to the calling channel. ---cut---------------- I know Asterisk is a multi-protocol PBX so it's quite obvious that what the applications really do largely depends upon the channel driver. But OTOH "Indicate progress" or "Indicate proceeding" doesn't mean anything for the end user. For SIP Progress() seems to send "183 Session Progress" (AST_CONTROL_PROGRESS), Proceeding() is "100 Trying" (AST_CONTROL_PROCEEDING). 183 starts early media, 100 does not. Are there any situations where it makes sense to use either of these applications from the dialplan? Philipp Kempgen -- AMOOCON 2009, May 4-5, Rostock / Germany -> http://www.amoocon.de Asterisk: http://the-asterisk-book.com - http://das-asterisk-buch.de AMOOMA GmbH - Bachstr. 126 - 56566 Neuwied -> http://www.amooma.de Gesch?ftsf?hrer: Stefan Wintermeyer, Handelsregister: Neuwied B14998 --
At 07:28 AM 2/14/2009, Philipp Kempgen wrote:>But OTOH "Indicate progress" or "Indicate proceeding" doesn't >mean anything for the end user. > >183 starts early media, 100 does not. > >Are there any situations where it makes sense to use either of >these applications from the dialplan? > > Philipp KempgenYES. In a large scale Farm-of-Asterisks application (thousand+ concurrent calls) where calls with a certain Tier 1 carrier requires 183 for some routes and not for others. Thus an adaptable dial plan and sip.conf. Unfortunately, the consumer should really care because it says a lot about their SIP provider(s) endeavors to provide reliable service - - - if we can adapt our Asterisks to their idiosyncrasies. <RANT> IMHO - - - because of the highly distributed [i.e. fractured-proxy ] design of the supposedly Tier-1 provider network. The carrier needs extra time and assistance to setup the RTP path with the real media port of another-carrier's point of origin. This usually indicates the calls are not organic calls from the carrier's own retail traffic but are 2nd or 3rd route calls collected from diverse wholesale sources [i.e. other carriers] where the RTP is probably not running over the Tier-1's own network. OUR OWN constant push to pass RTP over someone else's network must be controlled. We are deceiving ourselves (and our consumers) if we mistakenly believe that a recognizable Tier-1 brand name is synonymous with good VoIP service. </RANT> ..mike.. ..mike..