Summary:ASTERISK-09479: SIP packets are shown in sip debug peer, but are not actually sent
Reporter:David J Craigon (superdjc)Labels:
Date Opened:2007-05-20 16:08:09Date Closed:2011-06-07 14:03:08
Versions:Frequency of
Environment:Attachments:( 0) editedsip
( 1) look-no-packets.pcap
Description:We run our office phone system using Asterisk 1.4.4. From time to time (seemingly randomly) when making phone calls using our Cisco 7960 phones they hang displaying "INVITE" before actually making the phone call for several seconds, before the phone call is started successfully. Sometimes they time-out altogether.

Running Ethereal/Wireshark, we can see what is happening. The Cisco phone is transmitting SIP INVITEs to the Asterisk server to try and start the phone call. It is getting no response, so it is periodically retransmitting the INVITEs.

Running "sip debug peer" show that Asterisk thinks it is responding to the invites, with "407 proxy authentication required". *But these packets are not actually being sent out of the network card*.

I've attached a pcap snippet from Ethereal and the output of Asterisk doing sip debug peer. You can see the packets that asterisk thinks it's sending and see that they are not actually there in reality.

I tried doing strace with asterisk to try and confirm that asterisk was not actually calling the functions to make the packets, but I didn't get very far. Any tips for this?

I use Asterisk 1.4.4, with lots of realtime, including SIP realtime running from a MySQL database. The phone I've sent you an example of is configured via realtime.

Recreating this problem is tricky- I tried for 90 minutes and it happened to me only 3 times. When everybody is in the office and the phone system is busy, it is a significant problem however.


This is the result of "sip show peer" for the calling SIP phone making the call.

 * Name       : 389
 Realtime peer: No
 Secret       : <Set>
 MD5Secret    : <Not set>
 Context      : Internal
 Subscr.Cont. : <Not set>
 Language     : en
 Accountcode  : 51052
 AMA flags    : Unknown
 Transfer mode: open
 CallingPres  : Presentation Allowed, Not Screened
 Callgroup    : 2
 Pickupgroup  : 2
 Mailbox      : 89@Griffin
 VM Extension : asterisk
 LastMsgsSent : 0/4
 Call limit   : 10
 Dynamic      : Yes
 Callerid     : "David Craigon" <89>
 MaxCallBR    : 384 kbps
 Expire       : 1004
 Insecure     : no
 Nat          : RFC3581
 ACL          : No
 T38 pt UDPTL : No
 CanReinvite  : No
 PromiscRedir : No
 User=Phone   : No
 Video Support: No
 Trust RPID   : No
 Send RPID    : No
 Subscriptions: Yes
 Overlap dial : Yes
 DTMFmode     : rfc2833
 LastMsg      : 0
 ToHost       :
 Addr->IP     : Port 5060
 Defaddr->IP  : Port 5060
 Def. Username: 389
 SIP Options  : (none)
 Codecs       : 0x8 (alaw)
 Codec Order  : (alaw:20)
 Auto-Framing:  No
 Status       : Unmonitored
 Useragent    :
 Reg. Contact : sip:389@
Comments:By: David J Craigon (superdjc) 2007-05-20 16:09:16

This is the ethereal dump

By: Olle Johansson (oej) 2007-05-22 08:48:39

Is this really an asterisk issue, not an o/s issue?

By: David J Craigon (superdjc) 2007-05-22 09:04:03

I know what you mean. Have you got any suggestions how I could prove it one way or the other?

By: Olle Johansson (oej) 2007-05-29 03:06:22

1. Please try with latest svn
2. Please turn on DEBUG so we see if you get any error responses from the network layer. I suspect we get an error message somewhere. We print the DEBUG before we send out on the socket and we now handle errors on the socket layer a bit better.

By: Joshua C. Colp (jcolp) 2007-06-22 11:57:25

Is your MySQL server local or remote?

By: Joshua C. Colp (jcolp) 2007-07-02 09:37:43

I'm suspending this bug since it's been a month since the last reply from the reporter, if you can get the needed information please feel free to reopen.