intermittent one-way audio and no-way audio on SIP Trunk

Unanswered Question
Jul 11th, 2007

intermittent one-way audio and no-way audio on SIP Trunk

Callmanager 4.2.3 ES15 on OS 2000.4.4a SR7

Approximately 7 to 10 calls a day experience one-way audio and about the same experience no audio in either direction (at least those are the ones being reported). The one-way audio is always the same: outside caller initiates call, inside employee cannot hear them, but they can hear employee. If caller hangs up and calls back, most of the time the call proceeds normally without incident (sometimes it takes several tries). With no-way audio, the employee reports that there is absolutely no sound at all, not even background noise.

There has never been a problem like this with outbound dialing (that has been reported).

We have 4 locations around the US. The only PSTN access is SIP Trunks provided by a company called Smoothstone. Every SIP call is G711 all the way to/from Smoothstone (they say). Each site has their own Cisco 2801 that has a direct IP WAN link to Smoothstone; smaller sites have a single T1 WAN and larger sites have multiple T1s. The Cisco 2801s are Smoothstone controlled. Connection into our network is that each 2801 has an interface on the voice vlan at each site. Smoothstone has only one IP address to point to for their SIP server; each site has a static route that points to the Smoothstone controlled 2801 at each site for the path to the SIP server. (Dynamic routing will be introduced later but for now we have static routes). All sites have experienced the problem.

Here is a bit of interesting information: When a bad call comes in, if you park the call and then pick it up right away, the rtp path is established in both directions and all is good. Hold does not do the same - it is only call park that some how makes the call connect properly.

Also interesting: some callers (regular customers) who call frequently never experience the issue. Some other frequent customers experience the issue as many as 3 times out of 5.

As far as we can tell the problem began around the time that the Jacksonville Subscriber was put into place (May 2007). This was also the time that Smootstone began sending calls directly to each site using dial-peers with IP addresses and UDP port numbers. Previously, all call processing was done by the Publisher in California using UDP port 5060 - which in return caused rtp initial connection delays up to 2-3 seconds and caused alot of grief (processing the call in one location and having the rtp stream follow a different route to the final location). Smoothstone also made changes to the routing paths to force calls to go through some kind of accounting package. There were problems with outside callers who blocked their own callerid from going out could not call into our company at all; Smoothstone blocked them - now that is fixed, again.

As of today, we still experience the issue. Smoothstone says that is is obviously a Callmanager issue. I don't have enough SIP experience to be able to argue with them about the matter. This really has me baffled, but I think that parking a call and then retrieving it and having it work is the key that may unravel the mystery...

More info in attached files.

The trace file shows a call that initially failed, then was parked, then was retrieved and it worked. search for inbound callerid = 9046077039

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
mchin345 Wed, 07/18/2007 - 08:38

The problem may due to Codec check it or Upgrade the IOS 12.4.4T later.


This Discussion