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 >>> parklines 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/
