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