One way audio via Sip trunk

-
Audio issues are nasty, especially when they are sporadic.
In such scenarios, it is important to isolate if we are facing issues on inbound calls or outbound calls and collect detailed CM traces with Sip messages enabled.

In the CM traces, all we have to look is the session description protocol (SDP) information.
Through CM traces, we can understand if we are sending early offer or delayed offer.
(In early offer, we send SDP information alongwith Invite message, the opposite happens in delayed offer.)
Below is the snippet of such a scenario-

Content-Type: application/sdp

v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 <ip address>
s=SIP Call
c=IN IP4 <ip address>
t=0 0
m=audio 25494 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
*a=inactive*
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Another sample of SDP in such a scenario-

v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 <ip address>
s=SIP Call
c=IN IP4 <ip address>
t=0 0
m=audio 18800 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=ptime:20
a=sendonly
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15



The part in bold is SDP information.
The part in red is where we see the problem. And who is causing it? The party which is sending this SDP information.
If it is CUCM, it calls for a caveat , what else could it be! ;)


Intermittent MTP leak in certain SIP call scenarios causes call failures

Symptom:
MTP resources may be intermittently leaked, ultimately resulting in failure of
SIP calls that require MTP resources. From RTMT, available MTP resources reach
0 and MTP allocation failure counts go up for each call requiring an MTP.
The SDP portion of the initial INVITE will incorrectly contain "a=inactive".

Conditions:
This issue can only happen in an outgoing initial SIP call setup where MTP is
required. In this case, the outgoing SIP INVITE message will contain an SDP
offer. The issue may occur in the following scenarios:
- Outgoing SIP trunk calls with "Media Termination Point Required" checked on
the SIP trunk.
- Calls between IPv6-only endpoints and IPv4-only endpoints.

This problem does NOT occur in the following scenarios:
- outgoing delayed-offer SIP trunk calls, even if an MTP is required.
- incoming SIP trunk calls.
- mid-call incoming or outgoing INVITE messages.

Workaround:
1. Uncheck "Media Termination Point Required" on the SIP Trunk configuration if
possible.
2. If Early Offer is required, configure Early Offer but leave "Media
Termination Point Required" unchecked.
3. For IPv6 deployment, use dual-stack rather than IPv6-only endpoints.

Comments

  1. amoruck24 September 2012 at 13:55

    Thanks!!!!

    Sep 24 20:39:38.623: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
    Received:
    INVITE sip:XXXXXXXX@192.168.16.34:5060 SIP/2.0
    Via: SIP/2.0/UDP 10.251.6.11:5060;branch=z9hG4bK16469d530eb2db
    From: ;tag=1687856~48e3cf3a-4a07-4f91-82d8-372badd4029e-43718845
    To:
    (....)
    a=inactive
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15

    ReplyDelete

Post a Comment

Popular posts from this blog

Status: Local Agent is not responding. This may be due to Master or Local Agent being down.

-
If you have read my previous post , you would understand why LA and MA services are important for such a scenario and no component has backed-up, rather you get the above error message. Symptoms -   All Disaster Recovery Framework (DRF) services are down, and no new devices, schedules, or statuses can be viewed from the DRF console. Also, when you access the DRF admin pages, the above error message is received. Affected CM releases 6.1.5 and later. Resolution In order to resolve it, first, verify if the Certificate Serial Number in the keystore of Publisher is present in the Truststore of all Subscribers. Complete these steps: Log on to CUCM OS Administration page of Publisher server of the cluster setup. Choose Security > Certificate Management . The Certificate List window displays. You can use the Find controls in order to filter the certificate. Click on the ipsec.pem file and check the serial number of the certificate. Log on to CUCM OS Administr
Read more

Understanding code yellow

-
Understanding sample code yellow alert- Oct 3 01:00:10, cms01, Error, Cisco CallManager, ccm: 147896: Oct 03 05:00:10.616 UTC : %CCM_CALLMANAGER-CALLMANAGER-3-CodeYellowEntry: CodeYellowEntry Expected Average Delay:362 Entry Latency:20 Exit Latency:8 Sample Size:10 Total Code Yellow Entry:14 High Priority Queue Depth:2 Normal Priority Queue Depth:12 Low Priority Queue Depth:70 Cluster ID:StandAloneCluster Node ID:cms01, 3652 The above alert is about code yellow entry, it shows the time when server enters code yellow state. There are no specifications to note at this alert, CM enters code yellow when it achieves the mentioned conditions for code yellow state as mentioned in service parameters. Oct 3 01:00:12, cms01, Error, Cisco CallManager, ccm: 147897: Oct 03 05:00:12.268 UTC : %CCM_CALLMANAGER-CALLMANAGER-3-CodeYellowExit: CodeYellowExit Expected Average Delay:0 Entry Latency:20 Exit Latency:8 Sample Size:10 Time Spent in Code Yellow:2 Number of Calls Rejected Due to C
Read more