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 <[email protected]> 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:[email protected]:5080;transport=udp;gw= > sip.corp.ezuce.com SIP/2.0 > From: <sip:[email protected]>;tag=4Ut224 > To: "4092330016"<sip:[email protected]>;tag=Se415mQNX7D7D > Call-Id: 4d339693-a499-1230-729f-fad9dc40d221 > Cseq: 3 REFER > Contact: <sip:[email protected]:5120;transport=tcp;x-sipX-nonat> > Referred-By: <sip:[email protected]> > Refer-To: <*sip:[email protected]?** > 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: [email protected];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:[email protected]: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:[email protected]>;tag=4Ut224 > To: "4092330016" <sip:[email protected]>;tag=Se415mQNX7D7D > Call-ID: 4d339693-a499-1230-729f-fad9dc40d221 > CSeq: 3 REFER > Contact: <sip:[email protected]: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:[email protected]* SIP/2.0 > Via: SIP/2.0/UDP 172.16.1.90:5080;rport;branch=z9hG4bK2pQyFrXy5e8mN > Max-Forwards: 70 > From: "4092330016" <sip:[email protected]>;tag=tQXt7F8rtg4SS > To: <sip:[email protected]> > Call-ID: 50251028-a499-1230-729f-fad9dc40d221 > CSeq: 35871402 INVITE > Contact: <sip:[email protected]: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: [email protected] > ;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:[email protected] > ;signature=509C36D7%3A%3Ad1b624445c9e26173fe0de17f291d62d> > REFERENCES: 4d339693-a499-1230-729f-fad9dc40d221;rel=refer > *Remote-Party-ID: "4092330016" <sip:[email protected] > >;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 <[email protected]>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:[email protected] >> >;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: >> [email protected] >> 18:07:20.906 SIP.STACK MSG Cseq: 3 REFER >> 18:07:20.906 SIP.STACK MSG Contact: <sip:[email protected]:5120 >> ;transport=tcp;x-sipX-nonat> >> 18:07:20.906 SIP.STACK MSG Referred-By: < >> sip:[email protected]> >> 18:07:20.906 SIP.STACK MSG Refer-To: < >> sip:[email protected]?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: >> [email protected];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:[email protected]?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 >> <[email protected]>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 >>>> [email protected] => 4311 -> >>>> 1811(5063) -> 6000 >>>> 30 INVITE 2012-12-07T20:06:21 >>>> [email protected] => MoH >>>> 30 INVITE 2012-12-07T20:06:27 >>>> [email protected] => 6000 >>>> 33 INVITE 2012-12-07T20:06:28 >>>> [email protected] => 6000 >>>> 30 INVITE 2012-12-07T20:06:51 >>>> [email protected] => 1802 -> 6000 retrieve call >>>> 29 INVITE 2012-12-07T20:06:52 >>>> [email protected] => (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 <[email protected]>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 <[email protected] >>>> > 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 <[email protected]>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 >>>> [email protected] >>>> 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 >>> >>> [email protected] >>> >>> >>> _______________________________________________ >>> 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/ >> > > > > -- > Josh Patten > eZuce > Solutions Architect > O.978-296-1005 X2050 > M.979-574-5699 > http://www.ezuce.com > > > _______________________________________________ > 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] 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/
