cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3598
Views
3
Helpful
3
Replies

Calls put on Hold are dropping after 30 seconds

radoslav-drabik
Level 1
Level 1

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

3 Replies 3

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

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?

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.

Getting Started

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: