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/
