locked
SIMPLE QUESTION: AVAYA CS1000 IP PBX SIP TRUNK CONFIGURATION - IS THERE SOMETHING WRONG? HAVE 20 SECONDS DELAY ISSUE BETWEEN LYNC AND PBX RRS feed

  • Question

  • Hello,

    We have direct-SIP (a.k.a. SIP trunk) established between Lync 2010 and AVAYA CS1000 IP PBX. While everything works pretty good, there is one issue: when IP PBX user call Lync user, Lync user cannot hear anything for approx. 15-20 seconds. After that connection established and everything works just great.

    I checked everything on Lync side and even tried to change every possible setting and 20 seconds issue is not resolved. I'm wondering if the issue maybe caused by some incorrect setting on PBX side. I took a screenshot with our current configuration and it is shown below. I'm wondering is somebody with CS1000 experience can check and maybe find any issue in SIP TRUNK configuration shown below?

    Thank you in advance for your help!

    Friday, March 9, 2012 2:15 PM

Answers

  • Hello everybody!

    After having this issue for 1.5 years (yes it was from day one when Lync 2010 was deployed and connected to CS1000 IP PBX) I'm happy to finally close this thread.

    You may ask: why? what was the solution? And I would answer: AVAYA HOTFIX was recently released to fix 20 seconds delay issue. That's simple. That's it. Case slosed.

    20 seconds delay is no longer exist. Thanks to AVAYA for releasing this hotfix after 1.5 years since the problem started. You just made your own grave by doing this!

    Case is closed!

    • Marked as answer by lync15 Tuesday, July 3, 2012 12:11 PM
    Tuesday, July 3, 2012 12:11 PM

All replies

  • hi,

    did you do a sip trace? what does it say is happening in the 20 seconds?

    sorry, i'm not familiar with cs1000. but sip trace might give you a clue.

    your likely way beyond this, but just in case:

    http://windowspbx.blogspot.com/2011/08/how-to-get-your-first-sip-trace-of-lync.html


    +Say thanks and observe basic forum courtesy:
    +If this post answered your question, Mark As Answer
    +If this post was helpful, Vote as Helpful

    windowspbx blog: my thots/howtos
    see/submit Lync suggestions here: simple and public


    Saturday, March 10, 2012 4:52 AM
  • I would first start off with a SIP and a MEDIATION traces. In the negotiation you should see the Candidates list and ports to establish the audio. My best bet would be peers try to connect using first Candidates and failing (Could be a network issue) and thus trying other methods thus creating that delay.

    If you would share traces of both SIP Stack and Mediation, i would be able to assist further.


    Hany George | Consultant | IDC S.p.A MCITP: Lync Server | MCITP: Exchange 2010 | MCTS: OCS Blog: http://dusk1911.wordpress.com If this post has been useful please click the green arrow to the left or click "Propose as answer"

    Monday, March 12, 2012 10:28 AM
  • Thanks everybody for helping out with this issue. I took a SIP trace using Lync Loggif tool as suggested, and I clearly see the issue - there is 20 seconds delay.

    If I understand correctly, it looks like issue may be caused by the fact that Lync is trying to esablish TLS connection using port 5070, but I'm not sure why, I use port 5060 for both outgoing and incoming traffic, explicitly configured as TCP protocol for both PSTN gateway (outgoing) and Mediation Server (incoming).

    Can you please review the trace and suggest something to try?

    Monday, March 12, 2012 12:51 PM
  • You have hidden too much information :), but as far as i can see the 5070 might be between the Lync Client and the Lync Server which is OK and what we expect to see. Now in one of the invites you should see the list of candidates for the connection. Could you post that here ?

    You can also install a wireshark on a machine running the lync client, run a trace while the problem is occuring.


    Hany George | Consultant | IDC S.p.A | MCITP: Lync Server | MCITP: Exchange 2010 | MCTS: OCS | Blog: http://dusk1911.wordpress.com/ | If this post has been useful please click the green arrow to the left or click Propose as answer



    Monday, March 12, 2012 1:11 PM
  • if you are not sure that on which ports lync is litsening from gateway and from lync to gateway do the telnet.

    During the trace do the port search and check either lync is sending to gateway with the correct port and from gateway to lync to see weather is it using 5070 or the defined ports in the topology builder

    usually 5070 is a port to communicate between lync to lync server

    have you restarted mediation server services when you have changed litsening ports in topology

    i have faced same problem whle using AVaya but not the same version which you are using, that at any cost lync was not sending signal to gateway on any port defined in topology but it was going with 5070 and i was like forced to use 5070, but in may case ther was  no communication at all untill i define my lync port litsening as 5070,

    your case is a 20 second delay. how about avaya to avaya communication is there any delay is lync voice segregated over lan?

    Have a try what i have said.


    If answer is helpful, please hit the green arrow on the left, or mark as answer. Salahuddin | Blogs:http://salahuddinkhatri.wordpress.com | MCITP Microsoft Lync

    Monday, March 12, 2012 2:10 PM
  • Thanks again for helping. Below please see entire INVITE command that is issued from LYNC to PBX when I call from LYNC phone to PBX phone. I replaced all IP addresses with the meaningful names like <PBX_IP_ADDRESS> or <SIP_DOMAIN_NAME> and highlighted all items that I replaced. I cannot see that PBX is in the list of candidates, which makes me think that this is the root cause, but I'm not sure why it is not there; also after 20 seconds connection is established, so it does work, just not first 20 seconds. Please review and let me know what could be an issue here. Thanks again for your help, I apreciate it very much!!!

    TL_INFO(TF_PROTOCOL)
    [10]0C38.1C84::03/12/2012-12:11:25.441.0001ab8b
    (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(125))$$begin_record

    Trace-Correlation-Id: 1316800456

    Instance-Id: 001E4C5F

    Direction: outgoing

    Peer: lync.<LYNC_SIP_DOMAIN>:5070

    Message-Type: request

    Start-Line: INVITE sip:7111@<PBX_IP_ADDRESS>:5070;user=phone;maddr=lync.<LYNC_SIP_DOMAIN>
    SIP/2.0

    From: "Alex Garin"<sip:alex.garin@<LYNC_SIP_DOMAIN>;tag=79740afb6a;epid=7efea52c11

    To: <sip:7111;phone-context=global@<LYNC_SIP_DOMAIN>;user=phone>

    CSeq: 1 INVITE

    Call-ID: c523d05a0b3a13dda9183cdd068fd3a7

    Record-Route: <sip:lync.<LYNC_SIP_DOMAIN>:5061;transport=tls;ms-fe=<LYNC_SERVER_NAME>.<LYNC_SIP_DOMAIN>;opaque=state:T;lr>;tag=C2707FA7C9F0DA7644C260334FAA2192

    Via: SIP/2.0/TLS <LYNC_IP_ADDRESS>:56333;branch=z9hG4bK2F0D739B.D681947BE5E542AD;branched=FALSE

    Max-Forwards: 69

    Content-Length: 2708

    Via: SIP/2.0/TLS <LYNC_PHONE_IP_ADDRESS>:49156;ms-received-port=49156;ms-received-cid=E5E700

    ms-application-via: SIP;ms-urc-rs-from;ms-server=<LYNC_SERVER_NAME>.<LYNC_SIP_DOMAIN>;ms-pool=lync.<LYNC_SIP_DOMAIN>;ms-application=ad894dc3-55e0-44bf-a07e-3c073aaa4a57

    P-Asserted-Identity: "Alex Garin"<sip:alex.garin@<LYNC_SIP_DOMAIN>>,<tel:+14165902035;ext=2035>

    Contact: <sip:alex.garin@<LYNC_SIP_DOMAIN>;opaque=user:epid:pT5ZUaN20VSEQ3Jlz1IvlgAA;gruu>

    User-Agent: CPE/4.0.7577.4047 OCPhone/4.0.7577.4047
    (Microsoft Lync 2010 Phone Edition)

    Supported: ms-dialog-route-set-update

    Ms-Conversation-ID: Ac0ASTxs8C5DR3ZrL0b/vlbm2N3x7Q==

    Supported: timer

    Supported: histinfo

    Supported: ms-safe-transfer

    Supported: ms-sender

    Supported: ms-early-media

    Supported: 100rel

    ms-keep-alive: UAC;hop-hop=yes

    Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE,
    REFER, NOTIFY, BENOTIFY, OPTIONS

    ms-subnet: <IP_SUBNET_HERE>

    Accept-Language: en-US

    ms-endpoint-location-data:
    NetworkScope;ms-media-location-type=Intranet

    Ms-Escalate-To: <sip:alex.garin@<LYNC_SIP_DOMAIN>;opaque=user:epid:9olCS12311OyXKVNL0Bg0gAA;gruu>;video

    Supported: replaces

    Supported: ms-conf-invite

    Content-Type:
    multipart/alternative;boundary="c80a949311c7e993c91ac6750d1ab9d0"

    ms-routing-phase: from-uri-routing-done

    ms-user-data: ms-publiccloud=TRUE;ms-federation=TRUE

    Message-Body: --c80a949311c7e993c91ac6750d1ab9d0

    Content-Type: application/sdp

    Content-ID:
    <6eec923b1277c9795a975ffb4c35c7b4@<LYNC_SIP_DOMAIN>>

    Content-Transfer-Encoding: 7bit

    Content-Disposition: session; handling=optional;
    ms-proxy-2007fallback

    v=0

    o=- 0 0 IN IP4 <LYNC_PHONE_IP_ADDRESS>

    s=session

    c=IN IP4 <LYNC_PHONE_IP_ADDRESS>

    b=CT:99980

    t=0 0

    m=audio 8712 RTP/SAVP 114 9 111 0 8
    115 97 13 118 101

    a=candidate:0GBKDmR9wUJtECFwIpJvj2/P5oA1XJlzdypkLCWnL4c
    1 9Peys/NYTtrutx2mmXO3RA UDP 0.830 <LYNC_PHONE_IP_ADDRESS> 8712

    a=candidate:0GBKDmR9wUJtECFwIpJvj2/P5oA1XJlzdypkLCWnL4c
    2 9Peys/NYTtrutx2mmXO3RA UDP 0.830 <LYNC_PHONE_IP_ADDRESS> 8713

    a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80
    inline:lAL3z6P6MJSurNaBEv766qb4WFjQU5dSASgWV6Ty|2^31|1:1

    a=crypto:2 AES_CM_128_HMAC_SHA1_80
    inline:1pKzUafO+/SxNmcGV0+EEpTQaKukyyj+fkCutHaU|2^31|1:1

    a=crypto:3 AES_CM_128_HMAC_SHA1_80
    inline:ISRz4LeFrGe21cUVgSmUTY6+lSxXBbOJ4HlR/do6|2^31

    a=maxptime:200

    a=rtpmap:114 x-msrta/16000

    a=fmtp:114 bitrate=29000

    a=rtpmap:9 G722/8000

    a=rtpmap:111 SIREN/16000

    a=fmtp:111 bitrate=16000

    a=rtpmap:0 PCMU/8000

    a=rtpmap:8 PCMA/8000

    a=rtpmap:115 x-msrta/8000

    a=fmtp:115 bitrate=11800

    a=rtpmap:97 RED/8000

    a=rtpmap:13 CN/8000

    a=rtpmap:118 CN/16000

    a=rtpmap:101 telephone-event/8000

    a=fmtp:101 0-16

    a=encryption:required

    --c80a949311c7e993c91ac6750d1ab9d0

    Content-Type: application/sdp

    Content-ID:
    <8408aa09731650413ac0f5822daf0de1@<LYNC_SIP_DOMAIN>>

    Content-Transfer-Encoding: 7bit

    Content-Disposition: session; handling=optional

    v=0

    o=- 0 1 IN IP4 <LYNC_PHONE_IP_ADDRESS>

    s=session

    c=IN IP4 <LYNC_PHONE_IP_ADDRESS>

    b=CT:99980

    t=0 0

    m=audio 33204 RTP/SAVP 114 9 111 0 8
    115 97 13 118 101

    a=ice-ufrag:pxMj

    a=ice-pwd:1jXlUGZvzZS8NpRgA0ANa4Nn

    a=candidate:1 1 UDP 2130706431 <LYNC_PHONE_IP_ADDRESS>
    33204 typ host

    a=candidate:1 2 UDP 2130705918 <LYNC_PHONE_IP_ADDRESS>
    33205 typ host

    a=candidate:2 1 TCP-ACT 1684798975 <LYNC_PHONE_IP_ADDRESS>
    33204 typ srflx raddr <LYNC_PHONE_IP_ADDRESS>
    rport 33204

    a=candidate:2 2 TCP-ACT 1684798462 <LYNC_PHONE_IP_ADDRESS>
    33204 typ srflx raddr <LYNC_PHONE_IP_ADDRESS>
    rport 33204

    a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80
    inline:lAL3z6P6MJSurNaBEv766qb4WFjQU5dSASgWV6Ty|2^31|1:1

    a=crypto:2 AES_CM_128_HMAC_SHA1_80
    inline:1pKzUafO+/SxNmcGV0+EEpTQaKukyyj+fkCutHaU|2^31|1:1

    a=crypto:3 AES_CM_128_HMAC_SHA1_80
    inline:ISRz4LeFrGe21cUVgSmUTY6+lSxXBbOJ4HlR/do6|2^31

    a=maxptime:200

    a=rtpmap:114 x-msrta/16000

    a=fmtp:114 bitrate=29000

    a=rtpmap:9 G722/8000

    a=rtpmap:111 SIREN/16000

    a=fmtp:111 bitrate=16000

    a=rtpmap:0 PCMU/8000

    a=rtpmap:8 PCMA/8000

    a=rtpmap:115 x-msrta/8000

    a=fmtp:115 bitrate=11800

    a=rtpmap:97 RED/8000

    a=rtpmap:13 CN/8000

    a=rtpmap:118 CN/16000

    a=rtpmap:101 telephone-event/8000

    a=fmtp:101 0-16

    a=encryption:required

    --c80a949311c7e993c91ac6750d1ab9d0--

    $$end_record

    Monday, March 12, 2012 2:11 PM
  • I just found out that after I restart LYNC Mediation service, first call from LYNC to PBX does not have 20 seconds delay and works very well. Second call and all calls after that have 20 seconds delay. Every time I restart Mediation service, there is no 20 seconds delay for first call only. I'm not sure how this can help, but this is something interesting. Thanks!

    Monday, March 12, 2012 2:58 PM
  • Hi,

    Have you looked in to my suggestions.

     Also can you do the test of changing litsening port of lync mediation server to 5070 and then restart mediation services and then check.

    This is just for test


    If answer is helpful, please hit the green arrow on the left, or mark as answer. Salahuddin | Blogs:http://salahuddinkhatri.wordpress.com | MCITP Microsoft Lync

    Monday, March 12, 2012 3:06 PM
  • I'm not sure what suggestions you mentioning because I believe there are 2 people here is trying to help me, and it was few posts by now. I hope you are talking about port 5070, so here is an update: apparently you cannot change Mediation port to 5070 because it generates conflict as shown below:

    The topology contains one or more services with port sharing conflicts.

    • PortNumber "5070" with UrlPath "/" causes a port sharing conflict for IPAddress "0.0.0.0" on Machine "<mediation_server_name>" for these service ports.

      • ServiceId "MediationServer:<mediation_server_name>", NetPortId "Mediation.SipServer.Mtls.Primary"
      • ServiceId "MediationServer:<mediation_server_name>", NetPortId "Mediation.SipClient.Tls.Pstn
      • I tried changing both: TCP 5067 -> 5070 - got error, cannot publish topology; same for attempt changing TLS 5068 to 5070. Maybe I need to change listening port on PBX?
    Monday, March 12, 2012 4:29 PM
  • Ok then you can not change the port because it is already being used by server to server communication.

    when you restart mediation services then check the traces for a call which doesnt dealy for 20 seconds and then hang up then again make a call which makes a delay and do the trace for that. let's see what differences are in between.


    If answer is helpful, please hit the green arrow on the left, or mark as answer. Salahuddin | Blogs:http://salahuddinkhatri.wordpress.com | MCITP Microsoft Lync

    Monday, March 12, 2012 5:17 PM
  • Ok, thank you. I did that, and I think I was able to find out the difference. I tested several times in the row, and I confirmed that this is the difference between when it works and when it is not working. So let's now. When it works (only very first call after restarting Mediation service), it is always does in this order:

    Wen it does not work (every single time after first successfull call) the order always looks like this:

    I'm not sure what kind of information is contained in Progress Report, but when I check details for this packet I can clearly see that it contains pointer to PBX - so it looks like in order to work this packet should be the first before actual INVITE command. Here is what is included in this Progress Report when things are working:

    TL_INFO(TF_PROTOCOL)
    [0]0C38.3744::03/12/2012-19:00:05.137.0001b8fe
    (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(125))$$begin_record

    Trace-Correlation-Id: 2404194655

    Instance-Id: 001F3283

    Direction: outgoing;source="local"

    Peer: <LYNC_PHONE_IP_ADDRESS>:49156

    Message-Type: response

    Start-Line: SIP/2.0 101 Progress Report

    From: "Alex Garin"<sip:alex.garin@<SIP_DOMAIN>;tag=a775f7d4dd;epid=7efea52c11

    To: <sip:7111;phone-context=global@<SIP_DOMAIN>;user=phone>

    CSeq: 1 INVITE

    Call-ID: ec0c54ea38bf002a3fc827a2eef94843

    Authentication-Info: TLS-DSK qop="auth",
    opaque="EF7AAFCE", srand="F7D92247", snum="929",
    rspauth="d97c112b39c14268834533e3888ab4ea951767da", targetname="<LYNC_SERVER_NAME>",
    realm="SIP Communications Service", version=4

    Content-Length: 0

    Via: SIP/2.0/TLS
    <LYNC_PHONE_IP_ADDRESS>:49156;ms-received-port=49156;ms-received-cid=E5E700

    ms-diagnostics: 12006;reason="Trying next
    hop";source="<LYNC_SERVER_NAME>";PhoneUsage="PBX";PhoneRoute="PBX";Gateway="<PBX_IP_ADDRESS>";appName="OutboundRouting"

    Server: OutboundRouting/4.0.0.0

    Message-Body:

    $$end_record

    Monday, March 12, 2012 7:03 PM
  • Are you running an MGC or MC32S cards for your DSPs?

    Hany George | Consultant | IDC S.p.A | MCITP: Lync Server | MCITP: Exchange 2010 | MCTS: OCS | Blog: http://dusk1911.wordpress.com/ | If this post has been useful please click the green arrow to the left or click Propose as answer

    Monday, March 12, 2012 7:51 PM
  • As far as I know we have MC32S cards in our CS1000 IP PBX. "S" stands for Secure I believe. We used to have MC32 cards but this was before we deployed Lync. Next month we asked company who supports our PBX to bring older MC32 card to try and see if the 20 seconds delay is caused by MC32S cards, but this is taking time and I'm not even sure that this is what will fix it, so I'm trying to work in multiple directions in parallel.
    Monday, March 12, 2012 8:00 PM
  • Well, Looks like your issue is with early media negotiation, Avaya released a patch "MPLR28305" to fix this specific issue "The 20 Seconds Delay".

    Early Media is the ability for 2 clients to start media before the call is actually established. Now i'd say you have 3 options

    1- Get the above patch and install then test. --> Others reported success with that having the same 20 secinds delay

    2- If you have an old MGC card, you can try that also

    3- You can disable early media in Lync and check --> i'd say start off with that one

    Here is also some threads that you could use to kick off your troubleshooting, all of which is actually describing your very same issue

    http://social.technet.microsoft.com/Forums/en-US/ocsvoice/thread/22166411-a8bd-47f9-9974-a1362e5a8391 

    http://social.technet.microsoft.com/Forums/sv-SE/ocsvoice/thread/e5df3029-6e0a-4d8e-a471-b75ebfac45a3 

    Hope this helps


    Hany George | Consultant | IDC S.p.A | MCITP: Lync Server | MCITP: Exchange 2010 | MCTS: OCS | Blog: http://dusk1911.wordpress.com/ | If this post has been useful please click the green arrow to the left or click Propose as answer

    • Proposed as answer by Hany George Monday, March 12, 2012 8:10 PM
    Monday, March 12, 2012 8:09 PM
  • Thanks Hany, but I have to disappoint you on every step of the way:

    1. Patch "MPLR28305" is not applicable to us; more exactly we have it already. Few months ago I open case with AVAYA and they confirmed that we already have it because we are running version 7.0. Here is the official reply from AVAYA:

    MPLR28305 has been rolled into rls 6.30.16 , as per reported in the MPLR database . Site running rls 7.0 should not require this patch. Thanks, Ron. 613-771-7457.

    2. Old MC32 card - it is in our to do list to try, unfortunately it may only happen next month, or maybe even later. It does require shut down for the whole PBX so we are targeting this at the same time when we will be upgrading version 7.0. to latest and final version - 7.5. Apparently 7.5 is the last and final version for this PBX. Remember how the guy said on Lync worldwide launch event: Folks, the era of PBX is over :-)

    3. Links that you giving to me - I knoww them; in fact one of them is my thread :-). I just decided to open a new thread with slightly different falvour hoping that it will re-animate this case and ring some new insight into this case. This is absolutely ridiculous issue but at the same time it is absolute showstopper to start migrating from PBX to Lync.

    Reagrding "Early Media" option they are talking about some issues with Firewall. We have Firewall disabled on internal servers like Lync, so I guess this rule out this from the list of potential root causes?

    Hope my explanation helps a bit to clarify the situation and how bad it is. I still believe that solution is simple, but we just don't know what it is.

    Thanks!

    Monday, March 12, 2012 8:39 PM
  • well, the only thing i can suggest you do is to disable early media from the trunk configuration in Lync control panel and check

    Hany George | Consultant | IDC S.p.A | MCITP: Lync Server | MCITP: Exchange 2010 | MCTS: OCS | Blog: http://dusk1911.wordpress.com/ | If this post has been useful please click the green arrow to the left or click Propose as answer

    Monday, March 12, 2012 9:17 PM
  • Where I can find it? Here is how Trunk configuration looks like, there is no "Early Media" settings there:

    Can you please advise how to disable Early Media? Where this setting is hiding?

    Monday, March 12, 2012 9:21 PM
  • apologise, i meant refer support. but you have it done already. i think the MC32 card is the remaining option, other than that you can involve avaya support into this.

    One other option you can consider is to have a voice gateway in between the two, NET vx1200 for say


    Hany George | Consultant | IDC S.p.A | MCITP: Lync Server | MCITP: Exchange 2010 | MCTS: OCS | Blog: http://dusk1911.wordpress.com/ | If this post has been useful please click the green arrow to the left or click Propose as answer


    • Edited by Hany George Tuesday, March 13, 2012 8:30 AM
    Tuesday, March 13, 2012 8:20 AM
  • All this time I'm using Mediation Server co-located with Front-End Lync server (first it was Standard and now Enterprise but always co-located). Do you think that building dedicated (i.e. separate) Mediation Server may fix this issue? Or may be I can try enabling second NIC and use it exclusively for PBX connection? Since Mediation Server is not used yet (because we have 20 seconds issue we cannot migrate any users to Lync) I can play with this role and move it around. Thanks!

    Tuesday, March 13, 2012 12:28 PM
  • I think doing that will have no impact to your issue. My saying would be that avaya is just not handling the Early Media properly. Why dont you try TLS instead of TCP ?

    Hany George | Consultant | IDC S.p.A | MCITP: Lync Server | MCITP: Exchange 2010 | MCTS: OCS | Blog: http://dusk1911.wordpress.com/ | If this post has been useful please click the green arrow to the left or click Propose as answer

    Tuesday, March 13, 2012 12:46 PM
  • Yes, I tried this before and it never worked, so I tried again now while using SIP trace. When call is failing (shorty after dialing) I get this message in red color twice in SIP trace:

    Start-Line

    : SIP/2.0 504 Cannot connect to gateway. Error: The operation failed because a message received from the network was not formed properly.

    Tuesday, March 13, 2012 1:35 PM
  • Have you installed a certificate on the Gateway that Lync Trusts ? Have you modified the settings in your topology (New Ports) and in avaya lync trunk ?

    What Cumulative Update are you on ? Sip 504 in general means timeout.


    Hany George | Consultant | IDC S.p.A | MCITP: Lync Server | MCITP: Exchange 2010 | MCTS: OCS | Blog: http://dusk1911.wordpress.com/ | If this post has been useful please click the green arrow to the left or click Propose as answer

    Tuesday, March 13, 2012 1:42 PM
  • No, I did not. But here is the issue: things like install SSL certificate on PBX is huge task for us, unless it can be done through the same GUI as SIP trunk, but I don't think so. I would guess that this has to be done inside Linux (CS1000 at the end of the day is Linux-based server, right?) and for this we will need to go to the company who support PBX, ask them, pay them, and not even sure it will work.

    Another question: are we sure that PBX need SSL installed? What about Lync to have PBX's certificate? Remember I call to PBX, not from PBX. So I guess Lync should trust PBX as well. I can trust anything in Lync, but I have no idea what certificate is there, and I'm not even sure if there is any SSL certificate there.

    For now I managed to change TCP port from defaults to 5060, both incoming and outgoing, as shown below:

    Then went to PBX and changed protocol to TCP and port to 5060 everywhere I can in the SIP trunk configuration. So everything is working except 20 seconds delay issue. I do not believe that TLS could fix it, but it maybe the case, the issue is that it does not work and playing with SSL will be much more complicated then using TCP instead.

    Another thing I noticed that when TLS is disabled on PBX, I have 2 options for protocols: TCP and UDP. Lync only has option TCP or TLS. I will try using UDP and see how this can work. Still I smell that solution is somewhere close, but don't know where exactly.

    Thanks!

    Tuesday, March 13, 2012 1:58 PM
  • You can only configure UDP if you use a gateway in between, Given that you are using the MC32"S" card, S is the secure one, i would guess having TLS would be more efficent. Tinkering with certificates is no problem at all. issuing one for the CS and installing it should be no more than 5-10 minutes with plenty of guides on the internet.

    Hany George | Consultant | IDC S.p.A | MCITP: Lync Server | MCITP: Exchange 2010 | MCTS: OCS | Blog: http://dusk1911.wordpress.com/ | If this post has been useful please click the green arrow to the left or click Propose as answer

    Wednesday, March 14, 2012 6:42 AM
  • Today we tried to switch TCP protocol to TLS, but no matter what we tried - it did not work. I always get this when I make a call from Lync to PBX:

    I took valid self-generated SSL certificate from PBX (cs1k.domainname) and imported to Lync server as Trusted Root Certification authorities (under computer account of course). Then changed TCP to TLS, and even tried different ports (5060, 5067) on each side. And it does not work. I have no idea how and whether or not I need to import Lync SSL certificate into PBX. Lync is using valid GoDaddy SSL certificate, so I assume that Linux (CS1000 is actually Linux server) should trust something that is trusted everywhere, especially because it is not very old - we have CS1000 version 7.0.

    Since this does not work, and I cannot say why, we had to roll back to TCP. Ports do not matter, as long as they match on both sides - it works (except 20 seconds delay issue). So we stick with 5060 for now (TCP).

    And I have no idea what else we could try... So bad!


    • Edited by lync15 Wednesday, March 14, 2012 5:05 PM
    Wednesday, March 14, 2012 4:58 PM
  • Hi Alexgarin,

    Avaya CS 1000 is not supported for Direct SIP configuration with Lync. Please refer to below link for all supported devices.

    http://technet.microsoft.com/en-us/lync/gg131938

    Regards

    Sid

    Thursday, March 15, 2012 4:12 AM
  • I would say that your options are now

    1- Use a gateway in between the two.

    2- Use the MGC Card - Seen a lot of CS1000 success with this.


    Hany George | Consultant | IDC S.p.A | MCITP: Lync Server | MCITP: Exchange 2010 | MCTS: OCS | Blog: http://dusk1911.wordpress.com/ | If this post has been useful please click the green arrow to the left or click Propose as answer

    • Proposed as answer by Hany George Thursday, March 15, 2012 8:42 AM
    Thursday, March 15, 2012 8:42 AM
  • Thanks Sid and Hany for your help and support.

    Sid: I know that AVAYA CS1000 is not supported from day one. I know this URL. But when something is not supported, it does not neccesary means that it does not work. What other options we have? Scenario: client has CS1000 PBX for 10-15 years, pay big bucks for support and for PSTN service. One day come another guy (Microsoft) and says: hey, I have a new product for you - Lync. You can throw away your PBX, and enjoy life by paying 10 times less for actually better service. Client thinks: sounds good. But there is no magic, I cannot replace 1,000 phones over night, and what is more important, I cannot educate 1,000 users at the same time, so client wants gradual approach. Let's do IT first, then some pilot users, then slowly try call centres (yeah these guys use phones all the time so special attention is required), then roll-out to all other users, and then don't forget all these queues (for sales press 1 etc.). And how about modem lines - Lync does not provide them. Connect to 911 service too, what about fax machines? You see, big bang migration is not an option, unless you have 3 people in your company, and you are one of them :-) So obviously Lync users still want to call PBX users. You cannot tell them: hey, you cannot do that anymore. And all then know for 20 last years - 4 digits calling. This is why everybody use these extentions. It will take years before people will be calling by using SIP URI or picking up from contact list on nice Lync phone touch-screen color LCD display. Bottom line: direct SIP, or SIP trunk if you want, working nice between Lync and PBX, except when Lync user is calling to the queue, or reaching somebody's voicemail, or calling to old digital phones. If I call PBX user who has new IP phone - no problem. It works. I believe that this is fixable, just need to find out how to fix that. It is easy to say "Hey this is not supported". But we have to find how to make this work.

    Hany: 1. Using gateway maybe tricky, because to use it we need to buy it first. I guess it is not $50 device. It may be 5 grand or something. Then we need to install and configure it. And at the end, what if it will not work? Who said that it will work? Who can guarantee that? Nobody I guess. I can try this option to see if this is possible, but at the moment I'm very sceptic. Can you recommend some good inexpensive gateway that may fit the bill? 2. Testing MC32 (instead of MC32S) card is our planned next step, but again it may happen only next month when we have planned outage. We cannot just bring telephones down any time, this is serious excersise. Then our support company is involved, they need to replace one of four MC32S cards with older MC32 card, disable three other cards, and test connectivity. Maybe it will work. Another planned activity is to upgrade CS1000 from version 7.0 to version 7.5. Again, maybe something will change and will fix this issue. I can only hope for this.

    Anyway, I don't want to give up. And to increse the interest to this issue (especially because I know for sure that lots of other people have exactly the same issue) I would like to announce a prize (bonus) to the person who will help us to resolve this issue bu applying some configuration change that we can easily apply. I will post details in my next post.

    Thanks!

    Thursday, March 15, 2012 5:35 PM


  • *** I would like to make an announcement ***

    In order to bring some interest into this thread and assist with
    quicker resolution of this case, the person who will help me to resolve this
    annoying 20 seconds delay issue (except the case with trying MC32 cards because
    this is already in my to do list for next month) I will give (send by Canada
    Post) this person nice top-of-the-line LG Nortel 8540 IP Lync phone with Latest
    Lync firmware. Those phones are still sold for over $1,000, and I will send one
    of such phones (used but in good working condition) to the person who can give
    solution to 20 seconds issue:

    http://www.cdw.ca/shop/products/LG-Nortel-IP-Phone-8540-VoIP-phone/1816780.aspx

    Solution should be easy to implement, and should not require
    purchasing of any hardware or software. It may be settings on PBX or Lync side,
    I will be able to implement pretty much any proposed solution and test it right
    away. Solution should not say something generic like “Try using TLS” but
    instead it should mention exact steps and how to deploy it, without obvious
    mistakes or typos. This is usually most annoying thing when you see
    step-by-step procedure, and something is not there, or called differently.

    Anyway, I will be open to try any non-destructive solution that
    may lead to solution to resolve 20 seconds delay issue. If you need any
    additional information please let me know and I can get it. Run any logs,
    traces, tests etc. Anything – because I really want to resolve this issue. It
    is bugging me for almost a year by now, and actually preventing from starting
    migration to Lync.

    • Edited by lync15 Thursday, March 15, 2012 6:27 PM
    Thursday, March 15, 2012 5:41 PM
  • Hi,

    This might seem a bit off, but I'll ask anyway:

    Do you have an Edge server in your deployment? If you have, have you selected it as a resource available to the mediation/frontend server ( Associate Edge pool (for media components))? If you have, make sure all your clients, all your lync servers and your siptrunk endpoints can reach the inside edge interface.

    I've seen similar delays, and the have all been related to some firewall blocking (or interrupting) the traffic to/from the edge server. Or the lack of routing (or knowledge of each other) to/from the internal edge interface. 


    Lasse Wedø,
    Blog:Tech@work, Twitter: @lawedo

    Please take a second to hit the green arrow on the left if the post was helpful, or mark it as an answer if it resolved your issue.

    Thursday, March 15, 2012 8:01 PM
  • Hi Lasse,

    We definitely have Edge server sitting in DMZ - everything by the book! It was there pretty much from day 1, before we setup SIP trunk (or direct SIP) connection. What I just did in last 20 minutes is removed (unassociated) EDGE pool from Front-End pool as well as from Mediation server pool (you cannot unassociate from co-located mediation pool because this is the same as unassociate from front-end pool). Then I published topology, made sure that all replicated, rebooted my Lync phones (I learned that when I change something it is much better to reload Lync phones for clean test results) and tested again - same issue. I even then rebooted Edge server and while it was rebooting 5-7 minutes I tested again multiple times - still does not work.

    What I did today is built new temporary dedicated Mediation server, but I can only test this tomorrow - person who is supporting PBX is not in today. Tomorrow I will ask to switch PBX from co-located Mediation server (i.e. running on Front-End Enterprise edition server) to dedicated Mediation server and test to see if this issue can be resolved. I have a feeling that something is getting messed up after first call, because otherwise how to explain the fact that after restarting Mediation service on Front-End server I can do my first call without 20 seconds delay, and then any next call gets 20 seconds delay? So it does work somehow, I just don't know why it works one time after Mediation Service restart.

    Another option I was thinking of is maybe this delay is casued by the fact that Lync using G.722 codec but CS1000 PBX only supports G.711 and G.729? What is Lync is expecting G.711, wait 20 seconds to establish voice connectivity, then give up and fall back to use G.711? Is that possible? I don't know...

    Anyway, tomorrow I will test PBX connection via dedicated Mediation Server and let you know.

    Thursday, March 15, 2012 9:20 PM
  • Wait a minute,

    I think I see your error now. You are using a Sip trunk to a colocated mediation server without "media bypass" enabled. Media bypass is a prerequisite for colocating these services:

    "Media Bypass

    Media bypass has been added to Lync Server. Media bypass allows media traffic to bypass the Mediation Server and flow directly from the client (that is, Lync Server) to the gateway or IP-PBX. When media bypass is configured, the signaling traffic continues to flow through the Mediation Server on its path to the gateway; however, media traffic bypasses the Mediation Server and is sent directly to the gateway. Media bypass requires support from specific gateways. These gateways will be listed in the Microsoft Unified Communications Open Interoperability Program.

    With media bypass, the Mediation Server role can now be co-located on a front-end server, simplifying deployment and management of Lync Server. This reduction in physical servers helps lower the total cost of ownership. By removing the media workload from the Mediation Server, it can scale higher to support thousands of users."

    (from: http://technet.microsoft.com/en-us/library/ff793475.aspx"

    Moving the trunk to a stand alone mediation server should work better:


    Lasse Wedø,
    Blog:Tech@work, Twitter: @lawedo

    Please take a second to hit the green arrow on the left if the post was helpful, or mark it as an answer if it resolved your issue.


    Thursday, March 15, 2012 9:48 PM
  • Well, do you think I never tried enabling "Media Bypass" on Lync server? I tried hundred times with no luck. I tried in both places - under Voice Route (Trunk Configuration) as well as under Network Configuration. No luck. What I never tried is to build dedicated (and not co-located) Mediation server - this is what I was planning some time ago and finally completed today morning. I just can test it tomorrow because our PBX support person was away today and I don't have access to PBX configuration. For obvious reasons I did not want to change IP address of production Lync Front-End server in the middle of the day :-)

    Tomorrow morning we will re-point CS1000 to dedicated Mediation Server and will see how it works. If magic will happen and 20 seconds delay will be resolved, I will be surprised very much and at the same time will be happiest person on planet Earth for next several days (only several days because there are some other challenges still exists - for example number displayed on PBX phones when Lync user is calling is not 4 digits but full 11 digits in E.164 format, and I have no idea ho and whether it is even possible to change "From:" telephone number - dialing rules and Trunk transition rules only can modify "To:" number, not "From:" number. It is not a huge deal especially because Call Display still works (i.e. name of the person calling is shown) but this will make PBX users think that this call is coming from outside and it is not internal call. Users used to see 4 digits extension alone with person name so they know that it is internal call).

    By the way, lsecond link in your reply is actually for OCS 2007R2 and not for Lync. In OCS 2007 R2 Mediation server must be dedicated server and Media Bypass is not even supported (new feature introduced in Lync 2010). And yes, I perfectly aware that OCS 2007 R2 works nucely with CS1000, the only problem that we need to make Lync working with CS1000 because there is no way we can use OCS 2007 R2. It was good 5 years ago, but sorry it is too old now. We have to move forward. In 3-4 years Lync will be old, and hopefully by this time PBX will be completely gone. We still have to decide what to do with the big pile of hardware: donate, sell by pieces, or send to nearest junkyard :-)

    Thanks!

    Thursday, March 15, 2012 11:02 PM
  • Ok I have some news, and unfortunately they are not very good news: dedicated Mediation Server running on separate Windows server did not fix the problem.

    Here is what was done (just to confirm that the test is valid): I deployed Mediation Server on separate Windows server. All patched 100%. Then updated Routes to add new PSTN gateway associated with new Mediation Pool, and removed old PSTN gateway. I even stopped Mediation Service on Front-End server to make sure that my calls are going through dedicated Mediation Server. Exactly same issue with 20 seconds delay. And exactly same behaviour when I restart Mediation service: first call is connected instantly, without delay. Second call and any call after first call have 20 seconds delay (i.e. Lync user cannot hear auto-attendant message from PBX for first 20 seconds).

    Before decommissionning new temporary dedicated Mediation Server I will try to play couple of days (e.g. try to play with Media Bypass) but I do not believe that anything can help. Then I will switch back to co-located Mediation server and decommission dedicated mediation server.

    If there is anything else I could try - please let me know. The competition for Lync IP touch-screen display phone is still on!

    Thanks!

    Friday, March 16, 2012 4:10 PM
  • With the Stand Alone Mediation server in place, please set the following settings on your trunk (or global):

    Disable media bypass, Disable refer support and Set encryption to "not supported"

    next, make sure servers have associated the edge pool for media.

    Also, double check full IP-reachability between Frontens, edge, mediation and the CS1000 unit. (Make sure they can resolve each others fqdn's too, when needed.


    Lasse Wedø,
    Blog:Tech@work, Twitter: @lawedo

    Please take a second to hit the green arrow on the left if the post was helpful, or mark it as an answer if it resolved your issue.

    Friday, March 16, 2012 5:34 PM
  • Ok, I checked all the name resolution and connectivity. For obvious reasons EDGE server is not using internal AD DNS (we don't want Swiss Cheese in the firewall) so I used HOSTS file to resolve LYNC and PBX names. Although I cannot TELNET PBX 5060 - I hope you do not ask me to allow this. EDGE server shoud not have ports open to internal network unless I misunderstood the whole concept of the Lync 2010 EDGE server role in the first place. I can ask our Firewall person to temporary open all ports from EDGE server to internal network, but I do not believe thsi may resolve this issue. If you think it may, please confirm and I will do that on Monday.

    Name resolution between all components works, no problem. Short names and FQDN names are resolved correctly, no issue at all. Honestly I do not believe that EDGE server is involved in calls between LYNC and PBX. I believe that Front-End is talking to PBX via Mediation server. This is where I see all the traffic. Yesterday I did try to unassociate EDGE server pool from all other pools - Front-End and Mediation, but this did not change the behaviour. By the way just to be clear here is the scenarios where 20 seconds delay issue occurs - in any other scenario calls are connected instantly:

    Last scenario can be easily eliminated by connecting Lync to SIP trunking services. We are actually in the process of connecting to SIP Trunking provider, it just takes time, and hopefully in 1-2 months our Lync will be talking to outside world using SIP trunking and not through IP PBX. But the first two issues will remain, and because we will need to co-exist between PBX and Lync for long time (probably at least 1 year) we need to make sure that Lync users can call PBX queues (e.g. Helpdesk) or call users who still use older digital phone (approx. 50% of our users still using older phones). In fact we stopped rolling out AVAYA phones (1120E) hoping that instead of spending $350 per IP phone we can migrate those users to Lync right away and buy Lync phones instead (Polycom CX-700, CX-600, HP 4220, Aastra or Snom) but this 20 seconds delay is actually huge showstopper that makes impossible to move forward.

    We desperately need solution for 20 seconds delay. I'm sure this is stupid issue somewhere, and we just don't know where...

    Friday, March 16, 2012 6:25 PM
  • Ok, this weekend we made two changes:

    1. Upgraded CS1000 from version 7.0 to latest and greatest version 7.5 - unfortunately this did not work and did not fix 20 seconds delay issue.

    2. Tried connecting older MC32 cards - this test failed as MC32 for some reason (I don't know why) failed to register or was not receognized, so this was not successful.

    I also opened a Microsoft case for this issue last month, and after working couple of weeks (I'm not sure if they really worked or just did not do anything) they came back with simple answer: Microsoft Lync 2010 does not support Nortel/AVAYA CS1000 PBX and therefore there is nothing we can help with. Case is closed. No solution.

    Now we are back to square one, and the only hope is to use some kind of Media Gateway. From any search the most popular gateway that comes up in search results is AudioCodes Mediant 1000, so I guess next step will be to buy one of these devices and try it. But I guess it would be last resort...

    Any other ideas are more than welcome!

    Monday, April 23, 2012 1:34 PM
  • The only thing I can say is that cs1k works fine with lync starting from 5.5. so in your case it's definitely configuration issue.
    Tuesday, April 24, 2012 1:24 PM
  • Thanks for your advice. It would be nice to know what is the configuration issue and how to fix it.

    Reminder: I do see that pretty much all people who attempted integrate (read: connect) Lync to PBX (or PBX to Lync) are having the same issue.

    Working scenario: if company has CS1000 PBX, and all phones are IP Phones (i.e. AVAYA 1120, 1140, 1150) then everything works. It does work for me no problem when I call to IP phone PBX user. No problem. No delay. And vice versa - no issue.

    Non-working scenario # 1: when Lync user calls PBX user who is using older digital black phones (e.g. Nortel Meridian M3904 phone) or vice-versa, Lync user cannot hear PBX user for first 20 seconds. PBX user can hear Lync user immediately from first second.

    Non-working scenario # 2: when Lync user calls PBX queue (auto-attendant, auto-reply, you name it) then Lync user cannot hear voice for first 20 seconds.

    Non-working scenario # 3: when Lync user calls any PBX user (including the ones who have modern IP phones like 1120E) and PBX user configured re-direct to voicemail (e.g. PBX user is gone for vacation) then Lync user cannot hear PBX user for first 20 seconds.

    Non-working scenario # 4: when outside user (e.g. cell phone) calls Lync user (PSTN --> PBX --> Lync) then Lync user cannot hear first 20 seconds but external user can hear right away. If Lync user calls outside user (Lync --> PBX --> PSTN) then everything works ok in both directions.

    Interesting scenario: if I restart Mediation Service, then any of the non-working scenarios will work just fine, but only one time (i.e. very first call). Next call will have the same 20 seconds delay issue.

    ================================================================================

    This issue is quite amazing, and here is my understanding what is happening (correct me if I'm wrong):

    1. It looks like Microsoft and Avaya are no longer friends.

    2. AVAYA is not interested to fix this issue, and not interested to certify Lync 2010 as compatible PBX with CS1000. If they do, they understand that people ad companies will start swtiching - why not? Lync is better, cheaper, and amazing. PBX is bulky, old dinosour. They don't want to lose money, so they will do anything not to support Lync 2010

    3. Since AVAYA is not cooperating, Microsoft do not care too much. They even did not want to help me. All they say: sorry, CS1000 is not certified and therefore not supported by Microsoft.

    =================================================================================

    And the question is: what we supposed to do?

    Tuesday, April 24, 2012 2:27 PM
  • I would suggest to collect information about cs1k configuration (dch, trunk, route) and status of sip trunks and DSPs (after you do restart of mediation and after first call).

    sip stack traces from SS and dch traces from CS may also help. and you can do netmon or wireshark traces to see when exactly media starts.

    BTW it also can be in configuration (or misconfiguation) of IP addresses on avaya side (I mean node IP, tlan IP, etc.).

    and finaly, you can raise the case in Avaya =)

    Tuesday, April 24, 2012 3:50 PM
  • We are now trying to open ticket through AVAYA but it maybe not as easy as it sounds. Current official statement of AVAYA and Lync is quite different from what we need, and here is why. All we need is to be able to call directly from Lync to PBX and vice-versa, and it is working pretty good except scenarios mentioned above. What AVAYA is saying, is that Lync is supported through using AVAYA ACE product that was released in January 2012.

    Unfortunately meaning of support is different: what they do is provide full support for Remote Call Control, so the Lync user must be confgured with RCC instead of Enterprise voice. Or, more specifically, it means that we still have to use PBX for voice calls (using PBX phones etc.) but it will integrate with Lync for updating presence information and some other stuff. While it sounds interesting, this is not really what we want. I'm happy to use Lync 2010 as complete PBX solution, and I don't need any AVAYA there. But because process of switching is not one weekend deal, we need co-existance between two systems, but for calls only. I don't care that PBX user is not integrated with Lync, in fact I don't even want to start with this: more issues, more troubles, and more time to waste.

    Regarding the logs and configuration, I did collect enough information about the issue symptom, and many of them are actually in this thread - just scroll up and you will see. Specifically for the issue disappearing one time after Mediation Service restart you can see 2 screenshots with 4 packets, and you can see that the order of packets is changing after first call (that is successful first time after Mediation Service restart). Although due to luck of deep knowledge with SIP protocol (may be I should go deeper now) I cannot explain or even understand whether the problem is on Lync or on PBX side.

    If I was AVAYA person, I would blame Lync. Here the proof: nothing is changing on PBX side, while restart of the service make first call working. Second call does not work. So there is something inside Mediation server. Otherwise how to explain that restarting service fixes the issue (one time only)?

    Anyway, this is absolutely ridiculous case I've been working on in the whole life (over 25 years in IT). And this is the longest time I ever dealt with issue. And the funny part is that needs to be done somehow. It's like you want that Lync server will make a fresh muffins, but the vendor says: sorry, Lync cannot make fresh muffins, it is not compatible with muffins. But I say: sure, but I need it. So who you gonna call? Ghostbusters... :-)


    • Edited by lync15 Tuesday, April 24, 2012 5:16 PM
    Tuesday, April 24, 2012 5:15 PM
  • i've read all the tread but if you read cearfully what i'm saying is:

    1. collect traces from NIC (wireshark/netmon) not from lync processes, and you'll see what's going on (in-out)

    2. make sure cs1k side is clear in configuration (CS and SS and MC)

    3. make sure patches and dsp fw are up to date (because if ipphones are ok, then it is dsp, but there could be mistake in configuring it)

    4. if you are using collocated mediation - change local port of mediation to 5068 (and gw listening port in SS)

    5. collect traces from cs1k side (cs, ss, mc)

    and you don't need ace for sip trunks. they do work.

    Tuesday, April 24, 2012 6:52 PM
  • and this even can be a misconfiguration of lync routing, btw.

    Wednesday, April 25, 2012 5:13 AM
  • Most unlikely - our configuration is extremely simple and there is only one route in Lync - IP PBX. Any calls that do not have matching telephone number inside Lync (and there are only 3 numbers in Lync) are going to PBX. Please do not forget that this issue is only is specific scenarios as described above.

    Last week we noticed that after upgrade to version 7.5 (latest and greatest) now there is a new checkbox in PBX as shown on the picture below. We tried this but no luck - exactly same issue, so proceeded with purchase of Mediant 1000 gateway. It whould arrive this week, and then it will take some time to setup and configure everything. I will let you know what would be the results of this... 

    Monday, May 14, 2012 12:26 PM
  • Hello everybody!

    After having this issue for 1.5 years (yes it was from day one when Lync 2010 was deployed and connected to CS1000 IP PBX) I'm happy to finally close this thread.

    You may ask: why? what was the solution? And I would answer: AVAYA HOTFIX was recently released to fix 20 seconds delay issue. That's simple. That's it. Case slosed.

    20 seconds delay is no longer exist. Thanks to AVAYA for releasing this hotfix after 1.5 years since the problem started. You just made your own grave by doing this!

    Case is closed!

    • Marked as answer by lync15 Tuesday, July 3, 2012 12:11 PM
    Tuesday, July 3, 2012 12:11 PM
  • Thanx Alex for chiming in with the solution and congrats :)

    Hany George | Consultant | IDC S.p.A | MCITP: Lync Server | MCITP: Exchange 2010 | MCTS: OCS | Blog: http://dusk1911.wordpress.com/ | If this post has been useful please click the green arrow to the left or click Propose as answer

    Tuesday, July 3, 2012 12:17 PM
  • i guess the culprit is now in the open, but good for them for fixing.

    +Say thanks and observe basic forum courtesy:
    +If this post answered your question, Mark As Answer
    +If this post was helpful, Vote as Helpful

    windowspbx blog: my thots/howtos
    see/submit Lync suggestions here: simple and public

    Tuesday, July 3, 2012 12:19 PM
  • Unfortunately I do not have the article ID number (I even have no idea how to get it - I guess contact AVAYA) but here is what I have - text from this KB article - hopefully it will help other people to find out what hotfix is required (even though it does not mention Lync in fact this is a HOTFIX for Lync :-):

    Delay in setting up speech path with VGW and OCS

    Problem:
    --------
    The customer upgraded from 5.5 to 7.0, and as a result upgraded the MGC loadware from AP01 to BD01. Soon after that they started to experience speech
    path problems with OCS.
    - Incoming PSTN call routed to OCS were disconnected when answered on OCS client and the PSTN caller got a busy tone. But OCS client was not aware of
    call being disconnected (call timer continued to run as if call was going on).
    - Outgoing PSTN call from OCS client is connected as it should, but there is one-way speech (OCS-client can't hear other party). But after about 20 seconds
    or so, two way speech is established.

    Tuesday, July 3, 2012 2:30 PM