Hi Tony, It would be much easier for me to to run a tcpdump on the sipXecs box than it would be on the Avaya one, and I would be quite happy to.
With the limitation of not being able to use an AA as a method to get to "extensions" that are not directly "dialable" from the Avaya, my only interest in debugging this is to resolve a possible bug in sipXecs, possibly by proving a bug onto Avaya. I'm quite happy to do this, but it's no skin off my nose if it doesn't work. As the AA can "transfer" to an extension correctly, but the "transfer" to the conference fails, my feeling is that sipXecs is sending a different "transfer" for the two cases. As a for instance, could it be that the SIP message is different for the two cases ? I appreciate that my language might not be completely accurate, but I would hope that it can be interpreted by somebody that knows both the TDM world and the SIP one. Cheers Arne On Wed, Oct 28, 2009 at 10:18 AM, Tony Graziano <tgrazi...@myitdepartment.net> wrote: > Do you have any way of getting a deep level log or a pcap file from the > failed case from the avaya? > > Alternately, you can create a user with a personal auto attendant to try to > route the calls and see if the personal AA handles the transfers > differently, though you are linited to 9 separate keypresses and it does not > allow you to find them in a dial by name fashion. > ============================ > Tony Graziano, Manager > Telephone: 434.984.8430 > Fax: 434.984.8431 > > Email: tgrazi...@myitdepartment.net > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > Fax: 434.984.8427 > > Helpdesk Contract Customers: > http://www.myitdepartment.net/gethelp/ > > ----- Original Message ----- > From: shouldbe q931 <shouldbeq...@googlemail.com> > To: Tony Graziano <tgrazi...@myitdepartment.net>; sipXecs users > <sipx-users@list.sipfoundry.org> > Sent: Wed Oct 28 06:14:05 2009 > Subject: Re: [sipx-users] conferencing capabilities > > Any further suggested next steps for seeing where the problem lies ? > > Cheers > > Arne > > On Tue, Oct 27, 2009 at 9:31 AM, shouldbe q931 > <shouldbeq...@googlemail.com> wrote: >> Just to clarify, that works for both cases, calling 6810, or calling >> 6815 (the AA), and then doing a blind transfer to 6810 >> >> Cheers >> >> Arne >> >> On Tue, Oct 27, 2009 at 9:21 AM, shouldbe q931 >> <shouldbeq...@googlemail.com> wrote: >>> Hi Tony, >>> >>> Having a forward on 6810 to 6812 works, I get the "please enter your >>> conference number" prompt. >>> >>> Cheers >>> >>> Arne >>> >>> On Mon, Oct 26, 2009 at 9:33 PM, Tony Graziano >>> <tgrazi...@myitdepartment.net> wrote: >>>> THEN if you take user 6810 and do a permanent forward to 6812 in sipx, >>>> does >>>> it work dialing 6810 from the avaya? >>>> >>>> On Mon, Oct 26, 2009 at 4:57 PM, shouldbe q931 >>>> <shouldbeq...@googlemail.com> >>>> wrote: >>>>> >>>>> okay, I'm probably coming at this from the wrong angle. >>>>> >>>>> I'm seeing the "blind transfer" work when it goes to 6810 (a user >>>>> "extension" without a phone attached, so it goes to voicemail), but >>>>> not working when the destination is 6812 (a conference extension), and >>>>> having trouble seeing why it would work in one case, and not the other >>>>> unless sipXecs is doing (sending to the Avaya) something different... >>>>> >>>>> Could it be that sipXecs is sending something differently in the two >>>>> cases >>>>> ? >>>>> >>>>> Rather than bringing a softphone into the mix, I'm wondering if it >>>>> would be better to use tcpdump/wireshark to check that what is going >>>>> over the wire is the same, if it is, then I can look at opening a case >>>>> with Avaya,... >>>>> >>>>> Cheers >>>>> >>>>> Arne >>>>> >>>>> On Mon, Oct 26, 2009 at 8:25 PM, Scott Lawrence >>>>> <scott.lawre...@nortel.com> wrote: >>>>> > On Mon, 2009-10-26 at 20:09 +0000, shouldbe q931 wrote: >>>>> >> I can certainly try adding a softphone to the mix tomorrow. >>>>> >> >>>>> >> Granted its from an external call (I'm not in the office this late), >>>>> >> but the following tac trace shows a working blind transfer to the >>>>> >> "goes to voicemail" extension (6810), which makes me think that it >>>>> >> could be the conference part isn't "picking up" correctly from a >>>>> >> blind >>>>> >> transfer.... >>>>> > >>>>> > No, that's not it - the call never gets to the sipXproxy at all, and >>>>> > it >>>>> > would have to go through the proxy to reach the conference bridge. >>>>> > >>>>> > >>>>> _______________________________________________ >>>>> sipx-users mailing list sipx-users@list.sipfoundry.org >>>>> List Archive: http://list.sipfoundry.org/archive/sipx-users >>>>> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users >>>>> sipXecs IP PBX -- http://www.sipfoundry.org/ >>> >> > _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
