[Freeswitch-users] Trunking between Lync and FreeSWITCH

[David Ponzone]

Christian,

that's interesting, and I think I can help you to solve your one-way audio issue with inbound calls :)
You have to force the outbound codec from FS to Lync to be PCMU.
If you send it both PCMA and PCMU or PCMA only, the stupid Lync agrees on PCMA, but will send you PCMU anyway.
And those are the guys who are saying they follow the RFCs to the letter....

That should solve it.
And at the same time, this will probably eliminate your NAT/FW hypothesis, and I am sorry for that :)
With a normal audio,  and if you enable it, a normal RTCP flow, it becomes more difficult to understand why the call is disconnected, even before there is one REINVITE caused by session-timers.

I got some info from MS.
I got some web links with completely useless information (the currently certified equipements and the lengthy and painful process to be come certified):
http://technet.microsoft.com/en-us/lync/gg131938

Also some interesting info:
http://technet.microsoft.com/en-us/library/gg398619.aspx

What is interesting in that last document is that they never talk about a NAT topology. They only show examples without NAT.
So the question is: is it because they have issues with NAT that even FS can't circumvent, or is it because they wan't to discourage people to run SIP trunk to Lync over an unmanaged public Internet ?
As the outbound calls are working fine, I would tend to think the NAT is not an issue, and that's just MS being overcautious.

On the Lync side, it seems the amount of useful debugging info that can be obtained is close to 0, but I don't have access to the Lync, so I could be wrong.
You could probably confirm that point.

David Ponzone  Direction Technique
email: david.ponzone at ipeva.fr
tel:      01 74 03 18 97
gsm:   06 66 98 76 34

Service Client IPeva
tel:      0811 46 26 26
www.ipeva.fr  -   www.ipeva-studio.com

Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.



Le 30/04/2011 à 12:45, Christian Löschenkohl a écrit :

> hi
> 
> we have kind of the same issue in our lync test setup
> 
> - outbound calls work with two-way audio and with no disconnection
> - inbound calls work only with one-way audio and the disconnection from
> the lync side after exact 32 seconds
> 
> at the moment it looks like a firewall/nat problem to us (firewall is now a isa server).
> the next test will be done with an iptables firewall
> 
> if something new comes up, i'll post it here
> 
> br
> 
> 
> On 2011-04-28 23:24, David Ponzone wrote:
> 
>> Well, I thought I could start a thread about that.
>> I am trying to accomplish this, and I guess I am not the only one.
>> Lync 2010 seems to have quite some success (compared to OCS), so there are probably business opportunities around this.
>> 
>> My first attempt is a half success, as I got calls from Lync to FreeSWITCH working (need some extensive testing, though), and calls from FreeSWITCH to Lync are connecting ok, but they get disconnected after circa 30 seconds.
>> 
>> I am trying to pinpoint the reason for this disconnection, but untll now, I had no luck.
>> RTCP requirement was disabled on the Lync side (RTCPActiveCalls), but anyway I have enabled RTCP on the FreeSWITCH, so it should not be that.
>> RTP is flowing normally, it's not a call on hold or muted.
>> Refer was disabled on the Lync side.
>> SessionTimer is enabled on the Lync side (but I dont think I ever saw a REINVITE caused by the session timer).
>> I just suddenly receive a BYE from Lync, after 30-35 seconds.
>> On the Lync side, as you can guess, it's not easy to access any meaningful logs. I think our partner managing the Lync will have to escalate that to the SVP Product Engineering to get the right command to enable the interesting debug mode :)
>> 
>> I've been told that some folks at MS were claiming a such trunking was not possible.
>> Well, I would tend to say otherwise, as I am not far to get this working, except of course if they just hardcoded some forbidden Owner Usernames in the SDP, like FreeSWITCH, in order to save this business from the mean OpenSource world and leave it to commercial SBC vendors.
>> I can hardly imagine they would dare to do that in 2011, so the question remains opened: what may be closing that call after 30 seconds ?
>> 
>> I would be glad to discuss the subject, here or privately, with anyone who is involved on a such project, or planning to be soon.
>> 
>> David Ponzone Direction Technique
>> email: david.ponzone at ipeva.fr <mailto:david.ponzone at ipeva.fr>
>> tel: 01 74 03 18 97
>> gsm: 06 66 98 76 34

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110430/114c1307/attachment.html