Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Conductor XC2.2 and TMS 14.3 Automatic Connect

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?

Regards, Paul
Everyone's tags (4)
1 ACCEPTED SOLUTION

Accepted Solutions

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

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.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
39 REPLIES
Cisco Employee

Conductor XC2.2 and TMS 14.3 Automatic Connect

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

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

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.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
New Member

Conductor XC2.2 and TMS 14.3 Automatic Connect

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.

Regards, Paul
New Member

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

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?

Regards, Paul

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

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.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
New Member

Conductor XC2.2 and TMS 14.3 Automatic Connect

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!

Regards, Paul

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

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.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
New Member

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

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.

Regards, Paul

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

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.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
New Member

Conductor XC2.2 and TMS 14.3 Automatic Connect

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.

Regards, Paul

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

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.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
New Member

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

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.

Regards, Paul
Cisco Employee

Conductor XC2.2 and TMS 14.3 Automatic Connect

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

Thanks,

Guy

New Member

Conductor XC2.2 and TMS 14.3 Automatic Connect

Is the B2BUA working different than the VCS B2BUA?

Conductor and VCS has the same Software base, right?

Regards, Paul
Cisco Employee

Conductor XC2.2 and TMS 14.3 Automatic Connect

yes, Conductor and VCS have the same base, and the B2BUAs also share some common components (and developers). But the Conductor B2BUA is signalling only. Where as the VCS B2BUA could take media - for force encryption value of the sip media encryption setting on zones or subzones on the VCS for example.

Thanks,

Guy

New Member

Conductor XC2.2 and TMS 14.3 Automatic Connect

Ok thanks Guy and Paulo for that good discussion and detailed info!

Regards, Paul

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

Hi Paul,

Just to advise you, when using TMS 14.3 and Conductor XC 2.2, the recommended deployment model is the new B2BUA. Take a look at the release notes of the TMS 14.3:

Page 2 - http://www.cisco.com/en/US/docs/telepresence/infrastructure/tms/release_note/Cisco_TMS_release_notes_14-3.pdf

Furthermore, as I stated before, according to the Conductor's deployment guides, the CPL deployment model will be discontinued in a future release, then, as you are migrating your environment to Conductor now, I strongly recommend you to use the new B2BUA deployment model, so that you can avoid an effort in the future to migrate from the old deployment to the new one.

Of course, that's just my suggestion. I guess that is something worth to investigate.

Regards

Paulo Souza

Please rate useful replies and remember to mark any solved questions as "answered".

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
New Member

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

Hi Paulo,

now that I know, that only signaling will be sent to conductor, but not media traffic I like that deployment a lot, because it makes the config a lot easier. You only have the SIP trunk to Conductor and configure the conference handling all in one on Conductor.

Regards, Paul

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

Yeah! B2BUA deployment is the best! All of my customers are using that deployment.

Paulo Souza

Please rate useful replies and remember to mark any solved questions as "answered".

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
New Member

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

Hi,

I have in lab enviroment a TMS 14.3, VCS X7.2, Conductor XC2.2 and TS7010 (3.1(1.80))

I have configured the two deployments methods of Conductor: Policy Service and B2BUA and in my point of view the best deployments is B2BUA. The main decision is due to the Policy Services will be discontinued and other services that isn't working fine in tht Policy Service method.

Tha Scheduled Conferences go in this way: TMS-->Conductor-->TS7010-->VCS--> Endpoints. The conductor update the information in TMS and he is manage everything.

Ad hoc conferences is working fine.

I found some issues with the B2BUA deployment when I schedules conferences from TMS:

- Add IP directly from TMS Booking isn't working. To work around this issue you have to Add IP@DNS for example.

- The call from TS7010 or MCU are all SIP and my endpoints are all H.323 and VCS consumes Traversal Calls.

- The Preview in TMS isn't working. Monitoring>Conference Control center, enter into the conference and I can't see the Preview of the Endpoints. I have to enter directly into the MCU or TS to see if the enpoint is sending video...

If you have your endpoints deployed in H.323 E.164 Alias, I recommend you to migrate to SIP.

The best thing I could see is the port optimization.

Regards.

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

Hi Romero,

I will give a try in my lab what you mentioned.

Rgds

Alok

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

Hi Romero,

Most issues that you have pointed are expetected behavior when using B2BUA deployment model. Such as:

- Add IP directly from TMS Booking isn't working. To work around this issue you have to Add IP@DNS for example.

When scheduling Conductor via TMS, you can only set Conductor do dial out using SIP, as IP address is H323, TMS will probably not allow you to dial out IP address.

ma.romero escreveu:

- The call from TS7010 or MCU are all SIP and my endpoints are all H.323 and VCS consumes Traversal Calls.

That's an expected behavior, because B2BUA only allow SIP in the Conductor's side. As a matter of fact, the deployment guide states clearly that you have to use interworking in VCS in order to join H323 endpoints. For me, it is not a problem, once the default bundle of VCS Control comes with 100 traversall call licenses.

- The Preview in TMS isn't working. Monitoring>Conference Control center, enter into the conference and I can't see the Preview of the Endpoints. I have to enter directly into the MCU or TS to see if the enpoint is sending video...

I think this is really a strange behavior. I will try this in my lab to see what I get.

Well, in general, TMS+Conductor has some blind points yet, that's why the release notes of TMS 14.3 states that you have to consider the known limitations before implementing Conductor with TMS. See:

Starting on page 36 - http://www.cisco.com/en/US/docs/telepresence/infrastructure/tms/release_note/Cisco_TMS_release_notes_14-3.pdf

Regards

Paulo Souza

Please rate useful replies and remember to mark any solved questions as "answered".

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
New Member

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

Hi Paulo,

Yes, I know that this issues were expected in these versions of TMS and Conductor. But I hope to resolve as soon as possible.

Too, I found another issue: in conference control center when the endpoint is connected to the meeting I can't check the Video/Audio features or the connection protocol (appears as unknown) negotiated in the call.

Regards.

Cisco Employee

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

[...] in conference control center when the endpoint is connected to the meeting I can't check the Video/Audio features or the connection protocol (appears as unknown) negotiated in the call. [...]

Hi,

This sounds like Conductor limiation CSCuj04565.

Regards,

Kjetil

New Member

Re: Conductor XC2.2 and TMS 14.3 Automatic Connect

Yes. Thanks.

Regards.

New Member

Conductor XC2.2 and TMS 14.3 Automatic Connect

Hi All,

It is from this answer not clear whether the auto reconnect now works with the tms server and conductor. I have the same problem that a 5679e2bdf-245bf-23453-ba46-efddvfvrcc1@1.1.1.1 addresse: 5073 is chosen does not find about the VCS Control . It all works well until the auto  connect with the TMS server. The endpoints are not automatically connected, if i scheduled a conference with couple of endpoint with the conductor and external dial out participants.

Thanks for your feedback

P.s i have also configuraed the B2BUA

New Member

Conductor XC2.2 and TMS 14.3 Automatic Connect

Hi,

it works fine for me now. I configured a new installation with B2BUA and a SIP trunk from VCS to Conductor. The MCU/TS are not configured to use VCS but to use direct calling.

If you follow the Conductor B2BUA Deployment guide it should work fine. All necessary settings are shown there.

BR Paul

Regards, Paul
New Member

Conductor XC2.2 and TMS 14.3 Automatic Connect

Hi Paul,

I have kept even after the manual. It works well so far everything except the auto connect from the TMS server. The invitation comes on the endpoint but not the call comes about because the VCS C try the string

reconnect now works with the tms server and conductor. I have the same  problem that a 5679e2bdf-245bf-23453-ba46-efddvfvrcc1@1.1.1.1 addresse:  5073 .. can not be found.

I deployed like the B2BU2 deployment guide

Conductor XC2.2 and TMS 14.3 Automatic Connect

Hi Rasim,

It works for me too. There is a problem with external dial out participant though. 

Rgds

Alok

2582
Views
20
Helpful
39
Replies
CreatePlease to create content