Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

Issue with double interworking SIP to H.323 to SIP


I have recently had problems with calls beeing disconnected after 15 minutes. I discovered that calls made locally on a customer video network (VCS Control and VCS Expressway on X8.1.1) was interworked from SIP to H.323 and back to SIP.

First scenario was external Jabber video users that did not meet autorization standards for membership rules (should be jhon.doe.movi but registered as john.doe due to findme error) was put in a sub zone that interworked their incomming SIP call to H.323. The call was then H.323 to the VCS Control, and was interworked back to SIP to a SIP only client registered on the VCS Control. It seems the SIP invite sent half way into the 1800 sec TTL was lost in translation. 

Second scenario was a similar event where an external customer called SIP internally, but for some reason it was interworked into H.323 before our customer recieved the call. The call hit the VCS Expressway as H.323 and was interworked back to SIP on the VCS Control to a SIP only device. Again double interworking where the call disconnected after 15 minutes. 


Why does this happen? Is it a BUG in the Cisco interworking feature?    


Please give a more verbose

Please give a more verbose description of the call flow and behavior.

Especially the search details for the interworked parts are interesting.

In general Interworking only happens on the last step if on each point of the path where noly one protocol is available and its different from the incoming call.


I would check if your search rules work as intended, which might also require that your

zones and other parts related to it are ok.

Also if there is anything fishy regards authentication, membership rules, ...


The behavior of h323 and sip regards policies for "authenticated" behave different,

I could assume that might be what your hitting here.


Also double check that the network/firewalls are ok. In theory if a call is on purpose interworked  multiple times it should not disconnect.




Please remember to rate helpful responses and identify

New Member

Hi!I think you are missing


I think you are missing the point. The point is that we from time to time encounter issues like the one above or where the call has been interworked at the remote party before it hits the local infrastructure. When it hits the local infrastructure it needs to be interworked again to be able to communicate with a internal SIP endpoint. This means the call is like this:


SIP --> H.323 (at remote site where they have issues with SIP on their traversal Zone) --> DNS --> H.323 --> SIP (local site). Here we have no control over the remote site. The call is interworked twice.


The call is disconnected because the SIP invite that is sent after 1/2 1800 sec is lost in translation. This must be a limitation in interworking or a bug. I realize that the remote site in this case has an issue somewhere, but I am not allowed to help them (different partner). 

VIP Purple

I had a similar issue in one

I had a similar issue in one of my environments, where the Jabber calls were dropping after about 30 seconds and there was lots of interworking.  The issue was the search rules and their order/priority - A quick re-order of a couple of rules fixed the issue.  That could be a good place for you to start your investigations.

Please remember to rate responses and to mark your question as answered if appropriate.

Please remember to rate responses and to mark your question as answered if appropriate.
CreatePlease to create content