|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:09||Date Closed:||2011-06-07 14:03:08|
|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.
****** ADDITIONAL INFORMATION ******
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
Overlap dial : Yes
DTMFmode : rfc2833
LastMsg : 0
Addr->IP : 192.168.168.74 Port 5060
Defaddr->IP : 0.0.0.0 Port 5060
Def. Username: 389
SIP Options : (none)
Codecs : 0x8 (alaw)
Codec Order : (alaw:20)
Status : Unmonitored
Reg. Contact : sip:email@example.com:5060
|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.