Re: [asterisk-users] SIP Debugging Information..

[Matthew J. Roth]

Michael L. Young wrote:

 If I am reading this right, it looks like a BYE is coming in from
 the far end, Bandwidth.com.


Prior to that, Asterisk retransmits the OK to Bandwidth.com's INVITE
twice.  It doesn't look like Bandwidth.com receives any of them,
because they never respond with an ACK.  Since, from Bandwidth.com's
perspective, the call is never setup, they terminate it with a BYE.

It could just be a NAT issue, but there are two things I really don't
understand about the SIP dialog:

1) It starts with an ACK from Bandwidth.com.  Is it possible that
   the debugging output is missing the beginning of the dialog?

2) Every timestamp is Nov 23 15:43:13.  I don't think the SIP
   session timers on either end should be expiring quickly enough
   for this to happen.

Do other calls originating from Bandwidth.com work properly?  If so,
comparing the SIP from a working call to a failed call may be
revealing.

Regards,

Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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

Re: [asterisk-users] SIP Debugging Information..

[Michael L. Young]

- Original Message -
 From: Howard Leadmon how...@leadmon.net
 To: asterisk-users@lists.digium.com
 Sent: Saturday, November 24, 2012 3:19:10 PM
 Subject: [asterisk-users] SIP Debugging Information..
 
 
  I did a little googling, but didn't seem to find anything specific
  to
 answer the question.   I am trying to debug some calls on an Asterisk
 system
 (AsteriskNow) that are dropping, and when the general logs didn't
 nail
 anything I turned on SIP Debugging on the trunk to the provider.
 Basically the complaint is that when some call in, regardless of if
 the call
 is answered, or if Vmail answers it, it drops the calls in a matter
 of
 seconds.   The strange thing is, that the system processes many
 hundreds of
 calls daily, but only a couple specific incoming callers are seeing
 the
 drops.  I would have thought a NAT issue, but why does this only
 affect a
 specific group of incoming callers, the rest go about their business
 just
 fine.  I think thinking bandwidth.com is mucking something up, but
 again I
 have no specific proof one way or another, so why the debugging.
 
  When one of the problem callers is dropped, in the SIP debugging I
  see:
 
   chan_sip.c: Scheduling destruction of SIP dialog
 '285991942_79966325@192.168.27.72' in 6400 ms (Method: BYE)
 
  
 Is this the remote end (ie bandwidth.com) dropping the call, or is
 the local
 Asterisk server dropping the call?

[snip]
 ---
 [Nov 23 15:43:13] VERBOSE[5127] chan_sip.c:
 --- SIP read from UDP:216.82.224.202:5060 ---
 BYE sip:4104159270@10.98.4.36:5060 SIP/2.0
 Record-Route: sip:216.82.224.202;lr;ftag=gK0b66d829
 Record-Route: sip:67.231.4.93;lr=on;ftag=gK0b66d829
 Via: SIP/2.0/UDP 216.82.224.202;branch=z9hG4bKe902.53bde7e.0
 Via: SIP/2.0/UDP 67.231.4.93;branch=z9hG4bKe902.32697e93.0
 Via: SIP/2.0/UDP 192.168.27.72:5060;branch=z9hG4bK0bBac8c2c3cb90659df
 From: sip:7173381800@192.168.27.72;isup-oli=0;tag=gK0b66d829
 To: sip:+14104159270@67.231.4.93;tag=as0850c6db
 Call-ID: 285991942_79966325@192.168.27.72
 CSeq: 297 BYE
[snip]

If I am reading this right, it looks like a BYE is coming in from the far end, 
Bandwidth.com.

Michael
(elguero)

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

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