Quantcast

Trunking between Lync and FreeSWITCH

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Trunking between Lync and FreeSWITCH

David Ponzone
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
tel:      01 74 03 18 97
gsm:   06 66 98 76 34

Service Client IPeva
tel:      0811 46 26 26
<a href="BLOCKED::http://www.ipeva.fr/">www.ipeva.fr  -   <a href="BLOCKED::http://www.ipeva-studio.com/">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.





_______________________________________________
FreeSWITCH-users mailing list
[hidden email]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Trunking between Lync and FreeSWITCH

Kristian Kielhofner-3
Interesting.  Can you put a sip trace up between Lync and FreeSWITCH?

On Thu, Apr 28, 2011 at 5:24 PM, David Ponzone <[hidden email]> 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: [hidden email]
> 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.
>
>
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> [hidden email]
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>



--
Kristian Kielhofner

_______________________________________________
FreeSWITCH-users mailing list
[hidden email]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Trunking between Lync and FreeSWITCH

Christian Löschenkohl
In reply to this post by David Ponzone
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: [hidden email] <mailto:[hidden email]>
> tel: 01 74 03 18 97
> gsm: 06 66 98 76 34
>
> Service ClientIPeva
> tel: 0811 46 26 26
> www.ipeva.fr <BLOCKED::http://www.ipeva.fr/>- www.ipeva-studio.com <BLOCKED::http://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./
> /
> /
>
>
>
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> [hidden email]
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org


--
Ing. Christian Löschenkohl
Technische Leitung, Forschung & Entwicklung VoIP

xpirio
Telekommunikation & Service GmbH
Lakeside B04
9020 Klagenfurt
Austria

T  +43 5 77 11 - 1000
F  +43 5 77 11 - 1002
E  [hidden email]

_______________________________________________
FreeSWITCH-users mailing list
[hidden email]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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):

Also some interesting info:

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
tel:      01 74 03 18 97
gsm:   06 66 98 76 34

Service Client IPeva
tel:      0811 46 26 26
<a href="BLOCKED::http://www.ipeva.fr/">www.ipeva.fr  -   <a href="BLOCKED::http://www.ipeva-studio.com/">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: [hidden email] <[hidden email]>
tel: 01 74 03 18 97
gsm: 06 66 98 76 34


_______________________________________________
FreeSWITCH-users mailing list
[hidden email]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Trunking between Lync and FreeSWITCH

Vitalie Colosov
I saw the cases when call is disconnected after 32 seconds when one of the parties does not receive the ACK message after sending the OK message when call is answered.
It was not with Lync, but with some crappy sip client.
Maybe you can investigate in this direction.

Vitalie

_______________________________________________
FreeSWITCH-users mailing list
[hidden email]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Trunking between Lync and FreeSWITCH

David Ponzone
Vitalie,

that was actually a good idea, and I just checked that on my trace.
Too bad, the ACK from FreeSWITCH is correctly received by Lync.

On my side, I think the next step will be to do a test without NAT, just to be on the safe side.

David Ponzone  Direction Technique
tel:      01 74 03 18 97
gsm:   06 66 98 76 34

Service Client IPeva
tel:      0811 46 26 26
<a href="BLOCKED::http://www.ipeva.fr/">www.ipeva.fr  -   <a href="BLOCKED::http://www.ipeva-studio.com/">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 à 22:07, Vitalie Colosov a écrit :

I saw the cases when call is disconnected after 32 seconds when one of the parties does not receive the ACK message after sending the OK message when call is answered.
It was not with Lync, but with some crappy sip client.
Maybe you can investigate in this direction.

Vitalie
_______________________________________________
FreeSWITCH-users mailing list
[hidden email]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org


_______________________________________________
FreeSWITCH-users mailing list
[hidden email]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Trunking between Lync and FreeSWITCH

njfm
This post has NOT been accepted by the mailing list yet.
In reply to this post by David Ponzone
Hello,

Has anyone found a solution to this problem of call being dropped after 30 seconds even when the audio is flowing in both ways?

Thanks,
Loading...