Did I not point it out well enough? I posted a good SIP flow that you forwarded on to them, no?
I highlighted exactly what was supposed to happen. Their SIP stack is supposed to take the parameters in the Refer to header and build the INVITE from them. It really is that simple. Look at the signal example I gave you, it shows just that. Adtran is instead trying to compare the replaces value to their internal call database. This is where they're wrong. The replaces points to a dialog that is on another device entirely. So instead of trying to find the dialog that is on another device entirely, in their internal call database, they simply just need to build the invite with the parameters given in the refer-to and send it on it's way. On Thu, Dec 13, 2012 at 10:24 AM, Bryan Anderson <shadow...@gmail.com>wrote: > Here was their reply: > > "what specifically do you consider to be a problem in the SIP messaging?" > > -Bryan Anderson > > > > On Wed, Dec 12, 2012 at 3:36 PM, Bryan Anderson <shadow...@gmail.com>wrote: > >> Ok thanks. I just sent if off. I did just remember, they mentioned if >> the adtran is set for "Network" transfer vs "Local" it wouldn't work. >> >> "For example, the ADTRAN will not send an INVITE in response to a REFER >> if the transfer-mode is network" >> >> I tried setting the transfer mode to "Local" and when I park a call >> "transfer+ext" it kick the user into the voice mail of the person >> transferring them. >> >> Does that help with or change anything at all? Clearly its not right. >> >> -Bryan Anderson >> >> >> >> On Wed, Dec 12, 2012 at 2:33 PM, Josh Patten <jpat...@ezuce.com> wrote: >> >>> Try sending them my response to the mailing list and see where that gets >>> you. If they balk at it, then I'll see how I can explain it better to them. >>> >>> >>> On Wed, Dec 12, 2012 at 4:23 PM, Josh Patten <jpat...@ezuce.com> wrote: >>> >>>> With all the interop testing I've had to do I've become pretty good at >>>> picking things like this out and calling their bluff. Thanks Tony! >>>> >>>> >>>> On Wed, Dec 12, 2012 at 2:40 PM, Tony Graziano < >>>> tgrazi...@myitdepartment.net> wrote: >>>> >>>>> REFER has been around a while, not everyone supports it in a way that >>>>> makes sense (per the RFC). >>>>> >>>>> If REFER is supported, the accused scenario will work. If it is not >>>>> supported an SBC that can hold the refer locally and bridge the call legs >>>>> together and manage the transfers is required. >>>>> >>>>> The question to both Adtran and Digium is the same: Do you support >>>>> RFC-3515 (REFER) in product x. Which is exactly what Josh seems to have >>>>> asked. >>>>> >>>>> Go Josh! >>>>> >>>>> >>>>> On Wed, Dec 12, 2012 at 3:15 PM, Josh Patten <jpat...@ezuce.com>wrote: >>>>> >>>>>> It looks like Adtran and Digium are screaming the same thing. I'm >>>>>> going to post the response I sent to Digium: >>>>>> >>>>>> According to http://tools.ietf.org/html/rfc5589#page-26 (see the >>>>>> refer-to on page 27) this is a valid transfer scenario. I have attached a >>>>>> valid capture using FreeSWITCH as a gateway, and when the particular >>>>>> REFER >>>>>> that is giving the Adtran GW problems comes up, it simply performs >>>>>> the refer and marks the replaces in the INVITE (see highlights): >>>>>> >>>>>> REFER sip:gw+sip.corp.ezuce.com@172.16.1.90:5080;transport=udp;gw= >>>>>> sip.corp.ezuce.com SIP/2.0 >>>>>> From: <sip:4...@sip.corp.ezuce.com>;tag=4Ut224 >>>>>> To: "4092330016"<sip:~~id~me...@sip.corp.ezuce.com>;tag=Se415mQNX7D7D >>>>>> Call-Id: 4d339693-a499-1230-729f-fad9dc40d221 >>>>>> Cseq: 3 REFER >>>>>> Contact: <sip:41@172.16.1.5:5120;transport=tcp;x-sipX-nonat> >>>>>> Referred-By: <sip:4...@sip.corp.ezuce.com> >>>>>> Refer-To: <*sip:2...@sip.corp.ezuce.com?** >>>>>> REPLACES=a0511239-ab6decb2-99d54f8f%40172.16.1.51%3Bto-tag%3DCA50B7BD-573B246%3Bfrom-tag%3DLkTYH8&REQUIRE=replaces&X-sipX-Authidentity=%3Csip%3A%7E%7Eid%7Epark% >>>>>> 40sip.corp.ezuce.com >>>>>> %3Bsignature%3D509C36D7%253A%253Ad1b624445c9e26173fe0de17f291d62d%3E&REFERENCES=4d339693-a499-1230-729f-fad9dc40d221%3Brel%3Drefer >>>>>> *> >>>>>> References: a0511239-ab6decb2-99d54f8f@172.16.1.51;rel=xfer >>>>>> Date: Thu, 08 Nov 2012 22:48:55 GMT >>>>>> Max-Forwards: 19 >>>>>> User-Agent: sipXecs/4.6.0 sipXecs/park (Linux) >>>>>> Accept-Language: en >>>>>> >>>>>> Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE >>>>>> Supported: replaces >>>>>> Proxy-Authorization: Digest username="~~id~park", realm=" >>>>>> sip.corp.ezuce.com", >>>>>> nonce="5c81f6a19cf6bd3bcaefdfe726e2db2e509c36d7", >>>>>> uri="sip:gw+sip.corp.ezuce.com@172.16.1.90:5080;transport=udp;gw= >>>>>> sip.corp.ezuce.com", response="a8fdc3b3eeb0f5e52ef91342aba9df3f", >>>>>> cnonce="jbJLTS", qop=auth, nc=00000001 >>>>>> Via: SIP/2.0/UDP >>>>>> 172.16.1.5;branch=z9hG4bK-XX-0b96Qj3NNqiD6usxS_3GIL_emg >>>>>> Via: SIP/2.0/TCP 172.16.1.5:5120 >>>>>> ;branch=z9hG4bK-XX-003aW8u6STjzakMVEqA5D65UPg;id=18008-29 >>>>>> Content-Length: 0 >>>>>> >>>>>> SIP/2.0 202 Accepted >>>>>> Via: SIP/2.0/UDP >>>>>> 172.16.1.5;branch=z9hG4bK-XX-0b96Qj3NNqiD6usxS_3GIL_emg >>>>>> Via: SIP/2.0/TCP 172.16.1.5:5120 >>>>>> ;branch=z9hG4bK-XX-003aW8u6STjzakMVEqA5D65UPg;id=18008-29 >>>>>> From: <sip:4...@sip.corp.ezuce.com>;tag=4Ut224 >>>>>> To: "4092330016" <sip:~~id~me...@sip.corp.ezuce.com >>>>>> >;tag=Se415mQNX7D7D >>>>>> Call-ID: 4d339693-a499-1230-729f-fad9dc40d221 >>>>>> CSeq: 3 REFER >>>>>> Contact: <sip:gw+sip.corp.ezuce.com@172.16.1.90:5080 >>>>>> ;transport=udp;gw=sip.corp.ezuce.com> >>>>>> Expires: 60 >>>>>> User-Agent: FreeSWITCH-mod_sofia/1.2.3 >>>>>> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, >>>>>> REGISTER, REFER, NOTIFY >>>>>> Supported: timer, precondition, path, replaces >>>>>> Allow-Events: talk, hold, conference, refer >>>>>> Content-Length: 0 >>>>>> >>>>>> INVITE *sip:2...@sip.corp.ezuce.com* SIP/2.0 >>>>>> Via: SIP/2.0/UDP 172.16.1.90:5080;rport;branch=z9hG4bK2pQyFrXy5e8mN >>>>>> Max-Forwards: 70 >>>>>> From: "4092330016" <sip:4092330016@172.16.1.90>;tag=tQXt7F8rtg4SS >>>>>> To: <sip:2...@sip.corp.ezuce.com> >>>>>> Call-ID: 50251028-a499-1230-729f-fad9dc40d221 >>>>>> CSeq: 35871402 INVITE >>>>>> Contact: <sip:mod_sofia@172.16.1.90:5080> >>>>>> User-Agent: FreeSWITCH-mod_sofia/1.2.3 >>>>>> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, >>>>>> REGISTER, REFER, NOTIFY >>>>>> *Require: replaces* >>>>>> Supported: timer, precondition, path, replaces >>>>>> Allow-Events: talk, hold, conference, refer >>>>>> *Replaces: a0511239-ab6decb2-99d54f8f@172.16.1.51 >>>>>> ;to-tag=CA50B7BD-573B246;from-tag=LkTYH8* >>>>>> Content-Type: application/sdp >>>>>> Content-Disposition: session >>>>>> Content-Length: 255 >>>>>> X-FS-Support: update_display,send_info >>>>>> *X-sipX-Authidentity: <sip:~~id~p...@sip.corp.ezuce.com >>>>>> ;signature=509C36D7%3A%3Ad1b624445c9e26173fe0de17f291d62d> >>>>>> REFERENCES: 4d339693-a499-1230-729f-fad9dc40d221;rel=refer >>>>>> *Remote-Party-ID: "4092330016" <sip:4092330016@172.16.1.90 >>>>>> >;party=calling;screen=yes;privacy=off >>>>>> >>>>>> Obviously the Adtran will not have knowledge of it, it's a call >>>>>> dialog on a completely different SIP client. Refer-To does not use >>>>>> existing >>>>>> dialogs to perform REFER. This is allowed per RFC 3515: >>>>>> >>>>>> 2.4.3 Accessing the Referred-to Resource >>>>>> >>>>>> The resource identified by the Refer-To URI is contacted using the >>>>>> normal mechanisms for that URI type. For example, if the URI is a >>>>>> SIP URI indicating INVITE (using a method=INVITE URI parameter for >>>>>> example), the UA would issue a new INVITE using all of the normal >>>>>> rules for sending an INVITE defined in [1]. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Dec 12, 2012 at 11:12 AM, Bryan Anderson <shadow...@gmail.com >>>>>> > wrote: >>>>>> >>>>>>> So as I said before I am not well versed in the SIP protocol but >>>>>>> this was Adtrans response. >>>>>>> >>>>>>> Thanks Bryan, >>>>>>> >>>>>>> I do not believe this to be an ADTRAN issue. The call leg that is >>>>>>> being replaced only exists on that PBX. Check out the Refer message >>>>>>> sent >>>>>>> to the ADTRAN: >>>>>>> >>>>>>> Rx: UDP src=10.0.31.5:5060 dst=10.0.31.4:5060 >>>>>>> 18:07:20.905 SIP.STACK MSG REFER sip:10.0.31.4:5060 >>>>>>> ;transport= >>>>>>> UDP SIP/2.0 >>>>>>> 18:07:20.905 SIP.STACK MSG From: <sip:6...@inwsip.lcsnw.org >>>>>>> >;tag=NkynMZ >>>>>>> 18:07:20.905 SIP.STACK MSG To: >>>>>>> <sip:10.0.31.4>;tag=3bd6630-7f000001-13c4-2e2d5b-dce8ab25-2e2d5b >>>>>>> 18:07:20.906 SIP.STACK MSG Call-Id: >>>>>>> 3bffb58-7f000001-13c4-2e2d5b-cf3f8dba-2e2d5b@10.0.31.4 >>>>>>> 18:07:20.906 SIP.STACK MSG Cseq: 3 REFER >>>>>>> 18:07:20.906 SIP.STACK MSG Contact: <sip:6001@10.0.31.5:5120 >>>>>>> ;transport=tcp;x-sipX-nonat> >>>>>>> 18:07:20.906 SIP.STACK MSG Referred-By: < >>>>>>> sip:6...@inwsip.lcsnw.org> >>>>>>> 18:07:20.906 SIP.STACK MSG Refer-To: < >>>>>>> sip:5...@inwsip.lcsnw.org?REPLACES=a5320d9d-1d788972-8a9aa6d3%4010.0.27.106%3Bto-tag%3D1C951DC1-EB497A86%3Bfrom-tag%3Drp_5OC&REQUIRE=replaces&X-sipX-Authidentity=%3Csip%3A%7E%7Eid%7Epark%40inwsip.lcsnw.org%3Bsignature%3D50C7E6D8%253A%253A05936d0a35fdf946cde62d9a14e3e446%3E&REFERENCES=3bffb58-7f000001-13c4-2e2d5b-cf3f8dba-2e2d5b%4010.0.31.4%3Brel%3Drefer >>>>>>> > >>>>>>> 18:07:20.906 SIP.STACK MSG References: >>>>>>> a5320d9d-1d788972-8a9aa6d3@10.0.27.106;rel=xfer >>>>>>> 18:07:20.907 SIP.STACK MSG Date: Wed, 12 Dec 2012 02:07:20 >>>>>>> GMT >>>>>>> 18:07:20.907 SIP.STACK MSG Max-Forwards: 19 >>>>>>> 18:07:20.907 SIP.STACK MSG User-Agent: sipXecs/4.4.0 >>>>>>> sipXecs/park (Linux) >>>>>>> 18:07:20.907 SIP.STACK MSG Accept-Language: en >>>>>>> 18:07:20.907 SIP.STACK MSG Allow: INVITE, ACK, CANCEL, BYE, >>>>>>> REFER, OPTIONS, NOTIFY, SUBSCRIBE >>>>>>> 18:07:20.907 SIP.STACK MSG Supported: replaces >>>>>>> >>>>>>> Below is the Refer To from that message: >>>>>>> >>>>>>> Refer-To: < >>>>>>> sip:5...@inwsip.lcsnw.org?REPLACES=a5320d9d-1d788972-8a9aa6d3%4010.0.27.106%3Bto-tag%3D1C951DC1-EB497A86%3Bfrom-tag%3Drp_5OC&REQUIRE=replaces&X-sipX-Authidentity=%3Csip%3A%7E%7Eid%7Epark%40inwsip.lcsnw.org%3Bsignature%3D50C7E6D8%253A%253A05936d0a35fdf946cde62d9a14e3e446%3E&REFERENCES=3bffb58-7f000001-13c4-2e2d5b-cf3f8dba-2e2d5b%4010.0.31.4%3Brel%3Drefer >>>>>>> > >>>>>>> >>>>>>> The call-id is not seen anywhere else in this debug meaning, that >>>>>>> portion of the call is not on the ADTRAN. The ADTRAN accepts the Refer >>>>>>> to >>>>>>> it is up to the other device to tear that call down. >>>>>>> >>>>>>> Regards, >>>>>>> Geoff >>>>>>> >>>>>>> >>>>>>> -Bryan Anderson >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Dec 8, 2012 at 12:19 AM, Ali Ardestani < >>>>>>> ali.ardest...@pnmac.com> wrote: >>>>>>> >>>>>>>> You need to install ngrep and do an ngrep -Wbyline port 5060 to >>>>>>>> trace sip messaging >>>>>>>> >>>>>>>> >>>>>>>> On Friday, December 7, 2012, Bryan Anderson wrote: >>>>>>>> >>>>>>>>> So I pulled some tests and some traces, and have also opened a >>>>>>>>> ticket with Adtran. Using a Dialog Count I identified the following >>>>>>>>> callid's to be in reference to one call. >>>>>>>>> >>>>>>>>> I called into the system with my cell to an alias (1811) on the >>>>>>>>> extension(5063). I was parked on x6000. Extension 1802 retrieved the >>>>>>>>> call >>>>>>>>> and then we ended. (4=adtran 5=SipXecs, 181=x5603, 147=x1802) >>>>>>>>> >>>>>>>>> 61 INVITE 2012-12-07T20:05:51 >>>>>>>>> 3c0e5b8-7f000001-13c4-2892d7-e3be3276-2892d7@10.0.31.4 => 4311 -> >>>>>>>>> 1811(5063) -> 6000 >>>>>>>>> 30 INVITE 2012-12-07T20:06:21 >>>>>>>>> 3f55ee95-7ee55086-ee3f7323@10.0.31.181 => MoH >>>>>>>>> 30 INVITE 2012-12-07T20:06:27 >>>>>>>>> a93cae45-a1b73e76-8a9dd253@10.0.31.181 => 6000 >>>>>>>>> 33 INVITE 2012-12-07T20:06:28 >>>>>>>>> 3c0ed38-7f000001-13c4-2892fb-c2bd77a9-2892fb@10.0.31.4 => 6000 >>>>>>>>> 30 INVITE 2012-12-07T20:06:51 >>>>>>>>> 193ddbd-44cbfc8e-4975aa8b@10.0.31.147 => 1802 -> 6000 retrieve >>>>>>>>> call >>>>>>>>> 29 INVITE 2012-12-07T20:06:52 >>>>>>>>> 3c0eb58-7f000001-13c4-289313-94be59a7-289313@10.0.31.4 => (From >>>>>>>>> 1802 retrieving the call) 4311 -> 1802 >>>>>>>>> >>>>>>>>> Where does the BLF for the call park get so it doesn't release? >>>>>>>>> That is what I am looking for. I am sorry I just don't know the SIP >>>>>>>>> protocol well enough to find it on my own. I have seen this with >>>>>>>>> Polycom >>>>>>>>> firmwares 3.2.4, 3.2.7 and yes 3.3.0 and 4.0.3(this trace). I have a >>>>>>>>> debug >>>>>>>>> off the adtran to send to them, but they asked me were it is failing >>>>>>>>> and I >>>>>>>>> just don't know for sure myself. >>>>>>>>> >>>>>>>>> -Bryan Anderson >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Dec 7, 2012 at 11:16 AM, Bryan Anderson < >>>>>>>>> shadow...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> Thanks for the reply and I will defiantly test it. We use a T1 >>>>>>>>> for service into the Adtran and the Adtran is in SipXecs as an >>>>>>>>> unmanaged >>>>>>>>> gateway. >>>>>>>>> >>>>>>>>> -Bryan Anderson >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Dec 7, 2012 at 11:07 AM, Ali Ardestani < >>>>>>>>> ali.ardest...@pnmac.com> wrote: >>>>>>>>> >>>>>>>>> This is how we implemented call park with polycom and it works (it >>>>>>>>> is a workaround though) >>>>>>>>> >>>>>>>>> 1. Extension 700 forwards to 701, 702, 703 and 703 >>>>>>>>> >>>>>>>>> 2. added the below to the custom config of the phones (this is >>>>>>>>> done so that the key does not timeout after 1 minute and call the park >>>>>>>>> orbit directly >>>>>>>>> <call >>>>>>>>> call.offeringTimeOut="3600" >>>>>>>>> call.directedCallPickupMethod="legacy" >>>>>>>>> call.parkedCallRetrieveMethod="legacy" >>>>>>>>> > >>>>>>>>> >>>>>>>>> 3. subscribe to the presence of 700 on user speed dials >>>>>>>>> >>>>>>>>> 4. Make sure you use the bridge, we had problems with the call >>>>>>>>> unparking when we did not use the bridge for incoming calls from trunk >>>>>>>>> provider >>>>>>>>> >>>>>>>>> *5. Our firewal does ALG, so we had to uncheck "Use public >>>>>>>>> address for call setup" under Devices=>Gateways(choose the gw)=>ITSP >>>>>>>>> Account, This fixed our problem with the calls unparking, maybe your >>>>>>>>> firewall is also doing some form of ALG* >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Dec 7, 2012 at 10:06 AM, Bryan Anderson < >>>>>>>>> shadow...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> So I noticed some talk in a previous email "Call forward fails to >>>>>>>>> external number" about the Adtran 900 series. I have a couple of >>>>>>>>> comments >>>>>>>>> and questions. >>>>>>>>> >>>>>>>>> We have a TA908e 2nd gen running AOS A5.02.00.E. We currently >>>>>>>>> have not noticed any issue with having an external caller forwarded >>>>>>>>> to and external number. cell => user for 30sec => external >>>>>>>>> number. >>>>>>>>> >>>>>>>>> What we have had issues with is presence monitoring of call >>>>>>>>> parking. We have a Polycom Soundpoint IP 650 with a sing side >>>>>>>>> car that monitors park lines 6000 - 6003. We can park calls no >>>>>>>>> problem, >>>>>>>>> and so far have not had trouble retrieving calls. Our problem is >>>>>>>>> that once the call gets retrieved from the call park the BLF >>>>>>>>> never stops blinking. I have to restart the Park/Presence >>>>>>>>> servers. >>>>>>>>> >>>>>>>>> This is with SipXecs 4.4.0. >>>>>>>>> >>>>>>>>> Thoughts and comments would be appreciated. >>>>>>>>> >>>>>>>>> >>>>>>>>> -Bryan Anderson >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> sipx-users mailing list >>>>>>>>> sipx-users@list.sipfoundry.org >>>>>>>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> -- >>>>>>>>> Ali S Ardestani >>>>>>>>> Telephony Systems Engineer >>>>>>>>> Private National Mortgage Acceptance Company (PennyMac) >>>>>>>>> 6101 Condor Drive >>>>>>>>> Moorpark, CA 93021 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> -- >>>>>>>> Ali S Ardestani >>>>>>>> Telephony Systems Engineer >>>>>>>> Private National Mortgage Acceptance Company (PennyMac) >>>>>>>> 6101 Condor Drive >>>>>>>> Moorpark, CA 93021 >>>>>>>> >>>>>>>> (805) 330-6004 Office >>>>>>>> (818) 224-7442 x2654 Office >>>>>>>> (626) 817-3512 Mobile >>>>>>>> (818) 224-7397 Fax >>>>>>>> >>>>>>>> ali.ardest...@pnmac.com >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> sipx-users mailing list >>>>>>>> sipx-users@list.sipfoundry.org >>>>>>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sipx-users mailing list >>>>>>> sipx-users@list.sipfoundry.org >>>>>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Josh Patten >>>>>> eZuce >>>>>> Solutions Architect >>>>>> O.978-296-1005 X2050 >>>>>> M.979-574-5699 >>>>>> http://www.ezuce.com >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sipx-users mailing list >>>>>> sipx-users@list.sipfoundry.org >>>>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ~~~~~~~~~~~~~~~~~~ >>>>> Tony Graziano, Manager >>>>> Telephone: 434.984.8430 >>>>> sip: tgrazi...@voice.myitdepartment.net >>>>> 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: >>>>> helpdesk@voice.myitdepartment.**net<helpd...@voice.myitdepartment.net> >>>>> >>>>> Helpdesk Customers: >>>>> http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net> >>>>> Blog: http://blog.myitdepartment.net >>>>> >>>>> _______________________________________________ >>>>> sipx-users mailing list >>>>> sipx-users@list.sipfoundry.org >>>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>>> >>>> >>>> >>>> >>>> -- >>>> Josh Patten >>>> eZuce >>>> Solutions Architect >>>> O.978-296-1005 X2050 >>>> M.979-574-5699 >>>> http://www.ezuce.com >>>> >>>> >>> >>> >>> -- >>> Josh Patten >>> eZuce >>> Solutions Architect >>> O.978-296-1005 X2050 >>> M.979-574-5699 >>> http://www.ezuce.com >>> >>> >>> _______________________________________________ >>> sipx-users mailing list >>> sipx-users@list.sipfoundry.org >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >> >> > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- Josh Patten eZuce Solutions Architect O.978-296-1005 X2050 M.979-574-5699 http://www.ezuce.com
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
