IP Office Twinned Calls Forwarding to Twin Destination- Resolved- AT&T sending premature connect msg 8

[SamIPOfficeSupport]

Hello IP Office Gurus, lurkers, and fellow internet users,

I have run into a weird problem. The twinning function is causing the call to the local IP Office user to drop. A call presents to the user but once it starts twinning the call that rings the desk phone is dropped.. so that the call is no longer available (or visible) to the local phone extension. The person calling in is not dropped, and they can be picked up at the twinned location. So, once twinning occurs, the incoming call is made unavailable to the desk phone.. If you have any ideas, please let me know.

 

[fonedude]

did you put a 9 before the twinned number?

 

[Westi]

did you do a reboot on the IPO yet?
sorry to ask the obvious but that would be my first action I take before hunting a ghost

Joe W.

FHandw, ACSS (SME)


"This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter

 

[SamIPOfficeSupport]

Hi guys! Thanks for the responses! Totally agree with you Westi.. this one is a ghost. Yes, we have rebooted many times, and have 9 in front of the twinned destination. Actually, the problem is not with the caller making it to the twin destination.. it gets there fine. The problem is that once the twinning mechanism is activated, the IP Office desk phone can no longer answer the call.. almost as if it forwards to the twin destination instead of ringing both locations. I can capture some logs if you think that'd be helpful.

 

[TouchToneTommy]

PRI, SIP, or analog lines?

 

[SamIPOfficeSupport]

Hi there Tommy. It's a PRI handoff, provided by our good friends at AT&T . I've got a ticket opened with them (and they keep closing the tickets without talking to me).. typical.

 

[janni78]

Do you have Partial Rerouting enabled on the PRI?

"Trying is the first step to failure..." - Homer

 

[SamIPOfficeSupport]

Hello Janni, thanks for checking in on this one. I'm not sure which setting you are referencing, but here's an image of the PRI settings. Still no word from AT&T

 

[rlsabin]

Does it exhibit this behavior on all twinned phones or just one? Does the user's cell phone have an app on it that could be causing the cell phone carrier to treat the call as being answered even though the caller is still hearing ringing. If this occurs on multiple phones do they all share a common cell phone provider?

Rick

 

[SamIPOfficeSupport]

Thanks for chipping in rlsabin! This issue does not seem to be user-specific, or twinned destination carrier-specific.

I think a more accurate description of this problem is "twinned calls are forwarding to the twin destination".. because the twinning part of the feature is working.. but the calls are forwarding to the twinned location, instead of being made available to both endpoints at once.

If I change the destination to my Verizon cell phone, or if I point the twinning destination to my desk phone through our TPx PRI, the results do not change. In all cases, the twinning destination is able to answer the phone call.. but the IP Office user is unable to pick up the call from their desk phone once once the dial delay timer expires. Actually, once the dial delay timer expires, the call to the IP Office user drops from their call appearance altogether. So, once the twinning feature is activated, it seems like the IP Office is forwarding the call to the twinning destination, and dropping the call from the IP Office desk phone. The calling party is not dropped and hears ringing just like any normal call, and the twinning destination is able to answer the call in all instances.

Increasing the dial delay timer changes the point when the "forwarding" to the twin destination occurs. So if we increase the dial delay timer from 6 seconds to 10 seconds, the user is able to answer the call at their desk phone for 10 seconds. But as soon as twinning is activated, the call disappears from their IP Office phone and forwards to the twinning destination.

I think we're probably going to need to see logs for this one.. I'll capture a call and post it here soon. Thank you all for checking in on this one.

 

[IPGuru]

the case of the problem is the IPO believing that the external call has answered.
Normally this is the case if you try to twin on analog lines (hence why the documents say not supported)
if you are on a pri circuit system monitor should be able to confirm that the provider is indeed flagging the call as answered. tThis is something you will have to take up with the line provider, it is not something that can be fixed ob the IPO side




Do things on the cheap & it will cost you dear

 

[SamIPOfficeSupport]

Hi IPGuru, thanks for the feedback. I was starting to lean towards AT&T on this... I'll get a call sample and post it here.

 

[bluemr2]

I'm having this exact issue with AT+T right now. IPGuru is exactly right. If you look at the PRI trace, as soon as the twinned call is created, AT+T sends back a connect message. We had it fixed, but now it reverted back. There is a setting in their Adtran that needs to be disabled.

 

[SamIPOfficeSupport]

Thank you all for the help on this! I think this proves that the CO is sending a connect:

09:15:49 96690341mS ISDNL3Rx: v=1 peb=1
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=0026(Local)
Message Type = Connect

And, here's a larger portion of that part of the call. I hope this helps some other IP Office internet users with forcing AT&T's hand!

09:15:49 96690164mS PRN: Monitor Status IP 500 V2 9.1.12.0 build 213
09:15:49 96690165mS PRN: LAW=U PRI=1, BRI=0, ALOG=4, VCOMP=10, MDM=0, WAN=0, MODU=0 LANM=0 CkSRC=1 VMAIL=1(VER=3 TYP=1) 1-X=0 CALLS=7(TOT=589)
09:15:49 96690339mS ISDNL1Rx: v=1 peb=1
0000 02 01 66 04 08 02 80 26 01 1e 02 82 88 ..f....&.....
09:15:49 96690339mS ISDNL2Rx: v=1 peb=1
0000 02 01 66 04 08 02 80 26 01 1e 02 82 88 ..f....&.....
09:15:49 96690339mS ISDNL3Rx: v=1 peb=1
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=0026(Local)
Message Type = Alerting
InformationElement = PI
0000 1e 02 82 88 ....
09:15:49 96690340mS ISDNL3Evt: v=1 stacknum=1 State, new=Delivered, old=Proceeding id=3582
09:15:49 96690341mS ISDNL2Tx: v=1 peb=1
0000 02 01 01 68 ...h
09:15:49 96690341mS ISDNL1Rx: v=1 peb=1
0000 02 01 68 04 08 02 80 26 07 ..h....&.
09:15:49 96690341mS ISDNL2Rx: v=1 peb=1
0000 02 01 68 04 08 02 80 26 07 ..h....&.
09:15:49 96690341mS ISDNL3Rx: v=1 peb=1
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=0026(Local)
Message Type = Connect
09:15:49 96690342mS ISDNL3Evt: v=1 stacknum=1 State, new=Active, old=Delivered id=3582
09:15:49 96690342mS ISDNL3Tx: v=1 peb=1
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=0026(Remote)
Message Type = ConnectAck
09:15:49 96690342mS ISDNL2Tx: v=1 peb=1
0000 00 01 04 6a 08 02 00 26 0f ...j...&.
09:15:49 96690343mS ISDNL1Tx: v=1 peb=1
0000 02 01 01 68 ...h
09:15:49 96690344mS ISDNL1Tx: v=1 peb=1
0000 00 01 04 6a 08 02 00 26 0f ...j...&.
09:15:49 96690344mS CMCallPkt: v=0
CMAlerting
Line: type=Q931Line 1 Call: lid=0 id=3582 in=0
IE CMIEProgressIndicator (30) cs=CMCSITUT (0), loc=CMLPublicNetLocalUser (2), pd=CMPDInbandPattern (8)
09:15:49 96690345mS CMLineRx: v=1
CMAlerting
Line: type=Q931Line 1 Call: lid=0 id=3582 in=0
IE CMIEProgressIndicator (30) cs=CMCSITUT (0), loc=CMLPublicNetLocalUser (2), pd=CMPDInbandPattern (8)
09:15:49 96690345mS CMCallEvt: c0a8030800000dfe 0.3582.0 589 Q931 Trunk:1 CHAN=15: StateChange: END=B CMCSAccept->CMCSRinging
09:15:49 96690346mS CMCallEvt: c0a8030800000dfb 0.3579.0 589 GHOST:: StateChange: END=A CMCSDialled->CMCSRingBack
09:15:49 96690347mS CMCallPkt: v=0
CMConnect
Line: type=Q931Line 1 Call: lid=0 id=3582 in=0
BChan: slot=0 chan=15
09:15:49 96690347mS CMLineRx: v=1
CMConnect
Line: type=Q931Line 1 Call: lid=0 id=3582 in=0
BChan: slot=0 chan=15
09:15:49 96690348mS CMCallEvt: c0a8030800000dfe 0.3582.0 589 Q931 Trunk:1 CHAN=15: StateChange: END=B CMCSRinging->CMCSConnReq
09:15:49 96690348mS CMCallEvt: c0a8030800000dfb 0.3579.0 589 GHOST:: StateChange: END=A CMCSRingBack->CMCSOGConnReq
09:15:49 96690348mS T1DSP: PRIU DSP 1: channel 15 (timeslot 30), digit receiver DTMF fast *
09:15:49 96690349mS CMExtnRx: v=131, p1=0
CMConnect
Line: type=NoLine 0 Call: lid=0 id=-1 in=0
09:15:49 96690349mS CMCallEvt: c0a8030800000dff 0.3583.0 588 UserNameReplaced.0: StateChange: END=T CMCSRinging->CMCSConnReq
09:15:49 96690350mS CMCallEvt: 0000000000000000 0.3577.0 588 TargetingEP: RequestEnd c0a8030800000dff 0.3583.0 588 UserNameReplaced.0
09:15:49 96690350mS CMTARGET: c0a803080000000a 1.10.1 588 Q931 Trunk:1 CHAN=1: CancelTimer CMTCCoverageTimeout
09:15:49 96690350mS CMCallEvt: 0000000000000000 0.3577.0 -1 BaseEP: DELETE CMEndpoint f1829798 TOTAL NOW=15 CALL_LIST=7
09:15:49 96690351mS CMExtnEvt: UserNameReplaced: CALL LOST (CMCauseAnsweredByOther)

 

[IPGuru]

geat everyone get a tar apart from the person who posted the correct cause of the problem (Me) :-(


Do things on the cheap & it will cost you dear

 

[SamIPOfficeSupport]

IPGuru: Oops, let me know if you still don't have it...Also, I'll try and report back once I get AT&T's attention about this. It might be helpful if I can find out which setting on the adtran/ AT&T equipment gets adjusted to fix it.

 

[bluemr2]

They fixed it. This is what they sent me to fix the issue.

Uncheck - "Sent CONNECT after Early Media" on PRI on the routers configuration

 

[IPGuru]

Star for posting resolution (So many forget to do this & it helps the people who search for an answer before posting)


Do things on the cheap & it will cost you dear

 

[SamIPOfficeSupport]

Customer just mentioned that the twinning issue is resolved. I still have not been contacted by a single AT&T technical resource after calling in 3 times and submitting two express tickets that were auto-closed... It's just poor customer service. Anyways, sorry for the rant, but it seems like someone made a change to the AT&T configuration which has repaired the problem. I'll report what setting they changed once I confirm that.

 

[SamIPOfficeSupport]

Ok, now I can confirm that my resolution was the same as bluemr2's. The BVoip technician upgraded the router firmware to 14.8.9, and then disabled the "send early connect" setting.