Conductor XC2.2 and TMS 14.3 Automatic Connect

[Paul Woelfel]

Hi,

I also saw a topic about the current beta versions Conductor XC2.2 and TMS 14.3, so I'll post my question here.

I'm using conductor with VCS, CUCM, MCU 4505 and TS. I'm able to create AdHoc conferences via CUCM and VCS and scheduled calls via TMS.

If I create a conference with automatic connect and the conductor in the call I can see that the MCU or TS tries to reach a participant, but not with the correct URI. It should use my email address (findme ID) to call me, but instead it uses some strange URI: 009a8bb3-ac2c-4bc1-8b02-4e4b52c171e2@1.1.1.1:5073

1.1.1.1 is the IP of the conductor. About the part before @ I do not know where it comes from, but it looks like an internal ID.

This are the logs from the MCU for an test conference with one participant to be connected automatically:

13:38:05          API          admin          /HTTP/TCP/1.1.1.1:38141          Info          Konferenzen: "Videokonferenz 101" erstellt

13307          13:38:05          API          admin          /HTTP/TCP/1.1.1.1:38141          Info          Konferenzen: Konferenz [Videokonferenz 101], numerische ID gesetzt auf "88800010"

13308          13:38:05          API          admin          /HTTP/TCP/1.1.1.1:38141          Info          Konferenzen: Konferenz [Videokonferenz 101], PIN gesetzt auf "114"

13309          13:38:05          API          admin          /HTTP/TCP/1.1.1.1:38141          Info          Konferenzen: Konferenz [Videokonferenz 101], Gast-PIN gesetzt auf "114"

13310          13:38:05          API          admin          /HTTP/TCP/1.1.1.1:38141          Info          Konferenzen: Konferenz [Videokonferenz 101], Sichtbarkeit "öffentlich"

13311          13:38:05          API          admin          /HTTP/TCP/1.1.1.1:38141          Info          Conferences: conference [Videokonferenz 101] content mode set to "Transcoded"

13312          13:38:05          API          admin          /HTTP/TCP/1.1.1.1:38141          Info          Konferenzen: Konferenz [Videokonferenz 101] Stummschaltung bei Teilnahme [Audio=deaktiviert]

13313          13:38:05          API          admin          /HTTP/TCP/1.1.1.1:38141          Info          Konferenzen: Konferenz [Videokonferenz 101] Stummschaltung bei Teilnahme [Video=deaktiviert]

13314          13:38:05          API          admin          /HTTP/TCP/1.1.1.1:38141          Info          Konferenzen: Konferenz [Videokonferenz 101], Layoutsteuerung über FECC/DTMF "Use FECC and fallback to DTMF"

13315          13:38:05          API          admin          /HTTP/TCP/1.1.1.1:38141          Info          Konferenzen: Konferenz [Videokonferenz 101], Maximale Dauer gesetzt auf "permanent"

13316          13:38:05          API          admin          /HTTP/TCP/1.1.1.1:38141          Info          Konferenzen: Konferenz [Videokonferenz 101], Ende gesetzt auf "kein Enddatum"

13317          13:38:05          API          admin          /HTTP/TCP/1.1.1.1:38141          Info          Conferences: conference [Videokonferenz 101] auto delete timeout set to "600 seconds"

13318          13:38:06          API          admin          /HTTP/TCP/1.1.1.1:38141          Info          API-Endpunkt-Einstellungen: Endpunkt [e922d880ee1854c242ba94e69b113af :: 00e98127-6564-4136-b0d7-bcca3c5076a4@1.1.1.1:5073] via API zu Konferenz "Videokonferenz 101" hinzugefügt

13319          13:38:06          API          admin          /HTTP/TCP/1.1.1.1:38141          Info          API-Endpunkt-Einstellungen: Endpunkt [3805 :: 009a8bb3-ac2c-4bc1-8b02-4e4b52c171e2@1.1.1.1:5073] via API zu Konferenz "Videokonferenz 101" hinzugefügt

13320          13:38:36          API          admin          /HTTP/TCP/1.1.1.1:38149          Info          API-Endpunkt-Einstellungen: Endpunkt [3806 :: 77e51d22-2239-483a-9e6d-2c8baa1ee1ae@1.1.1.1:5073] via API zu Konferenz "Videokonferenz 101" hinzugefügt

Unfortunatetly the logs are in german, but I think you can see that there is some strange URI added.

If I create a conference without conductor the log shows the correct URI:

13386           14:07:14           API           admin           /HTTP/TCP/172.21.10.12:52001           Info           API-Endpunkt-Einstellungen: Endpunkt [Paul Woelfel :: paul.woelfel@nts.eu] via API zu Konferenz "1234 - Videokonferenz 8/7/2013 " hinzugefügt

1.1.1.1 is the conductor IP (of course not the real IP ;-))

Has anyone testing the latest versions also expirenced that issue?

[Patrick Pettit]

Hi Paul.  What RC version you running for TMS and Conductor?

This looks like an audit log from MCU, so tried this in my lab against a 4205 MCU I'm using:

This is from my MCU. 

So I guess I'm curious to how your seeing this, especially in the audit log from the MCU.  Let me know?

VR

Patrick

[Paulo Souza · Accepted solution]

Hi Paul,

Are you using Conductor and VCS B2BUA deployment?? If yes, this behavior is correct. MCU should not call the endpoint directly, MCU should dial a unique URI of Conductor, something like 009a8bb3-ac2c-4bc1-8b02-4e4b52c171e2@1.1.1.1, so Condcutor will take this URI and forward the call to VCS replacing that strange URI by the correct SIP destination URI according to what you scheduled.

But in order to have it working, MCUs should not be registered to VCS, MCU should only be integrated with Conductor, without SIP and H323 registration to VCS.

Can you confirm what kind of deployment you have? How is the integration between your MCU and Conductor?

Regards

Paulo Souza

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

[Paul Woelfel]

Hi Paulo,

no I'm not using the B2BUA deployment. I want to reach the MCUs direct, because conferences are booked directly. In future, all conferences should use the conductor, but not for now.

I created a Neigbour Zone to Conductor, but disabled them for now.

Which setting affects the generation of outbund dial URIs? I can't find a setting, which tells conductor to translate the URIs to that special ID.

[Paul Woelfel]

I think I found the setting:

I added the Location to the Bridge Pool. After setting it to none, a MCU dial out works fine, but I still have an issue with the TS:

From the Log TS tries to call out:

onference "Conference 100" created

9414          09:21:56.344           APP          Info          call 57: new outgoing SIP call to "paul.woelfel@nts.eu"

9415          09:21:59.351           SIP          Error          Ending call due to network error during INVITE transaction

9416          09:21:59.351           CMGR          Info          call 57: disconnecting, "paul.woelfel@nts.eu" - network error

9417          09:21:59.351           APP          Info          call 57: tearing down call to "paul.woelfel@nts.eu" - destroy at far end request; networkError

9418          09:22:26.613           APP          Info          call 58: new outgoing SIP call to "paul.woelfel@nts.eu"

9419          09:22:29.621           SIP          Error          Ending call due to network error during INVITE transaction

But neither on the VCS or on the TS itself I can see a SIP INVITE in the debugs.

On TS I configured the SIP Trunk to VCS and also a Neighbour Zone on VCS.

I can also see the OPTIONS ping on VCS an TS

Any idea what could be wrong, so TS does not dial out over that trunk?

[Paulo Souza]

Hi Paul,

Regarding MCU, if you are booking MCU in TMS directly without Conductor, you should not have this MCU add to any conference bridge pools in Conductor, because if you do so, TMS will understand that this is a MCU managed by customer, thus TMS may try to ask Conductor to initiate the call out, so Conductor will invoke MCU to call through itself.

With regards TP Server, this is my opinion: I don't think you should use Trunk, you should use register instead when integrating to VCS. I think you are receiving this error because maybe TS is try to send the INVITE message to the destination directly, without using VCS, that's why you see a network error.

Regards

Paulo Souza

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

[Paul Woelfel]

With TS 3.1(1.82) there is only the option to either use "call direct" or "use trunk"

I found the issue, it was a typo in the SIP trunk. Now it is working fine, TS is dialing out.

I tried the scenario you mentioned, that Conductor may call instead of the MCU, but the calls are always initiated by the MCU or TS. If Conductor is added to a conference, conductor will instruct the TS/MCU to dial out, otherwise the TMS will instruct MCU/TS itself.

Thanks for your help!

[Paulo Souza]

It seems you have a different deployment. Have you implemented your devices by following the documentation? I would point some considerations:

• If you want to reach MCUs and TS diretctly, you should not add them to Conductor
• If you want to use Conductor to manage MCUs and TS, you should implement the B2BUA deployment, therefore MCUs and TS wont be integrated to VCS directly, they will only communicate to Conductor
• If using Conductor B2BUA deploymen to manage your MCUs and TS, when scheduling, you must to select Conductor as MCU and not the MCU directly

In my opinion, there is not reason to have Conductor if you invoke your multipoint resources directly, either using scheduling via TMS or AdHoc. If you want to have Conductor to manage your MCUs and TS, then you should implement B2BUA deployment.

Paulo Souza

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

[Paul Woelfel]

We want to use conductor, because we want to attach the MCU to VCS and CUCM. We want to use it for AdHoc and scheduled conferences.

It is also possible to connect the TS/MCU to VCS and not directly to Conductor. This makes sense, if you have MCU/TSs distributed over your network and want to use one conductor for distributed MCUs.

As said, we are currently moving from a deployment without conductor to one with, so the best option is to migrate slowly with MCU/TS connected to VCS.

[Paulo Souza]

Hi Paul,

Now I understand, you are migrating to a Conductor deployment slowly, it answers my question.

I personally would suggest you to look for integrating Conductor to VCS by using B2BUA deployment, because according to Conductor's documentation, this is the recommended method, because the old method (integrating via Policy service) will not be supported in the future, therefore you can avoid an additional effort in the future to migrate from the old deployment to the new one, B2BUA.

Good luck!

Regards

Paulo Souza

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

[Paul Woelfel]

Hmm, that's new to me and doesn't make much sense. Conductor supports up to 30 MCU/TSs. If you calculate 40 ports per MCU that would be 1200 calls. As far as I know, B2BUA on VCS supports up to 100 calls. So we would need 12 Conductors for such an installation. Without using B2BUA media could be routed directly between the endpoints and MCU/TS, so this reduces the number of conductors.

I think using CPLs is a much more scaleable deployment, than using the B2BUA.

[Paulo Souza]

Hi Paul.

I understand your point, but your logic is not entirely correct. In both deployments, you will use VCS to route calls to Conductor/MCUs/TS. So if you need to escalate the number of calls, you just need to raise a cluster of VCS, it is not required to buy additional Conductors.

Regarding CUCM registered endpoints, either using CPL or B2BUA, you can integrated the same Conductor to CUCM directly without using VCS, then you will be able to make calls to Conductor normally without use resources of the VCS. Of course, this is not applied to scheduled conferences.

Regards

Paulo Souza

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

[Paul Woelfel]

Of course you will have to have multiple VCS, but not as much as Conductors, because internaly the calls should be non-traversal. If you deploy Conductor and your MCU/TS with the B2BUA from Conductor, all calls have to be routed through conductor, even the media traffic. So conductor has to also handle the RTP streams. That's the reason I believe you will reach a limit with 100 calls / conductor.

I connected conductor directly to CUCM for AdHoc calls, as well as over a SIP Trunk from CUCM to VCS for scheduled conferences.

[gubadman]

Media should not go through Conductor with B2BUA - only the signalling.

Thanks,

Guy

[Paul Woelfel]

Is the B2BUA working different than the VCS B2BUA?

Conductor and VCS has the same Software base, right?