VoIP Mailing List Archives

[symack at gmail.com]

Hello Everyone,

Today we observed asterisk sending two invites for the initial call before
the call was established (ie, not re-invites). There were no changes made
to the configuration for a very long time, and was kind of confused when
seeing this action. Can someone please suggest where to look to remove
this behaviour?

U 2014/08/12 07:34:20.405029 192.168.2.10:5060 -> 192.168.2.20:5080
INVITE sip:873359633037@192.168.2.20:5080 SIP/2.0.
Via: SIP/2.0/UDP 192.168.2.10:5060;branch=z9hG4bK541d5594;rport.
Max-Forwards: 70.
From: "555955599" <sip:555955599@victoria.example.com>;tag=as285d2896.
To: <sip:873359633037@192.168.2.20:5080>.
Contact: <sip:555955599@192.168.2.10:5060>.
Call-ID: 5a51eef8064a0d360009f64e34c7007a@victoria.example.com.
CSeq: 102 INVITE.
User-Agent: EXAMPLE Systems.
Date: Tue, 12 Aug 2014 11:34:20 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 279.
.
v=0.
o=root 1631923320 1631923320 IN IP4 192.168.2.10.
s=EXAMPLE Systems.
c=IN IP4 192.168.2.10.
t=0 0.
m=audio 52034 RTP/AVP 18 101.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.


U 2014/08/12 07:34:20.903830 192.168.2.10:5060 -> 192.168.2.20:5080
INVITE sip:873359633037@192.168.2.20:5080 SIP/2.0.
Via: SIP/2.0/UDP 192.168.2.10:5060;branch=z9hG4bK541d5594;rport.
Max-Forwards: 70.
From: "555955599" <sip:555955599@victoria.example.com>;tag=as285d2896.
To: <sip:873359633037@192.168.2.20:5080>.
Contact: <sip:555955599@192.168.2.10:5060>.
Call-ID: 5a51eef8064a0d360009f64e34c7007a@victoria.example.com.
CSeq: 102 INVITE.
User-Agent: EXAMPLE Systems.
Date: Tue, 12 Aug 2014 11:34:20 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 279.
.
v=0.
o=root 1631923320 1631923320 IN IP4 192.168.2.10.
s=EXAMPLE Systems.
c=IN IP4 192.168.2.10.
t=0 0.
m=audio 52034 RTP/AVP 18 101.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

Thanks in Advance,

Nick

--
_____________________________________________________________________
-- 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

[sgriepentrog at digium...]

​There is right at 500 ms between the two invites.  You are seeing a retransmission due to a lack of response to the first INVITE in time.  This is normal, correct, and expected behavior.  The retransmission can occur even sooner in the case where QUALIFY is used to determine that the endpoint usually responds faster.


​



On Tue, Aug 12, 2014 at 6:49 AM, Nick Cameo <symack@gmail.com (symack@gmail.com)> wrote:

[symack at gmail.com]

Thanks Scott, Restarted all the machines since there uptime was 8 years .
Everything works ok now.

Kind Regards,

Nick.

--
_____________________________________________________________________
-- 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