RNIS call with MOVI via ISDN Gateway : impossible

[emmanuel fressange]

Hi,

Here is my configuaration :

* VCS Expressway with Gateway TAndberg-Cisco 3241 software 2.0(1.40)P registred top it

* VCS Control where the MOVI client is registred

* GAteway prefixe : 90

So from MOVI, i have to call 900123456789 where 0123456789 is the ISDN number

But call is impossible :

* Search is good

* the gateway receive and compose the right number

* You can see the different ISDN chanel mounting during dialing

--> when call setup is finished and the call with media is about to begin , the call is disconnected .

--> Error message in Gateway : gatekeeper error

--> Error message in VCS Expressway : see pictures included (Errror 403 forbidden AND  No permission Interworked Insuffient privilege)

Pictures : rnis vcs.jpg --> VCS Expressway

rnis vcs Control --> VCS Control

From an H323 client the same call is OK (same VCS used)

Thanks for some advices

Best Regards

[Andre Lavoie]

Hi ,

I have the exact same problem over here at my end.  Anyone found a fix for this?

Thanks!

[Patrick Pettit]

HI Emmanuel - Curious here, the GW is registered to the Expressway?  Or is the GW registered to the Control. Normally would see this on the control versus Expressway.  Any CPL in place to prohibit the call coming FROM the ISDN GW side? 

If the GW is on the Control, does it work?

I have MOVI 4.4 with GW 2.1(1.49)P running, and I don't have a problem interworking SIP to H323 video call via ISDN GW.  Can you confirm the configuration? 

Andre - Is your setup the same as well?

Would either of you entertain running the current release if possible?

VR

Patrick

[Andre Lavoie]

Hi Patrick,

Thanks for taking the time to test this out.  I will give you more details.  When the endpoint (an EX90 that is SIP registered to the VCS control) calls out with, in our case the prefix 8 for video calls, the call does reach the GW (H.323 registered to the Expressway).  In fact when tested with another ISDN GW at the far end, I do get to their auto attendant without problems.  When I dial an verified alias on that same attendant, I do get connected, however as soon as I get video the call drops.  The VCS-e states Errror 403 forbidden No permission Interworked insufficient privilege, while the VCS control while have error 481 Call leg/Transaction Does not exist.  This is probably due to the fact that the call gets cleared by the Expressway before the Control gets to know about it.  The call log from the GW shows that everything went fine and the call was normally cleared.

Here is when this gets interesting.  Following the same path, but this time making the call natively in H.323 (EX90 registered to the VCS control) the call goes trough without any issues.  We also do not have any problems connecting incoming calls to our tpserver who is registered to the vcs expressway.  Interworking appears to be the culprit. 

The only CPL that are running on the Expressway are the ones supplied in the latest VCS configuration guide (X7.1).  That was my first attempt at solving this, I turned the CPL`s off, even tough none of the CPL will return a 403 Forbidden with details No permission insufficient privileges.

I also did another test, which was registering a Movi client to our Expressway( a different one then the one mentionned above)  that sits in a DMZ, and attempting the same call.  It worked flawlessly.

Any clues on what is going on here?

Thanks for the help!

[Tomonori Taniguchi]

Does ISDN Gateway registered on VCS as both H323 and SIP device?

If only H.323 registration, do you have search configuration on VCS pointing to ISDN Gateway but remove domain (process as interworking call)?

Example search rule for stripping SIP domain

===================================

Mode: Alias pattern match

Pattern type: Regex

Pattern string: (90)(.*)@

Pattern behavior: Replace

Replace string: \1\2

===================================

[Patrick Pettit]

HI Andre - This one will probably require some tracing to be completed.  It may be best to open a TAC case to gather some traces, and the xconfiguration of both VCS's and xstat's from both the control and the Expressway.  May also need network log set to debug as well to see the communications between VCS control and Expressway. 

Sorry can't provide a direct answere here as to why this occurring.  I'm going to try and downgrade my ISDN GW to 2.0(1.40)P to see if i see the same thing here with Expressway on X7.1.  Will keep you posted.  But if you decide to open TAC case for this, Private Message me the case number, and would like to check it out if possible. 

Sorry this doesn't help right now, but really hard to ascertain as to what is going on unless we see your configuration of VCS E and C, and it may require traces as well. 

VR

Patrick

[Andre Lavoie]

Hi Patrick,

Thanks again for the reply, I just opened a TAC case and I will send you the number via private message.  I did forget to tell you that the ISDN GW is running the following: Software version 2.1(1.43)P, build B.4>8(1.43)P

Andre

[Patrick Pettit]

Thanks Andre.  If you can, when you open:

Control and Expressway (Where endpoint and ISDN GW is registered to) - xcon and xstat

On Control and Expressway - Maint>Diagnostics>Diagnostic Logging - Set network log level debug on C and E.

ISDN GW - Settings>upgrade and download configuration.xml file.  Also, Logs>H323 Log.  Enable to capture information at the GW.  Clear the event log if you can prior to making the call, so we can take a look there as well. 

Will be looking out for the case. 

Thanks again. 

VR

Patrick

[Patrick Pettit]

Hi Andre.  You may be running into CSCua49148 which is resolved in X7.2. 

Here is what we are thinking:

When the GW sends a H245 message for Fast Update Request, this gets interworked to SIP INFO message and sent back to the Control.  When this happens, the VCS C challenges it, and the Expressway keeps trying to challenge it until it fails. 

Also, this happens on INVITE requests as well.  When the GW sends and update Terminal Capability Set to VCS E, this in turn gets re-worked to SIP INVITE with SDP.  This is also challenged at the Control.  When the challenge occurs, it keeps getting turned down and eventually your call will fail. 

VCS should include P-Asserted Identity when the H323 device is registered to expressway in a subzone which is treat as authenticated.

This is resolved in X7.2.  Going to be giving this a shot in my lab later this afternoon to see the outcome.  You may want to upgrade the Expressway to X7.2 as there is a MOVI CDR problem in X7.2.  But if your getting Movi CDR's from the Control, this shouldn't be an issue on the Expressway. 

I believe thats what is happening here in your case.  Will send you an email to your case if you wish. 

VR

Patrick

[Jens Didriksen]

Just be aware that there are other log issues in x7.2 as well, see

https://supportforums.cisco.com/message/3732826#3732826

I'm also curious as to why the GW is registered to the VSC-E instead of VCS-C ?

/jens

[Martin Koch]

Patrick/Emanuel: An easy way to confirm that should be to set the traversal/neighbor zone on the VCS-C  to treat as authenticated.

Patricks thought sound reasonable as the h323 setup seems to work fine, but please update the case on what your issue is and how you solved it.

Jens: Maybe they want registered users on the expressway to use the isdn gw. Why do you wonder (Security/Networking/Deployment/...)?

It must not be least secure then having it connected to the VCS-C. Besides that I have also seen internal vcs-e deployments or private isdn networks.

Anyhow if the ISDN GW is connected to the public isdn network I would be double careful regards possibly security issues and unwanted dialouts!

If I see it right the isdn gw does not support h460.18 so media traffic might in some cases directly go from/to the gw.

[Martin Koch]

Btw, I noticed that you use TCP for the traversal zone, this is more likely to have issues if

you have a ALG/inspection/NAT helper (which are known to cause trouble anyhow and should

be disabled).

I would set this to TLS anyhow so you get proper encrypted SIP calls through your traversal zone.