Has anyone used Bandwidth.com SIP trunks with a UC520? I am having a weird issue with one-way audio on outgoing calls only. With some outgoing calls to certain numbers, most of the time I will get a one-way audio issue. The UC520 user can't hear the other end. With other numbers, outbound calls are just fine. I've done packet captures with Wireshark during a one way audio call and I get audio for both directions on the LAN and the WAN. I don't know why the 7960 phone won't play the audio back. I've worked with TAC and Bandwidth.com support and they both gave up and blame it on each other. Let me know if any other info would be useful. Thanks |
|||
 |
UC500.comCisco Communication Manager Express, UC520, SMB VOIP reference and community |
zcar, Do you remember any of
zcar,
Do you remember any of the called numbers that had the problem? I'd like to try dialing one or two from our system to see of we get the same result.
We aren't working with Bandwidth.com anymore
I have closed my TAC cases with Cisco, and Bandwidth.com denied any problems with their service. We have stopped working with Bandwidth.com due to the extreme waste of time and money on this issue. I won't be able to do anymore troubleshooting on this issue but I will provide you with anything you might need from my past testing. I have Wireshark packet captures on the WAN and LAN and with 2-way audio calls and 1-way calls.
Like Marcos has said, this is a VoIP issue with the RTP packets from Bandwidth.com. On outbound calls, exactly when the remote party answers the incoming call, the RTP packet sequence value jumps by thousands which confuses the phones. Cisco might update firmware to adapt to this. My old Bandwidth.com case #s are 20844 and 120585 I think. There might be a typo on one of those numbers.
Good luck getting Bandwidth.com to pressure their PSTN providers to update their gateways. You might want to look at another PSTN option.
Thanks again to Cisco TAC, Henry and Marcos for all the effort they put into this issue. They are great!
Similar issue but I need help
Site A has a UC500 with 7 phones working just fine. Site B is a temporary site that has a T-1 one to site A. I changes the telephone service source address to be the WAN address of site A. The 7040 at site B can register to the UC500 with no issues. I can make outbound PSTN calls through the UC500 from site B with no issue. The problem is when I try to dial 3 digit between Site And B. My extension at site B is 609. So any 3 digit calls that either originate or are destined to 609, I hear them but they do not hear me. Any help here is appreciated.
Issue Update
Hi all,
Just wanted to give you an update on this issue.
The problem has been escalated to the IP Phone Product Management, as it is NOT UC500 specific.
If you have TAC cases for this problem, please contact me directly and privately at marchern@cisco.com. We can use your cases to raise visibility that could help us expedite the resolution, if this is indeed a "fixable" problem on our side.
Thanks for the patience.
Marcos
Is there a Bug ID associated
Is there a Bug ID associated with this issue?
Same problem here...
We have a T1 from bandwidth.com through Verizon/MCI. Our UC520 is setup to route calls through their Edgewater gateway (using a private 192.168.1.x subnet) instead of hitting their call routing server directly. We have been having one-way voice audio issues on outbound calls since the beginning and I have troubleshot this extensively with Bandwidth.com. They (said they) made some changes to the call routing on their end and it appeared to resolve the issue, but now had a block-wide power outage today and after coming back, one-way audio all the way. We're able to alleviate the issue by quickly putting the call on hold and picking it up again, this causes the audio to come through to our end. If anyone has any ideas or a solution for this issue please contact me ASAP.
Thanks.
Phone load problem
The problem has been identified as an IP Phone Load problem and it is currently being worked out by Cisco engineering.
It has to do with RTP packet sequence jumping values, which causes the phone to blak hole the voice traffic.
There is no workaround. Thanks for your patience. I will update the forum ASAP.
Marcos
No Workaround!?
Any idea on what the lead time would/will be for a solution? I have a fairly phone intensive office that is for the most part having to pretend they are on their cell-phones. Do you know if installing a T1 Vic in the UC and going PRI to bandwidth would resolve the issue or not? Thanks in advance.
Local POTS should work fine
what you suggest would work, although I would not consider it a workaround per se.
My advice is that you open a high priority case with TAC and have it associated with the software defect number. We are working to resolve this ASAP.
Again, thanks for your patience.
Marcos
Is there a Bug ID associated
Is there a Bug ID associated with this issue?
We have a very similar problem
I have a customer that has experienced very similar one-way audio issues with outbound calls using a UC520 and Bandwidth.com. He reported that if you put the call on hold and then pick it up the audio will come through.
He experienced the issue both when directly connected to the net and when connected to Bandwidth.com's voice equipment once the T1 was delivered.
Wow
You're right! So I'm still not sure if this is a Bandwidth.com issue or Cisco?
zcarguy, I'm going to engage
zcarguy,
I'm going to engage some of the bandwidth.com reps about this issue as they say it doesn't exist. I have one other client that is having the exact same issue to the detail. I'd like to try and join forces and gather some metrics. Could you and your customer start logging the numbers called that are having the problem? I've asked the same of my client as well. Also, would you be comfortable emailing me any bandwidth.com ticket #'s that you have regarding this issue for the bandwidth reps to review. And lastly wold you be interested in participating in a con call I may be having with these guys in the near future?
You can email me directly at mketchum@ketchumits.com
Thanks for any support.
CCSIP Messaging
Here is Debug CCSIP and sh call history voice... Let me know if anything else would be useful. Thanks!
Oct 6 16:56:55.363: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:+1916960xxxx@216.82.224.202:5060 SIP/2.0
Via: SIP/2.0/UDP 66.208.xxx.xxx:5060;branch=z9hG4bK62C7
Remote-Party-ID: "Don xxxx" ;party=calling;screen=yes;privacy=off
From: "Don xxxx" ;tag=3227C4-1AEE
To:
Date: Mon, 06 Oct 2008 16:56:55 GMT
Call-ID: 9D8D0B8C-92FE11DD-802ACA8E-21D6DB37@66.208.xxx.xxx
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
Cisco-Guid: 2620345605-2466124253-2149960334-567728951
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70
Timestamp: 1223312215
Contact:
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 253
v=0
o=CiscoSystemsSIP-GW-UserAgent 6342 8019 IN IP4 66.208.xxx.xxx
s=SIP Call
c=IN IP4 66.208.xxx.xxx
t=0 0
m=audio 19574 RTP/AVP 0 101
c=IN IP4 66.208.xxx.xxx
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
Oct 6 16:56:55.455: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Giving a try
Via: SIP/2.0/UDP 66.208.xxx.xxx:5060;branch=z9hG4bK62C7
From: "Don xxxxx" ;tag=3227C4-1AEE
To:
Call-ID: 9D8D0B8C-92FE11DD-802ACA8E-21D6DB37@66.208.xxx.xxx
CSeq: 101 INVITE
Server: Bandwidth.com TRM (bw7.gold.13)
Content-Length: 0
Oct 6 16:56:57.427: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 66.208.xxx.xxx:5060;branch=z9hG4bK62C7
From: "Don xxxx" ;tag=3227C4-1AEE
To: ;tag=gK02ae958b
Call-ID: 9D8D0B8C-92FE11DD-802ACA8E-21D6DB37@66.208.xxx.xxx
CSeq: 101 INVITE
Record-Route:
Contact:
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Content-Length: 233
Content-Disposition: session; handling=optional
Content-Type: application/sdp
v=0
o=Sonus_UAC 23286 5766 IN IP4 67.231.0.72
s=SIP Media Capabilities
c=IN IP4 67.231.4.98
t=0 0
m=audio 19812 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20
Oct 6 16:57:00.296: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 66.208.xxx.xxx:5060;branch=z9hG4bK62C7
From: "Don xxxx" ;tag=3227C4-1AEE
To: ;tag=gK02ae958b
Call-ID: 9D8D0B8C-92FE11DD-802ACA8E-21D6DB37@66.208.xxx.xxx
CSeq: 101 INVITE
Record-Route:
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact:
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Content-Length: 233
Content-Disposition: session; handling=optional
Content-Type: application/sdp
v=0
o=Sonus_UAC 23286 5766 IN IP4 67.231.0.72
s=SIP Media Capabilities
c=IN IP4 67.231.4.98
t=0 0
m=audio 19812 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20
Oct 6 16:57:00.304: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
ACK sip:+1916960xxxx@67.231.0.72:5060 SIP/2.0
Via: SIP/2.0/UDP 66.208.xxx.xxx:5060;branch=z9hG4bK71E29
From: "Don xxxx" ;tag=3227C4-1AEE
To: ;tag=gK02ae958b
Date: Mon, 06 Oct 2008 16:56:55 GMT
Call-ID: 9D8D0B8C-92FE11DD-802ACA8E-21D6DB37@66.208.xxx.xxx
Route:
Max-Forwards: 70
CSeq: 101 ACK
Allow-Events: telephone-event
Content-Length: 0
Oct 6 16:57:53.406: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
BYE sip:916978xxxx@66.208.xxx.xxx:5060 SIP/2.0
Record-Route:
Via: SIP/2.0/UDP 216.82.224.202;branch=z9hG4bK1fef.1ad55473.0
Via: SIP/2.0/UDP 67.231.0.72:5060;branch=z9hG4bK02Bfbb1267fb0d76568
From: ;tag=gK02ae958b
To: "Don xxxx" ;tag=3227C4-1AEE
Call-ID: 9D8D0B8C-92FE11DD-802ACA8E-21D6DB37@66.208.xxx.xxx
CSeq: 24040 BYE
Max-Forwards: 69
Content-Length: 0
Oct 6 16:57:53.414: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 216.82.224.202;branch=z9hG4bK1fef.1ad55473.0,SIP/2.0/UDP 67.231.0.72:5060;branch=z9hG4bK02Bfbb1267fb0d76568
From: ;tag=gK02ae958b
To: "Don xxxx" ;tag=3227C4-1AEE
Date: Mon, 06 Oct 2008 16:57:53 GMT
Call-ID: 9D8D0B8C-92FE11DD-802ACA8E-21D6DB37@66.208.xxx.xxx
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 24040 BYE
Reason: Q.850;cause=16
Content-Length: 0
GENERIC:
SetupTime=3286980 ms
Index=10
PeerAddress=+1916960xxxx
PeerSubAddress=
PeerId=101
PeerIfIndex=70
LogicalIfIndex=0
DisconnectCause=10
DisconnectText=normal call clearing (16)
ConnectTime=3291920 ms
DisconnectTime=3345030 ms
CallDuration=00:00:53 sec
CallOrigin=1
ReleaseSource=4
ChargedUnits=0
InfoType=speech
TransmitPackets=2795
TransmitBytes=447200
ReceivePackets=2862
ReceiveBytes=457920
VOIP:
ConnectionId[0x9C2F4D05 0x92FE11DD 0x8025CA8E 0x21D6DB37]
IncomingConnectionId[0x9C2F4D05 0x92FE11DD 0x8025CA8E 0x21D6DB37]
CallID=13
RemoteIPAddress=216.82.224.202
RemoteUDPPort=19812
RemoteSignallingIPAddress=216.82.224.202
RemoteSignallingPort=5060
RemoteMediaIPAddress=67.231.4.98
RemoteMediaPort=19812
SRTP = off
TextRelay = off
Fallback Icpif=0
Fallback Loss=0
Fallback Delay=0
RoundTripDelay=0 ms
SelectedQoS=best-effort
tx_DtmfRelay=rtp-nte
FastConnect=FALSE
AnnexE=FALSE
Separate H245 Connection=FALSE
H245 Tunneling=FALSE
SessionProtocol=sipv2
ProtocolCallId=9D8D0B8C-92FE11DD-802ACA8E-21D6DB37@66.208.xxx.xxx
SessionTarget=216.82.224.202
OnTimeRvPlayout=54440
GapFillWithSilence=0 ms
GapFillWithPrediction=0 ms
GapFillWithInterpolation=0 ms
GapFillWithRedundancy=0 ms
HiWaterPlayoutDelay=0 ms
LoWaterPlayoutDelay=0 ms
ReceiveDelay=0 ms
LostPackets=0
EarlyPackets=0
LatePackets=0
VAD = disabled
CoderTypeRate=g711ulaw
CodecBytes=160
cvVoIPCallHistoryIcpif=0
MediaSetting=flow-around
CallerName=Don xxxx
CallerIDBlocked=False
OriginalCallingNumber=102
OriginalCallingOctet=0x0
OriginalCalledNumber=8960xxxx
OriginalCalledOctet=0x80
OriginalRedirectCalledNumber=
OriginalRedirectCalledOctet=0x0
TranslatedCallingNumber=916978xxxx
TranslatedCallingOctet=0x1
TranslatedCalledNumber=+1916960xxxx
TranslatedCalledOctet=0x80
TranslatedRedirectCalledNumber=
TranslatedRedirectCalledOctet=0x0
GwCollectedCalledNumber=8960xxxx
GwOutpulsedCalledNumber=+1916960xxxx
GwOutpulsedCalledOctet3=0x80
GwReceivedCallingNumber=102
GwReceivedCallingOctet3=0x0
GwReceivedCallingOctet3a=0x0
GwOutpulsedCallingNumber=916978xxxx
GwOutpulsedCallingOctet3=0x1
GwOutpulsedCallingOctet3a=0x83
MediaInactiveDetected=no
MediaInactiveTimestamp=
MediaControlReceived=
LongDurationCallDetected=no
LongDurationCallTimerStamp=
LongDurationCallDuration=
Username=
GENERIC:
SetupTime=3284680 ms
Index=11
PeerAddress=102
PeerSubAddress=
PeerId=20009
PeerIfIndex=94
LogicalIfIndex=93
DisconnectCause=10
DisconnectText=normal call clearing (16)
ConnectTime=3291920 ms
DisconnectTime=3345030 ms
CallDuration=00:00:53 sec
CallOrigin=2
ReleaseSource=4
ChargedUnits=0
InfoType=speech
TransmitPackets=0
TransmitBytes=0
ReceivePackets=2795
ReceiveBytes=447200
TELE:
ConnectionId=[0x9C2F4D05 0x92FE11DD 0x8025CA8E 0x21D6DB37]
IncomingConnectionId=[0x9C2F4D05 0x92FE11DD 0x8025CA8E 0x21D6DB37]
CallID=12
Port=50/0/8 (12)
BearerChannel=50/0/8.0
TxDuration=54400 ms
VoiceTxDuration=54400 ms
FaxTxDuration=0 ms
CoderTypeRate=g711ulaw
NoiseLevel=0
ACOMLevel=0
SessionTarget=
ImgPages=0
CallerName=Don xxxx
CallerIDBlocked=False
LongDurationCallDetected=no
LongDurCallTimeStamp=
LongDurCallDuration=
OriginalCallingNumber=102
OriginalCallingOctet=0x0
OriginalCalledNumber=
OriginalCalledOctet=0x80
OriginalRedirectCalledNumber=
OriginalRedirectCalledOctet=0x0
TranslatedCallingNumber=102
TranslatedCallingOctet=0x0
TranslatedCalledNumber=
TranslatedCalledOctet=0x80
TranslatedRedirectCalledNumber=
TranslatedRedirectCalledOctet=0x0
GwCollectedCalledNumber=8960xxxx
GwReceivedCallingNumber=102
GwReceivedCallingOctet3=0x0
GwReceivedCallingOctet3a=0x0
Signaling looks good
If it weren't for the symptom you are describing, I would say everything looks good for this 1 minute call.
Few suggestions:
1) Upgrade to latest IOS/CCA/SBCS release, if you are not there yet.
2) As suggested by a previous post, make sure there are no firewalls blocking the RTP traffic.
3) Add this to the config:
ip inspect name SDM_LOW udp router-traffic
(change SDM_LOW for whatever inspect policy you have)
4) Press the "i" button twice to check that the phone is sending/receiving traffic
5) Check "show call active voice brief" while on a call to see if the traffic is indeed getting to the UC500.
Marcos
No Firewall, directly connected to cable modem
Thanks for looking into this.
1. I am currently running 12.4(11)XW7 IOS/Package
2. I have disabled all firewalls and ACLs, the UC520 is directly connected to a cable modem with it's own static, public IP.
4./5. RTP is incrementing in both directions on the active call on the router on both call legs and on the phone RTP screen.
One thing I noticed in the RTP screen on the phone is that max jitter is 41038402 and conceal secs/severely conceal secs is equal to length of the call. On a internal calls, these stats are zero. Does this help at all?
My next step is trying the same Bandwidth.com account using a 2821 ISR to see if it's a UC520 issue.
Let me know if you guys think of anything else. I have the config available if I knew how to attach files to this thread.
I have the same problem on an ISR 2821
I setup a 2821 to connect use the Bandwidth.com SIP trunk and it also has one way audio on outbound calls.
TAC should be able to handle this
Email me directly. Once we figure it out, we will post the solution here for the community's benefit.
Marcos
firewall
i'm assuming you have already ruled out firewall/ACL issues? I know that is a frequent cause of one-way audio issues. i've configured a few different SIP trunks, and havent noticed any issues as long as the firewall is configured correctly.
i'd permit 'udp any' between bandwidth.com's IPs and your router WAN to be sure it isnt getting blocked. also make sure you have a inpsection line for 'udp router-traffic'.
also is the uc500 connected directly to the internet, i.e. no NAT device in front of it?
Post "debug ccsip messages"
That should give us a clue. Bandwidth.com uses Level 3 as the wholesale ITSP, and UC500 works with Level3.
Marcos