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/
