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/
