03-01-2012 04:59 AM - edited 03-16-2019 09:53 AM
Guys,
Calls put on hold are dropping after 30 seconds.
My topology: SIP server -> Cisco VG 3825 -> PSTN.
VG 3825 runs the c3825-spservicesk9-mz.151-3.T.bin IOS. The call is dropped because of the RTP/RTCP timer (error message: RTP/RTCP receive timer expired. Disconnect the call.) Below is my config and trace for one dropped call.
Could you please help? Why is this happening? It's says a=inactive for the RTP stream and it drops the call anyway.
Voice gateway configuration:
dial-peer voice 3130 pots (Incoming from PSTN)
permission orig
description Incoming from PSTN
huntstop
incoming called-number .
direct-inward-dial
port 0/0/0:15
!
dial-peer voice 1250000 voip (Outgoing to SIP server)
permission term
description SIP server
preference 4
destination-pattern 3...$
session protocol sipv2
session target ipv4:x.x.x.11
voice-class codec 1
dtmf-relay rtp-nte
no vad
!
voice vad-time 1000
!
gateway
media-inactivity-criteria all
timer receive-rtcp 5
timer receive-rtp 1200
!
Hold re-invite:
Feb 29 21:16:16.337 GMT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:9@x.x.x.12:5060 SIP/2.0
To: "unknown" <sip:9@x.x.x.12>;tag=13FF4F98-13C5
From: <sip:3777@x.x.x.11>;tag=SEC11-4a0d9509-4b0d9509-1-8Sy9M4cD97c7
Call-ID: 6F4BCA8F-625111E1-BE5CD8D5-9E39E534@x.x.x.12
CSeq: 1 INVITE
Contact: <sip:3777@x.x.x.11:5060;transport=udp;maddr=x.x.x.11>
Via: SIP/2.0/UDP x.x.x.11:5060;branch=z9hG4bKSEC-4a0d9509-4b0d9509-1-dfYDM2uB7r
Content-Type: application/sdp
Content-Length: 301
X-Siemens-Call-Type: ST-insecure
Accept-Language: en;q=0.0
Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER, INFO
Date: Wed, 29 Feb 2012 21:16:16 GMT
Max-Forwards: 70
v=0
o=MxSIP 0 165574749 IN IP4 x.x.x.51
s=SIP Call
c=IN IP4 x.x.x.51
t=0 0
m=audio 16400 RTP/AVP 18 8 0 101
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=silenceSupp:off - - - -
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=inactive
Feb 29 21:16:16.349 GMT: //9054239/6F48BDC8B14E/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP x.x.x.11:5060;branch=z9hG4bKSEC-4a0d9509-4b0d9509-1-dfYDM2uB7r
From: <sip:3777@x.x.x.11>;tag=SEC11-4a0d9509-4b0d9509-1-8Sy9M4cD97c7
To: "unknown" <sip:9@x.x.x.12>;tag=13FF4F98-13C5
Date: Wed, 29 Feb 2012 21:16:16 GMT
Call-ID: 6F4BCA8F-625111E1-BE5CD8D5-9E39E534@x.x.x.12
CSeq: 1 INVITE
Allow-Events: telephone-event
Server: Cisco
Content-Length: 0
Feb 29 21:16:16.349 GMT: //9054239/6F48BDC8B14E/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP x.x.x.11:5060;branch=z9hG4bKSEC-4a0d9509-4b0d9509-1-dfYDM2uB7r
From: <sip:3777@x.x.x.11>;tag=SEC11-4a0d9509-4b0d9509-1-8Sy9M4cD97c7
To: "unknown" <sip:9@x.x.x.12>;tag=13FF4F98-13C5
Date: Wed, 29 Feb 2012 21:16:16 GMT
Call-ID: 6F4BCA8F-625111E1-BE5CD8D5-9E39E534@x.x.x.12
CSeq: 1 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:9@x.x.x.12:5060>
Supported: replaces
Supported: sdp-anat
Server: Cisco
Supported: timer
Content-Type: application/sdp
Content-Length: 270
v=0
o=CiscoSystemsSIP-GW-UserAgent 3635 7861 IN IP4 x.x.x.12
s=SIP Call
c=IN IP4 x.x.x.12
t=0 0
m=audio 18022 RTP/AVP 18 101
c=IN IP4 x.x.x.12
a=inactive
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
Feb 29 21:16:16.361 GMT: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:9@x.x.x.12:5060 SIP/2.0
To: "unknown" <sip:9@x.x.x.12>;tag=13FF4F98-13C5
From: <sip:3777@x.x.x.11>;tag=SEC11-4a0d9509-4b0d9509-1-8Sy9M4cD97c7
Call-ID: 6F4BCA8F-625111E1-BE5CD8D5-9E39E534@x.x.x.12
CSeq: 1 ACK
Contact: <sip:3777@x.x.x.11:5060;transport=udp;maddr=x.x.x.11>
Via: SIP/2.0/UDP x.x.x.11:5060;branch=z9hG4bKSEC-4a0d9509-4b0d9509-1-WmWhf716Y6
Date: Wed, 29 Feb 2012 21:16:16 GMT
Max-Forwards: 70
Content-Length: 0
Feb 29 21:16:42.130 GMT: //9054239/6F48BDC8B14E/SIP/Info/ccsip_indicate_rt_packet_stats: Processing stats for callid=9054239, proc_id=9
Feb 29 21:16:43.390 GMT: //9054239/6F48BDC8B14E/SIP/Info/ccsip_set_cc_cause_for_spi_err: Categorized cause:41, category:185
Feb 29 21:16:43.390 GMT: //9054239/6F48BDC8B14E/SIP/Info/ccsip_set_release_source_for_peer: ownCallId[9054239], src[6]
Feb 29 21:16:43.390 GMT: //9054239/6F48BDC8B14E/SIP/Info/sipSPIRtpDiscTimerExpired: RTP/RTCP receive timer expired. Disconnect the call.
Feb 29 21:16:43.390 GMT: //9054239/6F48BDC8B14E/SIP/Media/sipSPIUpdateRtpSession: stun is disabled for stream:69EA02C0
Feb 29 21:16:43.390 GMT: //9054239/6F48BDC8B14E/SIP/Info/ccsip_call_statistics: Requesting stats for callid=9054239
Feb 29 21:16:43.390 GMT: //9054239/6F48BDC8B14E/SIP/Info/sipSPI_ipip_antiTrombone: Entered Antitrombone service
Feb 29 21:16:43.390 GMT: //9054239/6F48BDC8B14E/SIP/Info/sipSPI_ipip_antiTrombone: Antitrombone service not configured
Feb 29 21:16:43.390 GMT: //9054239/6F48BDC8B14E/SIP/Info/act_active_disconnect: Disconnect deferred, as stats request pending
Feb 29 21:16:43.398 GMT: //9054239/6F48BDC8B14E/SIP/Info/ccsip_indicate_rt_packet_stats: Processing stats for callid=9054239, proc_id=1
Feb 29 21:16:43.398 GMT: //9054239/6F48BDC8B14E/SIP/Info/sipSPI_ipip_antiTrombone: Entered Antitrombone service
Feb 29 21:16:43.398 GMT: //9054239/6F48BDC8B14E/SIP/Info/sipSPI_ipip_antiTrombone: Antitrombone service not configured
Feb 29 21:16:43.398 GMT: //9054239/6F48BDC8B14E/SIP/Info/sipSPIStopHoldTimer: Stopping hold timer
Feb 29 21:16:43.398 GMT: //9054239/6F48BDC8B14E/SIP/Info/sipSPIStopHoldTimer: Stopping hold timer
Feb 29 21:16:43.398 GMT: //9054239/6F48BDC8B14E/SIP/Info/sipSPISendBye: Associated container=0x69C40820 to Bye
Feb 29 21:16:43.398 GMT: //9054239/6F48BDC8B14E/SIP/Transport/sipSPISendBye: Sending BYE to the transport layer
Feb 29 21:16:43.398 GMT: //9054239/6F48BDC8B14E/SIP/Transport/sipSPIGetSwitchTransportFlag: Return the Dial peer configuration, Switch Transport is FALSE
Feb 29 21:16:43.398 GMT: //9054239/6F48BDC8B14E/SIP/Transport/sipSPITransportSendMessage: msg=0x69B3F668, addr=x.x.x.11, port=5060, sentBy_port=0, local_addr=x.x.x.12, is_req=1, transport=1, switch=0, callBack=0x61AC0344
Feb 29 21:16:43.402 GMT: //9054239/6F48BDC8B14E/SIP/Transport/sipSPITransportSendMessage: Proceedable for sending msg immediately
Feb 29 21:16:43.402 GMT: //9054239/6F48BDC8B14E/SIP/Transport/sipTransportLogicSendMsg: switch transport is 0
Feb 29 21:16:43.402 GMT: //9054239/6F48BDC8B14E/SIP/Transport/sipTransportLogicSendMsg: Set to send the msg=0x69B3F668
Feb 29 21:16:43.402 GMT: //9054239/6F48BDC8B14E/SIP/Info/sentByeDisconnecting: Sent Bye Request, starting DisconnectTimer
Feb 29 21:16:43.402 GMT: //9054239/6F48BDC8B14E/SIP/State/sipSPIChangeState: 0x69705A68 : State change from (STATE_ACTIVE, SUBSTATE_NONE) to (STATE_DISCONNECTING, SUBSTATE_NONE)
Feb 29 21:16:43.402 GMT: //9054239/6F48BDC8B14E/SIP/Msg/ccsipDisplayMsg:
Feb 29 21:16:43.402 GMT: //9054239/6F48BDC8B14E/SIP/Msg/ccsipDisplayMsg:
Sent:
BYE sip:3777@x.x.x.11:5060;maddr=x.x.x.11;transport=udp SIP/2.0
Via: SIP/2.0/UDP x.x.x.12:5060;x-route-tag="tgrp:tg_voice_pri";branch=z9hG4bK1EE7AE312
From: "unknown" <sip:9@x.x.x.12>;tag=13FF4F98-13C5
To: <sip:3777@x.x.x.11>;tag=SEC11-4a0d9509-4b0d9509-1-8Sy9M4cD97c7
Date: Wed, 29 Feb 2012 21:16:16 GMT
Call-ID: 6F4BCA8F-625111E1-BE5CD8D5-9E39E534@x.x.x.12
User-Agent: Cisco
Max-Forwards: 70
Timestamp: 1330550203
CSeq: 102 BYE
Reason: Q.850;cause=102
P-RTP-Stat: PS=201,OS=4020,PR=194,OR=3880,PL=0,JI=0,LA=0,DU=31
Content-Length: 0
03-01-2012 05:14 PM
could you please try changing the rtcp timer to 150..
the initiator is not recieing the repond with in the time configured
revert the result
03-02-2012 12:40 AM
Hi
It works when I change the timer but I believe that the call will drop after 150 (rtcp timer) * 5 (rtcp interval) = 750 seconds anyway, right?
I've found out that I have got two options for implentation of hold:
.
---------------------------------------------------------------------------------
1st - RFC 2543 Compliant (http://www.packetizer.com/rfc/rfc2543/)
-setting the connection address to 0.0.0.0 (neither RTP nor RTCP are sent)
c=IN IP4 0.0.0.0
IP address is set to zero so the RTCP timer is stopped.
2nd - RFC 3264 Compliant (http://www.packetizer.com/rfc/rfc3264/)
-mark the media stream as a=inactive or a=sendonly (media port MUST NOT be zero)
c=IN IP4 192.168.1.1
m=audio 19698 RTP/AVP 0 101
a=sendonly
a=inactive
RTCP is still sent and received for sendonly, recvonly, and inactive streams.
IP address is not set to zero so the RTCP timer is not stoppped and it drops the call after the timer runs out. (MY CASE!)
.
---------------------------------------------------------------------------------
I've read somewhere on the internet that if a stream is put on call hold, the timer for that stream is stopped. Is this statement correct why the timer on my Voice gateway didn't stop?
03-09-2012 01:56 AM
Hi
According to Siemens. When a call is placed on hold the phone should send RTCP packets. This means that the phone doesn’t have to send RTCP packets.
The standard doesn’t strictly specify it as „MUST“ so it depends on implementation.
I have got 2 options now:
a) deactivate the RTCP timer on the Cisco gateway
b) increase to a very large value so it never expires
Is there any option for disabling the rtcp timer for hold cases only?
Thank you.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: