Alright, I have a new logfile dump in pastebin http://pastebin.freeswitch.org/17403 This timeline goes a little different... Mitel 1 picks up the Shared Line, calls the echo test, puts it on hold, and Mitel 2 tries to pick up the shared line but gets voicemail. I've compared the call-info line and they seem to match.... and in the default dialplan the extension is defined... otherwise how am I getting the voicemail? Line 950 is where the 2nd phone tries to pick up.... as you can see after that it has the correct appearance-id and call-info: Line 1065 looks like Freeswitch is making a new call instead of capturing the old one. Hope this is of some help Thanks, Adam On Mon, Sep 26, 2011 at 2:39 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
Probably the barge in call is missing the replaces info or the correct appearance-index in the call-info or possibly you are not using the user/ channel in your dialplan which would mean you have to manually set presence_id as done in the default.xml from the stock dialplan template.
On Mon, Sep 26, 2011 at 1:38 AM, <aromberg@gmail.com> wrote:
Here's the quick synopsis: Freeswitch on CentOS 6 freshly installed 2 days ago. Freeswitch was grabbed via git. Phones are Mitel 5220 SIP phones that are in SIP mode. Mitel has a Broadsoft implementation called SIP_SCA in the device registration. There is 1 Cisco 7960 but its not configured at all for the shared extension.
I can't get it to work. I *think* I have it narrowed down to the presence ID being different on a per-phone basis. The LEDS show the correct call status (on-hook, ringing, on hold, etc). However, when you press the shared line from another phone, it dials the extension again and goes straight to voicemail/busy instead of seizing the line. All extensions are configured correctly (calling the shared extension from the Cisco results in both phones ringing and able to pick up the call initially)
Logfiles are located at: http://iis.powertogrow.com/fs
Each one has the same actions:
Mitel phone 1 (192.168.1.106/extention 1002) calls Cisco Phone 2 (192.168.1.103/#1000) on Shared Line 1003. Cisco answers. Mitel Phone 1 puts call on hold. Mitel phone 2 (192.168.1.100/#1001) tries to pick up Shared Line 1003 and then hangs up when it hears the voicemail system. It normally does this twice. Then Mitel phone 1 picks up Shared Line 1003 and ends it.
No matter what order the steps are done with whatever phone (well, except the Cisco doesn't have a shared line), the results are the same. Picking up the shared line results in a forward to the VM system
Thanks,
Adam