08-07-2013 06:12 AM - last edited on 03-25-2019 09:09 PM by ciscomoderator
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?
Solved! Go to Solution.
08-07-2013 05:57 PM
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.
08-07-2013 12:31 PM
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
08-07-2013 05:57 PM
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.
08-08-2013 12:11 AM
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.
08-08-2013 12:29 AM
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?
08-08-2013 03:13 AM
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.
08-08-2013 03:23 AM
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!
08-08-2013 03:25 AM
It seems you have a different deployment. Have you implemented your devices by following the documentation? I would point some considerations:
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.
08-08-2013 03:32 AM
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.
08-08-2013 03:44 AM
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.
08-08-2013 04:56 AM
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.
08-08-2013 05:36 AM
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.
08-08-2013 06:13 AM
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.
08-08-2013 07:31 AM
Media should not go through Conductor with B2BUA - only the signalling.
Thanks,
Guy
08-08-2013 07:37 AM
Is the B2BUA working different than the VCS B2BUA?
Conductor and VCS has the same Software base, right?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide