Ah. Vvx500. I was think vvx1500 On Jul 19, 2012 4:48 PM, "Philippe Laurent" <[email protected]> wrote:
> The packet loss did seem awfully odd and repeatable. > > I won't be on site at the client location until at least next week, so I > hesitate to make any firmware changes when I don't have the capacity to > reach out and hard reset, especially with the relatively new VVX500. > > Don't see any 3.2 downgrades for the VVX. Looks like the 4.0x series is > all there is to choose. Next time I'm by that location, I could pop in an > IP650 and see how it behaves. > > > On Thu, Jul 19, 2012 at 4:28 PM, Tony Graziano < > [email protected]> wrote: > >> FYI - I don't think I should see packet loss.There is packet loss during >> the DTMF. I am going out on a lomb here, but would suggest it is a call the >> patton is discarding because it does not know how to re-route it. I have >> seen this with call park return. >> >> If this continues to be the case it would be an issue where the patton is >> having a problem with the destination. "Why" we don't know. I would suspect >> a dial plan entry in the SN to be able to convert or transform it in a way >> that would alleviate that. >> >> (i.e. why is the from "anonymous" where it should know where it is from). >> The firmware on the patton is correct. Do you have a way to put a 3.2 >> firmware on the destination (v v x)? >> >> >> On Thu, Jul 19, 2012 at 4:18 PM, Philippe Laurent <[email protected]> wrote: >> >>> Just heard from Patton, who indicated that there was a trans-coding >>> issue, with one side speaking ulaw and the other alaw during the transfer. >>> Dunno why this is, since all devices (Patton, PBX, phones) are set to >>> prioritize ulaw over alaw. The Patton 4112 apparently does not support >>> trans-coding. >>> >>> So, I set the Patton to talk only ulaw, saved and reloaded (you know, >>> for good luck), and boom, it works. Not great, but it works. During the >>> transfer, I get music for about 2 seconds, and then silence. No ringing, no >>> anything, until a phone in the hunt group picks up. Ringing of continued >>> tunes would ease the mind of the person on the other end. >>> >>> Patton debug is on the way, but won't have access to the client's site >>> until this evening to do any testing. >>> >>> Philippe >>> >>> On Thu, Jul 19, 2012 at 4:06 PM, Tony Graziano < >>> [email protected]> wrote: >>> >>>> Can you shoot me a sip debug of the transaction? >>>> >>>> Since it is a sipx ivr (version 4.4/latest, right?), both transactions >>>> are "attended transfers" from the IVR (I am assuming). >>>> >>>> If it were me, I would try to create a phantom user with no VM >>>> permissions and have the forwarding on "all the time" to the intended >>>> recipient, then add that phantom user as an option on the IVR and see if >>>> that works. I have found that hunt groups have been geeting frustratingly >>>> difficult lately. Post back the results. >>>> >>>> On Thu, Jul 19, 2012 at 3:37 PM, Philippe Laurent <[email protected]>wrote: >>>> >>>>> Yeah, I know, this is a SipX list, not a Patton list. I'm working >>>>> with their tech support, but we're not getting very far, and since the >>>>> Patton 4112 is connected to a SipX box, and there a quite a few Patton >>>>> fans >>>>> out there working with SipX, I wanted to make sure I wasn't missing >>>>> something obvious in the link. >>>>> >>>>> Patton 4112: SIP registered to SipX extension, FXS port connected to >>>>> pharmacy IVR >>>>> >>>>> Here goes: >>>>> 1. Caller dials 8 from the auto attendant, transfers to the pharmacy >>>>> IVR on the Patton FXS port. Success. >>>>> 2. If the caller decides they want to speak to someone while sitting >>>>> on the IVR on the Patton, they dial 2. >>>>> 3. The FXS IVR then dials the 600 extension to ring the hunt group on >>>>> SipX. The sequence used by the FXS IVR to transfer the call is Hook-flash, >>>>> then dial 600, then terminate. This fails to transfer the call (no >>>>> ringing), and the call terminates. >>>>> >>>>> Clearly something isn't done right, or I've missed a concept. Should >>>>> the FXS IVR should be dialing a different string set to transfer the call? >>>>> The vendor says they can define the transfer on their side to match >>>>> requirements. >>>>> >>>>> Many thanks in advance for your time. >>>>> >>>>> _______________________________________________ >>>>> sipx-users mailing list >>>>> [email protected] >>>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>>> >>>> >>>> >>>> >>>> -- >>>> ~~~~~~~~~~~~~~~~~~ >>>> Tony Graziano, Manager >>>> Telephone: 434.984.8430 >>>> sip: [email protected] >>>> Fax: 434.465.6833 >>>> ~~~~~~~~~~~~~~~~~~ >>>> Linked-In Profile: >>>> http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >>>> Ask about our Internet Fax services! >>>> ~~~~~~~~~~~~~~~~~~ >>>> >>>> Using or developing for sipXecs from SIPFoundry? Ask me about >>>> sipX-CoLab 2013!<http://sipxcolab2013.eventbrite.com/?discount=tony2013> >>>> >>>> >>>> LAN/Telephony/Security and Control Systems Helpdesk: >>>> Telephone: 434.984.8426 >>>> sip: [email protected].**net<[email protected]> >>>> >>>> Helpdesk Customers: >>>> http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net> >>>> Blog: http://blog.myitdepartment.net >>>> >>>> _______________________________________________ >>>> sipx-users mailing list >>>> [email protected] >>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>> >>> >>> >>> _______________________________________________ >>> sipx-users mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >> >> >> >> -- >> ~~~~~~~~~~~~~~~~~~ >> Tony Graziano, Manager >> Telephone: 434.984.8430 >> sip: [email protected] >> Fax: 434.465.6833 >> ~~~~~~~~~~~~~~~~~~ >> Linked-In Profile: >> http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >> Ask about our Internet Fax services! >> ~~~~~~~~~~~~~~~~~~ >> >> Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab >> 2013! >> <http://sipxcolab2013.eventbrite.com/?discount=tony2013> >> >> >> LAN/Telephony/Security and Control Systems Helpdesk: >> Telephone: 434.984.8426 >> sip: [email protected].**net<[email protected]> >> >> Helpdesk Customers: >> http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net> >> Blog: http://blog.myitdepartment.net >> >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> > > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Helpdesk Customers: http://myhelp.myitdepartment.net Blog: http://blog.myitdepartment.net
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
