Hi there.
I have a very strange situation. All calls from all softphones (X-lite, Ekiga, Phoner…etc) are dropped after some time (30-60 seconds depends of client). Asterisk server and peers are inside local network, there are no nat or firewall running. Only network bridge on Asterisk server, I guess maybe this is the reason.
Also I have goip gateway, and all calls from gateway are not dropped.
I’m running Debian 7 x64 and Asterisk Asterisk 1.8.13.1.
From Asterisk CLI:
== Using SIP RTP CoS mark 5
-- Executing [30@noob:1] Dial("SIP/31-00000010", "Sip/30") in new stack
== Using SIP RTP CoS mark 5
-- Called Sip/30
-- SIP/30-00000011 is ringing
-- SIP/30-00000011 answered SIP/31-00000010
-- Remotely bridging SIP/31-00000010 and SIP/30-00000011
[Oct 14 09:59:58] WARNING[3781]: chan_sip.c:20457 handle_response_invite: just did sched_add waitid(203) for sip_reinvite_retry for dialog db56b088-1b0b-1910-8326-5254001e8f64@cia-93bcdf9813c in handle_response_invite
[Oct 14 10:00:31] WARNING[3781]: chan_sip.c:3656 retrans_pkt: Retransmission timeout reached on transmission db56b088-1b0b-1910-8326-5254001e8f64@cia-93bcdf9813c for seqno 103 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32001ms with no response
[Oct 14 10:00:31] WARNING[3781]: chan_sip.c:3685 retrans_pkt: Hanging up call db56b088-1b0b-1910-8326-5254001e8f64@cia-93bcdf9813c - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).
== Spawn extension (noob, 30, 1) exited non-zero on 'SIP/31-00000010'
Some versions of X-Lite have broken support for re-invites (they ignore them, rather than accepting or rejecting them). That would tend to produce a drop out at that sort of time if you had directmedia (previously canreinvite) or, on COLP capable versions, sendrpid, enabled.
Subject to confirmation from a full SIP log, it does look like it is a failure to respond to a re-invite that is causing the problem.
RE-INVITE can involve changing addresses or ports, adding a media stream, deleting a media stream, and so on. This is accomplished by sending a new INVITE request within the same dialog that established the session. An INVITE request sent within an existing dialog is known as a re-INVITE.
you might try different softphones, like ZOIPER, Check the directmedia option and a full SIP debug OUTPUT.
[quote=“david55”]Some versions of X-Lite have broken support for re-invites (they ignore them, rather than accepting or rejecting them). That would tend to produce a drop out at that sort of time if you had directmedia (previously canreinvite) or, on COLP capable versions, sendrpid, enabled.
Subject to confirmation from a full SIP log, it does look like it is a failure to respond to a re-invite that is causing the problem.[/quote]
Sorry, I’ve forgot to say, that warnings about reinvite are showing when using Ekiga only ( 3 and 4 versions), X-lite and other clients just hangup calls after some time (up to 60 seconds) and there are no warnings or errors in Asterisk CLI.
Also I have another Asterisk server (but on x32 Debian and without network bridge), and all in-out calls are works perfectly. I’m really confused about this situation.
RE-INVITE can involve changing addresses or ports, adding a media stream, deleting a media stream, and so on. This is accomplished by sending a new INVITE request within the same dialog that established the session. An INVITE request sent within an existing dialog is known as a re-INVITE.
you might try different softphones, like ZOIPER, Check the directmedia option and a full SIP debug OUTPUT.[/quote]
Could you tell me, what to look for when sip debug is on, there are a lot of info?
Most problems can be diagnosed by finding the INVITE requests, corresponding responses, and ACKs, and by looking at the SDP payloads associated with them. Unfortunately there is a lot of information to trawl through.
Generally you are going see explicit rejections, repeated retransmissions, indicating that a request or response has got lost, addresses in either the SIP or SDP that are not valid to the recipient (NAT problems), and incompatible codec or encryption choices.
For a delayed failure, it is going to either show up as a retransmission, or to rejection of something like a session timer update.