Unified Communications Development - All Comments

re: Transferring calls in UCMA 2.0, part one

mgreenlee — Thu, 07 May 2009 15:14:27 GMT

Hi Andi,

Yes, you're expected to implement your own logic to handle transfers, forwards, etc. in any applications you create. Aside from testing (like what you're doing), UCMA 2.0 isn't usually meant for client applications, and things like initiating a new call in response to a REFER aren't built in. In theory you might want to do something different when your application gets a REFER.

Thanks for sharing all the details of your investigation! This is definitely useful info.

Michael

re: Transferring calls in UCMA 2.0, part one

Andi — Thu, 07 May 2009 10:55:58 GMT

hi,

ok, news of my exlorations:

void AvCallTransferReceived(object sender, AudioVideoCallTransferReceivedEventArgs arg)

{

AudioVideoCall newAvCall = arg.Accept(null);

newAvCall.BeginEstablish((result) =>

{

newAvCall.EndEstablish(result);

}, null);

}

found in the SDK and tested. works well, also for self-transfers. hope that these posts help other devs, so that you can safe the time intensive try-and-errors.

other points for which we invested extensive exploration to understand how they work:

- to handle forwards (i.e. 302 moved temp) you must register a method at the event Forwarded before you invoke BeginEstablish() -> analogous to transfer)

- the first 180 ringing message is sent back to the caller AFTER the callback-method (which is registered at the endpoint with RegisterForIncomingCall<AudioVideoCall>()) is processed. I made the mistake to accept the call synchronous (in a lab/test-environment) with call.EndAccept(call.BeginAccept(null, null)); -> so the caller never get the 180 ringing. accpet async, also in labs!

andi

re: Transferring calls in UCMA 2.0, part one

Andi — Thu, 07 May 2009 08:22:28 GMT

Hi again,

You must register a method to the event TransferReceived BEFORE invoking BeginEstablish. This marks the call as AllowTransfer=true and the RemoteParticipant can apply a transfer. Have you experience in receiving the transfer (in an user-endpoint)? The registered method is called an there i invoke arg.Allow(null); This causes the 202 Accepted after the REFER. But the Receiver of REFER does not initiate a new call. Should I kick off this manual in the TransferReceived-Callback-Method? Or does the UCMA-Lib this for me?

greets

re: Transferring calls in UCMA 2.0, part one

Andi — Wed, 06 May 2009 22:09:31 GMT

Hello Michael,

We're working on an UCMA2-product (an application-endpoint) and a test-server which allows us testing/observating the product's behaviour (the latter is realized with user-endpoints to simulate sip-participants). Now, the user-endpoints should be able to handle a transfer. When i initiate a transfer on a call which remoteEndpoint is one of the test-server's user-endpoint, the BeginTransfer of the transfer-initiator fails with an InvalidOperationException. After a few minutes/hours research i noticed, that the user-endpoint doesn't allow transfers. I've not yet found a way to enable the user-endpoint for transfer-handling. I set

RegisterMethods = "INVITE,MESSAGE,INFO,OPTIONS,BYE,CANCEL,NOTIFY,ACK,REFER,BENOTIFY"

on the userEndpointSettings, but this didn't change the situation. I've seen also that there exists a Property "RemoteEndpointProperties" on the avCall which contains again a Property "AllowTransfer = false".

Have you any hint how i switch on the transfer ability on user-endpoints? Thank you for any idea!

best regards, andi

Transferring calls in UCMA 2.0, part one

Unified Communications Development — Tue, 14 Apr 2009 18:55:07 GMT

College students, like very small children, are easily entertained. Back in my college days, I always

Blogs I Heart: Michael Greenlee’s UCMA Blog

Chris Mayo's Blog - Unified Communications Development — Fri, 03 Apr 2009 22:19:51 GMT

While watching progress bars during the setup of my TS box for the Fabrikam VMs, I thought I’d catch

re: How to publish presence using UCMA v2.0 and have a clever Communicator status

Peter — Wed, 01 Apr 2009 19:17:49 GMT

Yes, thats what I thought wrt. the director FQDN.

re: Subscribe to presence in UCMA v2.0

mgreenlee — Wed, 01 Apr 2009 13:35:30 GMT

Thanks, Thor! I wasn't aware of those classes for specific presence categories, and can't find them documented anywhere. How did you find out about them?

re: How to publish presence using UCMA v2.0 and have a clever Communicator status

mgreenlee — Wed, 01 Apr 2009 13:34:24 GMT

I believe you should use the FQDN of the server that is functioning as a Director.

Does this answer your question?

re: Subscribe to presence in UCMA v2.0

Thor Halvor — Wed, 01 Apr 2009 12:35:44 GMT

Here is a tip for you:

Instead of writing alot of code to understand the rawXml from the Category, you can write this:

foreach (PresenceCategoryWithMetaData category in notification.Categories)

{

PresenceState state = PresenceState.Create(category);

and "State" got all the info you want. :)

re: How to publish presence using UCMA v2.0 and have a clever Communicator status

Peter — Tue, 31 Mar 2009 20:02:22 GMT

How will this work with a enterprise edition deployment with directors? What server should be entered as the OCS server in the UserEndpointSettings?

re: Installing a certificate for UCMA v2.0 applications

Rasmus — Mon, 30 Mar 2009 13:34:19 GMT

Excellent walkthough. Exactly what I was missing to be able to debug my OCS app.

re: Troubleshooting TLSException in UCMA 2.0 applications

thalvor — Fri, 27 Mar 2009 09:15:45 GMT

Ahh that is the reason!! thank you... I didnt "run as admin"...

perfect that you added this blogpost 2days ago :)

- keep up!

re: How to publish presence using UCMA v2.0 and have a clever Communicator status

mgreenlee — Wed, 25 Mar 2009 01:20:40 GMT

Jorge,

Thanks for the correction -- I haven't seen that issue myself yet. I'll incorporate your suggestion into my code. Thanks for pointing that out.

Michael

re: How to publish presence using UCMA v2.0 and have a clever Communicator status

mgreenlee — Wed, 25 Mar 2009 01:18:43 GMT

Marten,

To publish presence on behalf of other users, you could establish a UserEndpoint for each user whose presence you want to publish. You could then use the LocalOwnerPresence instance associated with each UserEndpoint to publish presence for that user.

Does this sound like it would cover what you're trying to do? If you give me some more details of what you have in mind, I can explain further.

Michael