[Asterisk-Users] Re: call progress - what are the sticking points?

[Steve Underwood]

Joe Greco wrote:

>>Stephen David wrote:
>>    
>>
>>>i don't have a specific bug in mind, i was just wondering WHY call progress doesn't work so well -- in particular, on analog lines.  ie. is it a hardware or software problem (or both).  with more info, i'd like to help to work out the kinks, for myself and everyone.  :)  
>>>      
>>>
>>Back in the days of Stowger exchanges you knew when the called party 
>>answered, by a reversal of the DC voltage on your analogue line. With 
>>digital exchanges that stopped, and no solid feedback is given to the 
>>caller on ordinary analogue lines. You have to infer that someone has 
>>answered, and the reliability of that can be poor. Digital lines, like 
>>ISDNand SS7, and protocols like MFC/R2 tell you positively that someone 
>>has answered.
>>    
>>
>
>That's a good explanation.  I'll expand upon it a bit by saying that even
>with reversal, there's a limited amount of information you can represent
>with that.  POTS was always intended to be cheap basic phone service, and
>keeping it simple was not considered a downside by the phone company.
>
>As it is, you run into an information representation issue with the
>existing technology:  the entire "traditionally used" bandwidth of the
>channel during a call is used for audio data (that is, to say, that they 
>send an analog signal).  As a call originator, you really can not tell 
>the difference between a ringing signal generated by the phone company
>and a ringing signal caused by the called party picking up the phone and
>playing an identical sound.  Reversal fixed that, but was largely made
>obsolete by out of band supervision - since the real purpose of reversal
>was for the telephone company to be able to bill correctly for completed 
>calls (IIRC, ICBW).
>  
>
Actually it was not really intentional. The reversal back to the calling 
party was just a byproduct of the way a Strowger exchange worked. Within 
the network it was used for billing purposes.

>More difficult is the problem of knowing when the remote end has gone
>away.  Reversal, loop break, dial tone, and just plain silence are not
>all that unusual as methods of detection.  In some cases, you do actually
>need to infer that the remote has gone away.
>  
>
Hangup is relatively easy. Most lines now give a strong distinct beeping 
either the moment the phone is dropped, or a short time after. The 
problem in * is its detector is not very good, or very voice immune. I 
have a much better one in my spandsp library, but it isn't integrated 
with * right now. Detecting answer is the tough one. There is nothing 
unambiguous about it.

>There's no real excuse for us to be using this technology anymore, with
>the availability of things like ISDN BRI, which allows for digital
>signalling of call progress.  However, we continue to use it because the
>ILEC's have done such a fab job of making ISDN a dead technology.  Funny
>thing is, it'll end up biting them where it hurts, as customers drift to
>VoIP to gain the features that ISDN promised, at a fraction of the cost.
>  
>
As someone whose colleagues built one of the first ISDN muxes in the 
80's, I can tell you attitudes made it dead from day one.

>(I say that as someone who currently brings in dialtone on BRI, btw)
>  
>
Steve