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/
