Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

H.323 to SIP interworking cause packet errors?

Hi All - another weird one: we have a neighbor zone with a customer that is SIP only. The calls in question are between my 5320 MCU and the customers CTS-3000.

-If I launch the call from the MCU conference as a H.323 call (3mbps) it connects fine, but the customer sees video artifacts/pixellation usually seen with packet loss. I see their video fine.

-If I launch as a SIP call, same bandwith, we experience good clear video in both directions.

This is very repeatable.

Why would this be? from our VCS-E to their endpoint should be exactly the same in both cases, yes?  Would the MCU be using a different video codec or something for aH.323 call vs a SIP call?

Thanks for any ideas on debugging.....

5 REPLIES

Re: H.323 to SIP interworking cause packet errors?

Hi John,

Can you check in the MCU what is the video codec negotiated and call rate for both calls, SIP and H323? Can you check in the side of the CTS endpoint as well? Are the video codec and call rate exactly the same?

Well, it is important to point that, Cisco does not recommend interworking in calls involving CTS/TX endpoints. The best practice is to avoid interworking for calls involving endpoints with TIP support.

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Re: H.323 to SIP interworking cause packet errors?

You say you are using a neighbour zone - note that the tips below don't apply if you are using a traversal zone because all media would be proxied;

If the call is H323 to SIP interworked, all media will be proxied via VCS.  If it's SIP to SIP, the media will flow straight from the MCU to the CTS.  It could be a packet loss/bandwidth/MTU issue between VCS and your MCU, or VCS and their CTS-3000 that doesn't come into play directly between the MCU and CTS unit.

While interworking between H323 and CTS isn't reccomended, my experience is that while there may be some issues, it's not usually packet loss but rather "weird" things with hold resume/presentation etc.  That is purely subjective though; others may have had different experiences.

New Member

H.323 to SIP interworking cause packet errors?

Hi All - the video codec and call rate are exactly the same for each type of call at the MCU. Since the MCU registers to the VCS-E (we don't have a VCS-C) I believe the call goes thru the Traversal zone enroute to the customer "neighbor" zone. Does that mean the media is "proxied"? What does tha mean exactly - is there transcoding? One thing odd- when I look a call Media Statistics in the VCS call log - it has an awful lot of "errors" - but thats in the video from them, which is fine. Just don't see those when we connect SIP-SIP. Of course, I don't understand most of what is in those "Call Media" info - what is DYNAMIC_96 protocol? and why is the rate so low?

TypeVideo
ProtocolDYNAMIC_96
Rate32139 bps
Packets forwarded3848317
Keepalives0
Errors3846101
Duplicate packets0
Lost packets0
Out of order packets0
Jitter1 ms
Fromsip:xxxxxx@vcs.nam.nsroot.net

Re: H.323 to SIP interworking cause packet errors?

Hi John,

Since the MCU registers to the VCS-E (we don't have a VCS-C) I believe the call goes thru the Traversal zone enroute to the customer "neighbor" zone. Does that mean the media is "proxied"? What does tha mean exactly - is there transcoding?

Well, in this case, when you have a SIP endpoint registered to VCS-E calling another SIP endpoint, this call will be proxied. That means, VCS will be simply a Media Termination Point for the call, but there is no transcoding, VCS only intermediate the signalling and the media as well. The same concept applies to call SIP to H323.

One thing odd- when I look a call Media Statistics in the VCS call log - it has an awful lot of "errors" - but thats in the video from them, which is fine. Just don't see those when we connect SIP-SIP.

Well, it is very hard to determine the cause of those errors without debuging. But, as I stated before, once Cisco does not recommend Interworking SIP/H323 involving CTS/TX endpoints, I wouldn't be surprise if any one experienced that kind of issue when using a not recommended method.

Again, it is highly recomended to avoid interworking for CTS/TX endpoints.

Of course, I don't understand most of what is in those "Call Media" info - what is DYNAMIC_96 protocol? and why is the rate so low?

TypeVideo
ProtocolDYNAMIC_96
Rate32139 bps
Packets forwarded3848317
Keepalives0
Errors3846101
Duplicate packets0
Lost packets0
Out of order packets0
Jitter1 ms
Fromsip:xxxxxx@vcs.nam.nsroot.net

Dinamic 96 refers to the RTP payload type. RTP protocol can carry many different types of video payloads, each payload type has a different number, normally a range from 96 to 127. If I am not wrong, 96 referes to H264 protocol. 99 is H263. 31 is H261 and so on, there are many types of video payloadscarried by RTP.

Just in case, what is the version of your MCU and the version of the CTS endpoint?

Regards

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

H.323 to SIP interworking cause packet errors?

Hello together.

It is always interesting to see some drawing and some more info regards the deployment.

Like nick mentioned.

Does the CTS > MCU call show up as a local / non traversal call or also as a traversal call?

The traffic flow of the media might behave different. So if the MCU is in a different network or

the vcs itself is the problem for the loss (defective cable, oversubscribed virtual session, different datacenter, ....)

that would be somethign to investigate.

You could also do a trace to see, does it happen in the network or is the loss already in the sending site

(like do a capgture upfront the vcs, mcu and the endpoint and compare what is send and whats received).

Paulo: dynamic is what its says dynamic :-)

http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml

If you have a non dynamic payload you could look at the RTP packet itself and by the payload

value you know what codec it is. For a dynamic payload packet you will need to look at some

higher level, like the SDP in SIP or h323/h245 to know what that payload is used for.

That some devices might use this or that value by default for specific codecs is an other point. :-)

Please remember to rate helpful responses and identify helpful or correct answers.

Please remember to rate helpful responses and identify

658
Views
0
Helpful
5
Replies
CreatePlease to create content