CWA is not able to dial RRS feed

  • Question

  • Good evening,
     my adventure in configuring OCS is at a good point, but I'm still having some problems that I'm not able to figure out.
    The last of these is a problem with the CWA. Basically when I select the "Join Conference Now Using..." once joined a conference through the "Join using the web browser" and add a phone number this is not called.
    I do not have this issue with the Office Communicator thick client, that dials without any problems, nor do I have problems dialing from a fixed phone to a user connected through the CWA.
    When having a look at the logs I see the following differences:

    Office Communicator Client: 

    To: <sip:218;phone-context=italy_parma@webconference.com;user=phone>

    Office Web Access

    To: <sip:+218@webconference.com;user=phone>;

    Now I realize that the thick client uses the normalization rules in the address book "on the fly" before dialing in, while this does not seem to happen for the CWA. Checking the SipTrack logs it would seem that a '+' is put in front of the number, and no location_profile is considered. At that point I added a number starting with my international code, having the + added (so from the logs the number was correct), but still no dialing happened.


    TL_INFO(TF_PROTOCOL) [0]0178.2214::07/16/2010-15:33:56.690.00001615 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record Instance-Id: 00000229 Direction: outgoing Peer: FRONTEND.webconference.com:4608 Message-Type: response Start-Line: SIP/2.0 404 Not Found From: <sip:sasa.maric@webconference.com;gruu;opaque=app:conf:audio-video:id:3814A82809A34ED0958CFDB60957BDF>;tag=8eff9b36;epid=FF76905F85 To: <sip:+218@webconference.com;user=phone>;epid=802411D2D2;tag=94807075df CSeq: 16 INVITE Call-ID: 0bfa1b80-cc36-4cca-88bf-0c1351247a89 Via: SIP/2.0/TLS;branch=z9hG4bK2e821b92;ms-received-port=4608;ms-received-cid=2300 CONTENT-LENGTH: 0 SERVER: RTCC/ MediationServer Ms-diagnostics: 10404;source="MEDIATION.webconference.efsa";reason="Gateway returned a SIP failure code";component="MediationServer";SipResponseCode="404";SipResponseText="Not Found";GatewayFqdn="" Message-Body: – $$end_record

    Some more information on my environment: I've a SIP Trunk configured on a CUCM 6.1
    This trunk is working and using the thick client we have no problems in dialing, nor do we have problems dialing to a authenticated user
    on logged with the web client, but from the web client we are not able to have ourself dialed in, even if we are authenticated.

    Any help is really appriciated!


    Friday, July 16, 2010 4:36 PM

All replies

  • Hello all, any idea on this issue?

    He is able to dial OCS user extentions inside, but no other number.
     On the web there is some documentation regarding the fact that the CWA does not respect the Normalization rules priority, and they suggest to delete them all and recreate them in the order you want them to be used. But I still get the issue (tonight I'll remove the disks and update everything with the April 2010 patch that should resolve this).


    Thanks again,


    Tuesday, July 20, 2010 9:51 AM
  • Did you install the patches and see if that fixed the issue?
    Randy Wintle | MCTS: UC Voice Specialization | Winxnet Inc
    Tuesday, July 27, 2010 12:54 PM
  • Hi Randy,


    thanks for the interest. A few things have changed. It still does not work after the updates of April. I really do not know what to do now. If I have the user insert "0xxxxxxxxx" it works, because he sends to the call manager the correct string and the call manager knows that with a 0 it has to be stripped off to go out. All normalization rules are ignored for guest users (as an authenticated user he applies the normalization settings for me, so if I dial +39xxxxxxxx he changes the +39 with a 0 and sends it to the call manager) :(


    Have I missed something?



    Wednesday, July 28, 2010 4:31 PM
  • Okay, so if I understand you correctly...


    If you insert a 0 before, and the number gets sent without a + in front of it, it works fine?


    So your call manager is only accepting numbers that begin with 0?

    Does that make sense?



    Randy Wintle | MCTS: UC Voice Specialization | Winxnet Inc
    Wednesday, July 28, 2010 10:43 PM
  • Hi Randy,
     My call Manager accepts three types of numbers:

    XXX >> Internal Number, it does not go to the VGW and pass on the PSTN but the call manager signals the internal phone.
    70XX >> Internal Numbers, assigned to the SIP Trunk for OCS (the 7000 are our Conference Assistant numbers)
    0XXXXXXXXXX >> All numbers that start with 0 get to the call manager that strips it off and send it to the VGW and to the PSTN.

    For this reason I have the following Location Profile defined:

    For the 70XX: ^(70\d{2})$ >> +39AreaCodeInternalPrefix$1

    For the XXX: ^([0-9]{3})$ >> $1

    For the 0XXXXXXXXXX (Italy): ^\+39(\d*)$ >> 0$1

    For the 0XXXXXXXXXX (International): ^\+(\d{1}\d+)$ >> 000$1

    These translation rules do work, in fact the Location Profile assigned to Internal Users (registered users) is applied when using the CWA. This is not the case when a user is a Guest/Anonymous user.


    My User case is the following:

    We have two users, REGISTERED user and ANONYMOUS user. REGISTERED user created an Audio Conference and send the e-mail with the link to join to ANONYMOUS user. 
     Both users access the Audio Conference connecting with the browser (CWA). Once the Browser client opens the REGISTERED user clicks on "Join Conference >> Call me at..." and puts in his number. He puts in +39XXXXXXXXXX. The CWA sends this number to be dialed, applies the transformation rule number 3, strips off the +39, puts in front the 0, so sends to the Call Manager 0XXXXXXXXXX. The Call Manager sees the 0, knows he has to send it to the VGW, strips the 0 off and has the call dialed on the PSTN. REGISTERED users phone dials, he answers and is connected.
    ANONYMOUS user does the same thing: he clicks on "Join Conference >> Call me at..." and puts in his number. He puts in +39XXXXXXXXXX. At this point OCS does not apply the normalization rules and sends to the Call Manager directly +39XXXXXXXXXX. The Call Manager does not know what to do with this number. If, instead, ANONYMOUS user would have inserted directly 0XXXXXXXXXX (so the number in his transformed form) this would have been the number sent to the Call Manager and his phone would have rang.

    It seems as if I can force Location Profiles on OCS users (we have the Default Profile for them, or add a specific profile for a specific user) but I do not know where/how/and if it is possible to do this for Guest users.

    I'm literally going crazy on this :)
    I could eventually apply a work around on the Call Manager, but honestly I'd prefer avoiding adding new rules there if OCS can dial with it.

    Once again thanks Randy for your help,


    Thursday, July 29, 2010 8:38 AM
  • Hi guys, any idea on this?
    Should I open a call with Microsoft? We have actually opened a couple with them but are having serious problems... I would not want this simply to get into the queue :(


    Tuesday, August 3, 2010 3:03 PM
  • Just catching up on the issue...


    I remember having to create special routes for CWA in a deployment, and I'm trying to dig my brain to remember why. More on that hopefully soon :)


    Anyways, as a double check, can you confirm under your conferencing attendant properties, the Regions tab. The correct region (this is actually the location profile) is there and the correct number is associated with it?


    I think the conferencing attendant may have a part in the dial out, so just want to see if that is setup for the correct location profile with those rules.



    Randy Wintle | MCTS: UC Voice Specialization | Winxnet Inc
    Tuesday, August 3, 2010 3:16 PM
  • Thanks :)
    I checked it out and we do have our Location Profile, used by our users, also set for the Conference Attendant (Region assigned to the Conference Attendant phone number).

    What is weird is that checking out the SipStack logs OCS really does not treat the dialed in number in any way. He just forwards it to the call manager. Situation that does not happen when a user has a location profile assigned (or not assigned, but he takes the first in the forest).

    I'm also along the line of believing that the problem is with the conference attendants profile. It make sense. But... still nothing.

    Thanks once again,


    Tuesday, August 3, 2010 4:18 PM
  • I wish I had a better answer, but I now remember why I had the special routes, and that is because no normalization was happening for anonymous users...

    You may want to open a case with msft unfortunately, no one else has chimed in on the forums with a fix for this either. I will ask around the community for some answers as well.





    Randy Wintle | MCTS: UC Voice Specialization | Winxnet Inc
    Tuesday, August 3, 2010 4:34 PM
  • Did you set the special routes directly on your call manager? That is a solution at the end. I'd delete all location profiles and have everything going on a specific trunk to have applied certain rules.
     I'll keep you informed on Microsoft's solution (at least I hope in a solution). It could come handy in the future.

    Thanks once again,


    Wednesday, August 4, 2010 8:20 AM
  • I am actually connecting to a dialogic gateway out to a PRI to my provider, so I was able to correct the dialing on the way out at the gateway level.


    Randy Wintle | MCTS: UC Voice Specialization | Winxnet Inc
    Wednesday, August 4, 2010 12:17 PM
  • Quick Update: "It is a design fault" ...

    Translations == totally useless :(

    Friday, August 6, 2010 9:32 AM
  • Hi,


    normalization rule just to transfer the number from normal digit to E.16 format

    if you want to controlling the voice you have to create phone policy , voice policy ,,

    and you have to create phone usage it's look like call search space.

    if you need any help in it ,, send me and I will explain more deeps about it



    Sunday, August 8, 2010 11:27 AM