H.323 to SIP interworking cause packet errors?

[John Shur]

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.....

[Paulo Souza]

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.

[Nick Halbert-Lillyman]

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.

[John Shur]

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?

Type	Video
Protocol	DYNAMIC_96
Rate	32139 bps
Packets forwarded	3848317
Keepalives	0
Errors	3846101
Duplicate packets	0
Lost packets	0
Out of order packets	0
Jitter	1 ms
From	sip:xxxxxx@vcs.nam.nsroot.net

[Paulo Souza]

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?
Type
Video
Protocol
DYNAMIC_96
Rate
32139 bps
Packets forwarded
3848317
Keepalives
0
Errors
3846101
Duplicate packets
0
Lost packets
0
Out of order packets
0
Jitter
1 ms
From
sip: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.

[Martin Koch]

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.