jg at slash128
Nov 20, 2009, 1:30 PM
Post #4 of 4
(513 views)
Permalink
|
Hi Nick,
Thx for the reply. You are correct this is exactly what it turned out
to be. I would agree that it's not a bug, per se. However, Cisco TAC
couldn't tell me this. They kept saying that it had to be the provider
but they didn't know why. No proof, no reason, just had to be because
they claimed that nothing changed between the release that worked and
the release that has the issue. Now, severalmonths later it is
obviously that something changed: video over SIP was introduced. Now
there is a bug ID associated but it is a feature enhancement, seems it
was opened earlier this month. For reference my TAC case started
several months ago. The bug ID itself states that there is no way to
fully remove the video negotiation in the invite. I would argue that
if this is not a bug, it is at least an oversight. I did finally get
it to work, though I had to modify the TAC workaround because it
didn't work with my provider. I'm sure this is provider dependent to
the degree of how each one handles the invites. I found that as long
as I sent a null or invalid parameter for the video my provider just
ignores it. I even put in the word "bogus" as the parameter and the
call completed. But with no modification, or with the exact TAC
prescribed modification, the call fails.
Thx to everyone who helped!
Jason
Sent while mobile.
On Nov 20, 2009, at 12:49 PM, Nick Matthews <matthnick [at] gmail> wrote:
> What it sounds like is this:
>
> Your provider doesn't support SIP video. This was a feature added
> into 12.4(20)T which is why things worked before that version. Before
> 20T, we didn't support SIP video so it wouldn't be possible for the
> provider to complain. We see similar issues like this with ISDN,
> except we have the capability to strip the video capability in ISDN.
> It's not so much a bug as it is your provider not supporting video.
> If you were to unplug the VA your calls would probably start working.
>
> The workaround should work, it's just a matter of setting up the sip
> profiles correctly.
>
> -nick
>
> On Fri, Nov 20, 2009 at 1:53 AM, Jason Granat <jg [at] slash128> wrote:
>> After looking at the SDP header I found the difference between a
>> good and
>> bad call was video capabilities. Seems there is a TAC bug regarding
>> the
>> issue, but even using their workaround doesn’t work. With the work
>> around the
>> call doesn’t complete and I think it is because there is a video a
>> ttribute
>> that cannot be removed.
>>
>>
>>
>> Enhancement to Block Video Codec from Voice class Codec , Open
>> CSCtb10108
>>
>> CUCME TAC Issues - Mon, 11/02/2009 - 12:36
>>
>> Symptom: Telco ===(SIP)===CME===Phone with VT The video codec
>> cannot be
>> disabled on the voice-class codec. The supported codec will be
>> passed to
>> telco if there is no video codec configured on the voice-class codec.
>> Currently, there is option to disable the video codec on the voice
>> class
>> codec. However, it caused some issue when customer make normal
>> voice call to
>> telco via SIP trunk from the SCCP Video Phone. The SIP INVITE
>> message will
>> announce the video codec to Telco when the call being made from Video
>> endpoint. Thus, If the VOIP telco does not support Video Codec, it
>> caused
>> the telco to drop the call when CME announce the video codec within
>> the
>> INVITE Message. This enhancement request aims to add a CLI/Method to
>> filter/Remove the Video Codec before send to any VOIP Trunk.
>>
>> Conditions: - Telco does not have video call capability - Make
>> Normal Voice
>> call from SCCP Video endpoint
>>
>> Workaround: 1. Use SIP profiles to change the SDP to indicate no
>> video
>> support - note this cannot remove the m-line completely but make it
>> a "zero
>> m-line" which indicates SIP video is not supported. The "a=" header
>> is
>> removable by SIP profiles. Below is an example for an outbound
>> call: voice
>> class sip-profiles 2 request INVITE sdp-header Video-Media modify
>> "m=video.*" "m=video 0 RTP/AVP 34 119" request INVITE sdp-header
>> Video-Attribute remove request INVITE sdp-header Video-Bandwidth-
>> Info remove
>> ! dial-peer voice 10000 voip session protocol sipv2 voice-class sip
>> profiles
>> 2 2. Disable CUVA
>>
>>
>>
>>
>>
>> From: cisco-voip-bounces [at] puck
>> [mailto:cisco-voip-bounces [at] puck] On Behalf Of Jason Granat
>> Sent: Thursday, November 19, 2009 10:01 AM
>> To: cisco-voip [at] puck
>> Subject: [cisco-voip] SIP Issue
>>
>>
>>
>> This is a little off-topic but to me still relevant in my learning
>> process.
>> I’m not looking for someone to solve this specific problem, in and
>> of
>> itself. I need to know if I am doing something wrong. I want to
>> understand
>> the technology. I have a voice lab to pass, you know… J
>>
>>
>>
>> Sooo… I’ve had this issue with a UC520. On CME 7.x or greater I
>> have an
>> issue with outbound calls through my SIP carrier having one-way
>> audio, only
>> when ‘service phone videoCabaility’ is set to 1 under telephony-
>> service.
>> This does not happen on CME 4.2 or lower. I ran some tests. This is
>> all 100%
>> reproducible every time. I am trying to pinpoint this thing with
>> sub-nanometer precision…
>>
>>
>>
>> Here’s the basic layout. UC520 with skinny phones (796X & CIPC) wi
>> th CUVA
>> ball cams. SIP trunk to CallCentric. When the video option is off
>> globally
>> in telephony-service (service phone videoCapaility 0) all calls are
>> fine.
>> When video is enabled (service phone videoCapaility 1) calls from
>> the skinny
>> phones out to PSTN via CallCentric have one-way audio: the called
>> party
>> hears just fine but the calling party has dead air. No rx on the
>> phone.
>> Wireshark confirms no RTP coming back to the phone, yet signaling
>> does. All
>> other calls are fine, internal to internal, PSTN to internal.
>>
>>
>>
>> I started my testing by rebooting the UC520 without modifying the
>> config.
>> When it came back up I was able to make outbound calls several
>> times with
>> 100% success, with the ‘service phone videoCapability’ set to 1.
>> After
>> roughly 5 minutes of uptime I went from 100% success to 100%
>> failure. I
>> rebooted again, same behavior: 5 minutes of 100 % outbound calling
>> success, followed by 100% failure.
>>
>>
>>
>> 1’st sanity check: while it was working I copied the running confi
>> g to tftp
>> as a ’good’ file. After it started failing I copied the running
>> config to
>> tftp as a ‘bad’ file. A diff on the two showed no differences.
>> The config
>> doesn’t change between ‘good’ and ‘bad’.
>>
>>
>>
>> 2’nd sanity check: I added the entire list of CallCentric supporte
>> d codecs
>> to my ‘voice class codec’. When the call works it negotiates
>> G711uLaw. As
>> soon as the problem starts happening the call starts negotiating at
>> G729r8.
>> The call setup completes, yet one-way audio.
>>
>>
>>
>> 3’rd sanity check: I set ‘service phone videoCapability’ back
>> to 0, create
>> cnf-files, reset phones and things work again, always, without
>> rebooting.
>> This parameter is the only thing that changes to break or fix the
>> issue.
>>
>>
>>
>> 4’th sanity check: I watched system uptime with the ‘version’
>> command. The
>> problem ALWAYS starts happening at the 6 minute mark.
>>
>>
>>
>> 5’th sanity check: This only happens with IOS post 12.4(11)XW10, w
>> hich has
>> CME 4.2(0). If I roll back to 12.4(11)XW10 the problem never happens,
>> whether video is enabled or not… NEVER!!! In fact I can only have
>> the
>> G711uLaw codec in my list and it still works flawlessly on this co
>> de… IOS
>> post this release is CME version 7.x…
>>
>>
>>
>> Aaaarrrgghhhh…..
>>
>>
>>
>>
>>
>> TIA…
>>
>> Jason
>>
>>
>>
>> ________________________________
>>
>> http://slash128.com
>>
>> ________________________________
>>
>> http://slash128.com
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip [at] puck
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
http://slash128.com
_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip
|
