No video when calling an IP only h.323 C60 from jabber(movi)

[Darren Lapierre]

Hello,

I seem to be having an odd occurance and am looking to see if someone could give me some guidance.

I have an externally IP assigned C60 (not registered to a GK; Ver 5.1.2). When I call it from my jabber client (ver 4.4), audio negotiates, but video does not.

When I call from my MCU, the call is fine. When I call from an older codec (MXP 1700), the call is fine.

When I register the C60 to a GK (Expressway), I can call via my jabber client.

Since my MCU connects to it fine, I am thinking it is a codec negoiation issue, but what could I check to determine this?

Any help would be appreciated. Thanks

D.

[Tomonori Taniguchi]

C60 and Jabber video should negotiate H.264 video capability in default.

Assume you have VCS Expressway that Jabber Video is making a call to C60 on public network and which handling interworking call.

Probably good to start taking "Debug" level log for "Network Log" and "Interworking Log" on VCS Expressway (since this allow us to check negotiation in both sides together) and check making sure VCS E and C60 does negotiate video capability in CapSet.

I'd suggest to open TAC support case for further investigation (please be careful posting any log on public forum as log will contain system information).

[afadeyev1]

Hi,

I have some updated info:

Any call from public Jabber to H.323 only endpoint where VCS or VCSE is doing interworking  - no video from Jabber.

The problem seems to be related to the fact that public Jabber provisioned by CUCM.

I can only guess, that  SIP call from CUCM in one entrerprise to H.323 endpoint provisioned by VCS of another enterprise will have same problem.

See debug log below:

2012-12-28T14:04:18-05:00 vcse tvcs: UTCTime="2012-12-28 19:04:18,307" Module="network.sip" Level="INFO": Dst-ip="199.19.190.28"  Dst-port="5061"   Detail="Sending Request Method=INFO, Request-URI=sip:199.19.190.28:5061;transport=tls, Call-ID=725ec032c2dbb7ed103691b94f93f0a9@199.19.190.28"

2012-12-28T14:04:18-05:00 vcse tvcs: UTCTime="2012-12-28 19:04:18,307" Module="network.sip" Level="DEBUG": Dst-ip="199.19.190.28" Dst-port="5061"

SIPMSG:

|INFO sip:199.19.190.28:5061;transport=tls SIP/2.0

Via: SIP/2.0/TLS 65.212.212.212:5061;egress-zone=DefaultZone;branch=z9hG4bK6e86c4a1d8f668f749c2e9a3cc8f1c9245361;proxy-call-id=5e792250-5121-11e2-8fd0-0010f31f1dca;rport

Via: SIP/2.0/TLS 172.20.108.10:5061;egress-zone=TraversalZone;branch=z9hG4bK9c2c171f0b72a145a6ae353c79b86d8e2911763;proxy-call-id=5e809986-5121-11e2-9501-0010f32102da;received=65.212.212.213;rport=11432;ingress-zone=TraversalZone

Via: SIP/2.0/TCP 127.0.0.1;branch=z9hG4bK4ce64a5b91d9db2d5ffc8d3190a0830a2911762

Call-ID: 725ec032c2dbb7ed103691b94f93f0a9@199.19.190.28

CSeq: 5 INFO

From: <>xxxx@vcs.company.com>;tag=98a2fd66e8bbf430

To: "user" <>user@jabber.com>;tag=199.19.190.28+1+584456d2+89d33662

Max-Forwards: 68

User-Agent: TANDBERG/4120 (X7.2)

P-Asserted-Identity: <>xxxx@vcs.company.com>

X-TAATag: 5e7923f4-5121-11e2-92c0-0010f31f1dca

Content-Type: application/media_control+xml

Content-Length: 193

11

|

2012-12-28T14:04:18-05:00 vcse sshd[11562]: Event="sshd" Module="openssh" Level="INFO" Detail="Set /proc/self/oom_score_adj to 0" UTCTime="2012-12-28 19:04:18"

2012-12-28T14:04:18-05:00 vcse sshd[11562]: Event="sshd" Module="openssh" Level="INFO" Detail="Connection from 125.152.148.11 port 44127" UTCTime="2012-12-28 19:04:18"

2012-12-28T14:04:18-05:00 vcse tvcs: UTCTime="2012-12-28 19:04:18,463" Module="network.sip" Level="INFO": Src-ip="199.19.190.28" Src-port="5061"   Detail="Receive Response Code=405, Method=INFO, To=sip:user@jabber.com, Call-ID=725ec032c2dbb7ed103691b94f93f0a9@199.19.190.28"

2012-12-28T14:04:18-05:00 vcse tvcs: UTCTime="2012-12-28 19:04:18,463" Module="network.sip" Level="DEBUG": Src-ip="199.19.190.28" Src-port="5061"

SIPMSG:

|SIP/2.0 405 Method Not Allowed

Via: SIP/2.0/TLS 65.212.212.212:5061;received=65.212.212.212;rport=25560;branch=z9hG4bK6e86c4a1d8f668f749c2e9a3cc8f1c9245361;egress-zone=DefaultZone;proxy-call-id=5e792250-5121-11e2-8fd0-0010f31f1dca

Via: SIP/2.0/TLS 172.20.108.10:5061;egress-zone=TraversalZone;branch=z9hG4bK9c2c171f0b72a145a6ae353c79b86d8e2911763;proxy-call-id=5e809986-5121-11e2-9501-0010f32102da;received=65.212.212.213;rport=11432;ingress-zone=TraversalZone

Via: SIP/2.0/TCP 127.0.0.1;branch=z9hG4bK4ce64a5b91d9db2d5ffc8d3190a0830a2911762

Call-ID: 725ec032c2dbb7ed103691b94f93f0a9@199.19.190.28

CSeq: 5 INFO

From: <>xxxx@vcs.company.com>;tag=98a2fd66e8bbf430

To: "user" <>user@jabber.com>;tag=199.19.190.28+1+584456d2+89d33662

Server: CISCO-SBC/2.x

Content-Length: 0

[Martin Koch]

Hi Darren!

It would be handy to get some more information about your deployment, maybe a drawing

showing how the setup looks like and how the call flows actually go through that drawing.

In general I can tell you the deployment should work fine, sure you could check if it behaves different if

you use for example the latest versions TC5.1.5, VCS X7.2.1, JabberVideo 4.5.

Unless you explicit changed the codec setup before I would expect that it would work out of the box.

The most likely reason I have seen so far are firewall issues, either that an application layer

gateway / nat helper (or any other kind of l3 "enhancement") was used, that a firewall simply

blocked ports.

[afadeyev1]

Hi Martin,

I saw an old tread and decided to continue instead of opening new one (see my previouse post).

My deployment is VCS-VCSE.

I doubt it's the firewall issue, because my expressway located outside, without any kind of restrictions.

Also, the only time when I can see the issue, is when I'm placing a call to\from public Jabber to the H.323-only endpoint provisioned by my VCS. All other possible scenarios work fine. Please look at the attached debug info.

[Patrick Pettit]

Hi. It seems the SBC may be rejecting INFO message from VCS. If your the owner or know the owner of the SBC, I would verify that the SBC would allow the INFO message to pass through so that the far end can send picture update for video to pop in. Just a hunch from what you posted. I would check there to see if this is the problem. Hope this helps.

VR
Patrick


Sent from Cisco Technical Support Android App

[Jens Didriksen]

As far as I can see, afadeyev1 is using the Cisco hosted version of JabberVideo since the domain is "jabber.com", and I didn't think this particular version allows for interworking?

I have, at least, never been able to properly connect this "free" version of JV to an h.323 only endpoint, I can however, connect to any endpoint with this client as long as SIP is enabled on the endpoint, regardless of the endpoint being registered with a SIP registrar or not.

JabberVideo (Movi), which is the "enterprise" version; which Darren asked about at the start, is a completely different story, for obvious reasons.

/jens

[Patrick Pettit]

HI Folks.  Can someone test this out and see of any changes? Make a call like Jens scenario perhaps, and if afadeyev1, if you make the same call as well, you notice any difference?

VR

Patrick

[Jens Didriksen]

Just tested with a 990MXP which is not registered to a GK nor a SIP registrar;

SIP on: call connects fine

SIP off: call denied

/jens

[Patrick Pettit]

Thanks Jens. Interesting, need to see further on that one.

You also seeing any interworking problems in the past with Free Jabber calling an H323 MCU or any other endpoint that is H323 like afadeyev1? That is registered to VCS C and Free Jabber traversing through your C and E??

VR

P2

[Jens Didriksen]

Yes, we did see some interworking problems in the past with "free" JV calls coming through our VCS-E, however, we have since turned on SIP on all of our systems and these are registered to VCS-C with both SIP and H.323 addresses, SRV records for SIP and H.323 are also in place - so no more problems.

/jens

[afadeyev1]

It’s working fine now.

Placed a call from Free Jabber to MXP with H.323 registration only via VCSE-VCS  and video goes both ways.

Same thing with H.323 only MCU.

Thank you.

[Patrick Pettit]

Awesome.  Thats good news.  Patch was applied very early this morning, so hopefully this will get some TAC cases out of my way.  Thanks for confirming for us.

VR

P2

[tec cou]

I've had problems with encryption, try to "off"