[Asterisk-Dev] IAX Calls close after 140 seconds

Steve Kann stevek at stevek.com
Wed Jun 22 15:56:18 MST 2005


Derek Smithies wrote:

>Tim,
> thanks for your reply..
>
>  
>
>>>Note that The iseqno and timestamp of a full packet form a unique
>>>identifying pair. An iax2 device will keep a record of timestamp and
>>>iseqno of packets sent. On receipt of an ack packet, the iax2 device
>>>will be able to determine which packet has been acknowledged.
>>>      
>>>
>>Not exactly. iseqno on it's own is unique it is an ack of all the
>>full frames sent upto but not including iseq.
>>The timestamp is useful in packet traces and filtering
>>because iseq wraps after a few mins in a typical call, so
>>the timestamp can be used to differentiate.
>>
>>    
>>
>
>True.
>>From the calc_timestamp routine, there are the lines:
>			
>/* On a dataframe, use last value + 3 (to accomodate jitter 
>   buffer shrinking) if appropriate unless
>   it's a genuine frame */
>if (genuine) {
>	/* genuine (IAX LAGRQ etc) must keep their clock-based stamps */
>	if (ms <= p->lastsent)
>		ms = p->lastsent + 3;
>} else if (abs(ms - p->lastsent) <= MAX_TIMESTAMP_SKEW) {
>	/* non-genuine frames (!?) (DTMF, CONTROL) should be 
>           pulled into the predicted stream stamps */
>	ms = p->lastsent + 3;
>}
>
>which ensure that time stamp is given a 3ms gap.. This does not make sense 
>to me, but someone else might be able to shed light on these lines...
>  
>

There's bugs in mantis about this.

The basic story is that:

1) Several IAX endpoints (including asterisk and libiax2) sent out audio 
frames with timestamps _as_sent_, not necessarily as they "ought to be 
sent". I.e. if you only got scheduled every 60ms, you'd end up sending 
frames as 60,61,62 120,121,122, etc.

2) The old jitterbuffer didn't actually "buffer" frames, but just 
"schedule their delivery". so, if it was in a place where it thought it 
should shrink it's "buffer" time, it would schedule each successive 
packet with 1 or 2ms less delay than the previous packet.

3) This lead to the packets that came in a bunch like this to get played 
in _reverse_ order, which, obviously, doesn't sound too good.

-SteveK

>
>Thanks,
>  Derek...
>
>=================
>Derek Smithies Ph.D.                         
>IndraNet Technologies Ltd.                
>Email: derek at indranet.co.nz         
>ph +64 3 365 6485                          
>Web: http://www.indranet-technologies.com/  
>
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>  
>




More information about the asterisk-dev mailing list