SIP Debugging Information..

Home » Asterisk Users » SIP Debugging Information..
Asterisk Users 2 Comments

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?

For any that care to look at all the gory details, here is a chunk of the debugging output:

[Nov 23 15:43:13] VERBOSE[5127] chan_sip.c:
<--- SIP read from UDP:216.82.224.202:5060 --->
ACK sip:4104159233@10.98.4.36:5060 SIP/2.0
Record-Route:
Record-Route:
Via: SIP/2.0/UDP 216.82.224.202;branch=z9hG4bKebf3.453cc5a5.2
Via: SIP/2.0/UDP 67.231.8.93;branch=z9hG4bKebf3.315d4e14.3
Via: SIP/2.0/UDP 192.168.37.72:5060;branch=z9hG4bK0eB7f5f0b80116aa493
From: ;tag=gK0e4bc97f To: ;tag=as6974aee7
Call-ID: 353260172_48597606@192.168.37.72
CSeq: 11346 ACK
Max-Forwards: 68
Content-Length: 0

<------------->
[Nov 23 15:43:13] VERBOSE[5127] chan_sip.c: — (12 headers 0 lines) –

2 thoughts on - SIP Debugging Information..

  • Michael L. Young wrote:

    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