Call dropped when second call comes through the in-use IAX2 trunk

This problem only occurs on about 5 or 10% of the calls on
my system.
I haven't been able to isolate it to a particular case
(meaning it
happens with both incoming and outgoing calls through the
trunk, not
only on one or the other).

I have an IAX2 trunk to my service provider (an excellent
local one
that you're probably familiar with =-).  Once in a while,
but not
always, during a call through the trunk, the call gets
dropped when
another call comes through (call waiting).  The upstream
provider call
waiting feature is disabled (if it's enabled, the call will
be dropped
every time!).

I pulled some log files today because my wife had another
call
interrupted.  I suspect that when the second call comes in,
additional
jitter is introduced in the IAX2 packet stream, causing
asterisk to
disconnect the original call.  I'm experimenting with
enabling the
jitter buffer in my iax.conf file, but it will be a few days
or weeks
before I know if it helps or not.  I don't really need a
diagnosis or
detailed analysis, but any insights that you may have would
be
appreciated.

I did some searching on the message "Didn't get a frame
from channel"
and that's where I came up with the idea that it may be
jitter
induced.

>From the "full" log file:

May 21 17:03:22 DEBUG[7484] chan_sip.c: (Provisional)
Stopping
retransmission (but retaining packet) on
'17da5c2b6aae223a6b1fcbe950db09d1192.168.0.230' Request 102:
Found
May 21 17:03:22 DEBUG[7484] chan_sip.c: (Provisional)
Stopping
retransmission (but retaining packet) on
'080d16f810a176b45a9acbbd31cc96ef192.168.0.230' Request 102:
Found
May 21 17:03:23 DEBUG[7481] chan_iax2.c: Immediately
destroying 2,
having received INVAL
May 21 17:03:23 DEBUG[22995] channel.c: Didn't get a frame
from
channel: IAX2/iaxtrunk-2
May 21 17:03:23 DEBUG[22995] channel.c: Bridge stops
bridging channels
SIP/105-0945e130 and IAX2/iaxtrunk-2
May 21 17:03:23 DEBUG[22995] chan_iax2.c: We're hanging up
IAX2/
iaxtrunk-2 now...
May 21 17:03:23 DEBUG[22995] chan_iax2.c: Really destroying
IAX2/
iaxtrunk-2 now...
May 21 17:03:23 DEBUG[22995] app_dial.c: Exiting with
DIALSTATUS=ANSWER.
May 21 17:03:23 DEBUG[22995] cdr_addon_mysql.c: cdr_mysql:
inserting a
CDR record.

Thanx!


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Utah Asterisk Users Group" group.
To post to this group, send email to utauggooglegroups.com
To unsubscribe from this group, send email to
utaug-unsubscribegooglegroups.com
For more options, visit this group at http://gro
ups.google.com/group/utaug?hl=en
-~----------~----~----~----~------~----~------~--~---

we could try a SIP trunk.  If you message us with your phone
number I can
look to see how many channels you have.  Inbound and
outbound channels on
our system are separate and if they don't match, unexpected
things can
sometimes happen.

You might also check to see if you endpoint can have call
waiting turned on
or off.

-----Original Message-----
From: utauggooglegroups.com [mailto:utauggooglegroups.com] On Behalf
Of
jeremy.willdengmail.com
Sent: Monday, May 21, 2007 9:01 PM
To: Utah Asterisk Users Group
Subject: Call dropped when second call comes through the
in-use IAX2 trunk


This problem only occurs on about 5 or 10% of the calls on
my system.
I haven't been able to isolate it to a particular case
(meaning it
happens with both incoming and outgoing calls through the
trunk, not
only on one or the other).

I have an IAX2 trunk to my service provider (an excellent
local one
that you're probably familiar with =-).  Once in a while,
but not
always, during a call through the trunk, the call gets
dropped when
another call comes through (call waiting).  The upstream
provider call
waiting feature is disabled (if it's enabled, the call will
be dropped
every time!).

I pulled some log files today because my wife had another
call
interrupted.  I suspect that when the second call comes in,
additional
jitter is introduced in the IAX2 packet stream, causing
asterisk to
disconnect the original call.  I'm experimenting with
enabling the
jitter buffer in my iax.conf file, but it will be a few days
or weeks
before I know if it helps or not.  I don't really need a
diagnosis or
detailed analysis, but any insights that you may have would
be
appreciated.

I did some searching on the message "Didn't get a frame
from channel"
and that's where I came up with the idea that it may be
jitter
induced.

>From the "full" log file:

May 21 17:03:22 DEBUG[7484] chan_sip.c: (Provisional)
Stopping
retransmission (but retaining packet) on
'17da5c2b6aae223a6b1fcbe950db09d1192.168.0.230' Request 102:
Found
May 21 17:03:22 DEBUG[7484] chan_sip.c: (Provisional)
Stopping
retransmission (but retaining packet) on
'080d16f810a176b45a9acbbd31cc96ef192.168.0.230' Request 102:
Found
May 21 17:03:23 DEBUG[7481] chan_iax2.c: Immediately
destroying 2,
having received INVAL
May 21 17:03:23 DEBUG[22995] channel.c: Didn't get a frame
from
channel: IAX2/iaxtrunk-2
May 21 17:03:23 DEBUG[22995] channel.c: Bridge stops
bridging channels
SIP/105-0945e130 and IAX2/iaxtrunk-2
May 21 17:03:23 DEBUG[22995] chan_iax2.c: We're hanging up
IAX2/
iaxtrunk-2 now...
May 21 17:03:23 DEBUG[22995] chan_iax2.c: Really destroying
IAX2/
iaxtrunk-2 now...
May 21 17:03:23 DEBUG[22995] app_dial.c: Exiting with
DIALSTATUS=ANSWER.
May 21 17:03:23 DEBUG[22995] cdr_addon_mysql.c: cdr_mysql:
inserting a
CDR record.

Thanx!




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Utah Asterisk Users Group" group.
To post to this group, send email to utauggooglegroups.com
To unsubscribe from this group, send email to
utaug-unsubscribegooglegroups.com
For more options, visit this group at http://gro
ups.google.com/group/utaug?hl=en
-~----------~----~----~----~------~----~------~--~---

Thanks for the comment.
I'm pretty confident that it isn't the trunk itself that's
at fault,
and I've started to think it may be more an issue with load
on the
server.  I'm starting to think that due to the number of
extensions on
the server, and that they are almost all in one big ring
group, that
the large amount of SIP traffic when starting the ring group
causes it
to lose a packet from the IAX2 trunk.  I've turned off the
Qualify
option on the server for most extensions, hoping that will
keep the
server load down, and set up the jitter buffer option in
iax2.conf.
I'll keep monitoring the situation and post anything new
that I
learn.  Any further comments would be welcome.

If I switch back to a SIP trunk from IAX2, would I still be
able to
have two channels (so I can handle call waiting on my
Asterisk box)?
I don't mind setting it up either way.  (I'll send you my
number in an
email message so you can check the account and see if there
are any
problems with it.)
Thanx

On May 22, 11:55 am, "Eliott Spencer"
<eliottspen...gmail.com> wrote:
> we could try a SIP trunk.  If you message us with your
phone number I can
> look to see how many channels you have.  Inbound and
outbound channels on
> our system are separate and if they don't match,
unexpected things can
> sometimes happen.
>
> You might also check to see if you endpoint can have
call waiting turned on
> or off.
>
> -----Original Message-----
> From: utauggooglegroups.com [mailto:utauggooglegroups.com] On Behalf Of
>
> jeremy.will...gmail.com
> Sent: Monday, May 21, 2007 9:01 PM
> To: Utah Asterisk Users Group
> Subject: Call dropped when second call comes through
the in-use IAX2 trunk
>
> This problem only occurs on about 5 or 10% of the calls
on my system.
> I haven't been able to isolate it to a particular case
(meaning it
> happens with both incoming and outgoing calls through
the trunk, not
> only on one or the other).
>
> I have an IAX2 trunk to my service provider (an
excellent local one
> that you're probably familiar with =-).  Once in a
while, but not
> always, during a call through the trunk, the call gets
dropped when
> another call comes through (call waiting).  The
upstream provider call
> waiting feature is disabled (if it's enabled, the call
will be dropped
> every time!).
>
> I pulled some log files today because my wife had
another call
> interrupted.  I suspect that when the second call comes
in, additional
> jitter is introduced in the IAX2 packet stream, causing
asterisk to
> disconnect the original call.  I'm experimenting with
enabling the
> jitter buffer in my iax.conf file, but it will be a few
days or weeks
> before I know if it helps or not.  I don't really need
a diagnosis or
> detailed analysis, but any insights that you may have
would be
> appreciated.
>
> I did some searching on the message "Didn't get a
frame from channel"
> and that's where I came up with the idea that it may be
jitter
> induced.
>
> >From the "full" log file:
>
> May 21 17:03:22 DEBUG[7484] chan_sip.c: (Provisional)
Stopping
> retransmission (but retaining packet) on
> '17da5c2b6aae223a6b1fcbe950db0...192.168.0.230' Request 102:
Found
> May 21 17:03:22 DEBUG[7484] chan_sip.c: (Provisional)
Stopping
> retransmission (but retaining packet) on
> '080d16f810a176b45a9acbbd31cc9...192.168.0.230' Request 102:
Found
> May 21 17:03:23 DEBUG[7481] chan_iax2.c: Immediately
destroying 2,
> having received INVAL
> May 21 17:03:23 DEBUG[22995] channel.c: Didn't get a
frame from
> channel: IAX2/iaxtrunk-2
> May 21 17:03:23 DEBUG[22995] channel.c: Bridge stops
bridging channels
> SIP/105-0945e130 and IAX2/iaxtrunk-2
> May 21 17:03:23 DEBUG[22995] chan_iax2.c: We're hanging
up IAX2/
> iaxtrunk-2 now...
> May 21 17:03:23 DEBUG[22995] chan_iax2.c: Really
destroying IAX2/
> iaxtrunk-2 now...
> May 21 17:03:23 DEBUG[22995] app_dial.c: Exiting with
> DIALSTATUS=ANSWER.
> May 21 17:03:23 DEBUG[22995] cdr_addon_mysql.c:
cdr_mysql: inserting a
> CDR record.
>
> Thanx!


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Utah Asterisk Users Group" group.
To post to this group, send email to utauggooglegroups.com
To unsubscribe from this group, send email to
utaug-unsubscribegooglegroups.com
For more options, visit this group at http://gro
ups.google.com/group/utaug?hl=en
-~----------~----~----~----~------~----~------~--~---