It looks like your box is doing some digit manipulation and forwarding the call sip-to-sip out to 192.168.101.35 which is answering the call and sending the 200OK which you then relay back to the sender at 192.168.10.168. It isn't routing to the FXO.
Packet 1 is the incoming INVITE to 0246135928892.
Packet 3 strips the leading "024", hairpins the call out to 192.168.101.35, sending an INVITE to 6135928892.
Packet 5, three seconds later, is a 200OK from 192.168.101.35 when the call is answered by 192.168.101.35
Packet 7 relays the 200OK back to the sender.
Check your voice grouped trunk configuration if you don't intend to hairpin the call to 192.168.101.35 and fix that so that the call routes to the FXO as intended.
"deb voice switchboard" may provide some help in debugging the call routing.
I am new to Adtran so not sure whether my observation are correct or not.
I think Adtran is not making the call hairpin since I am able to make a call from the PBX to (PSTN :6135928892) the far end. And there is two way voice path. What I observed from the debug command "deb voice switchboard" is calls are routed to the proper trunk group. Looks like as soon as Adtran forwards the packet to FXO port, Adtran assumes the call is connected. I could not see even 180 Ringing there is only 200 OK. Please correct me if I am wrong.
Below is my configuration on Adtran.
voice trunk T01 type sip
sip-server primary 192.168.101.20
registrar primary 192.168.101.20
voice trunk T02 type analog supervision loop-start
description "FXO Trunk"
resource-selection linear ascending
connect fxo 0/0
match dnis "$" substitute "6135928892"
rtp delay-mode adaptive
voice grouped-trunk MIVB
accept $ cost 0
voice grouped-trunk FXO
accept 6135928892 cost 0
Please find below the output for deb voice switchboard
04:39:19.851 SB.CALL 610 Idle Called the call routine with 6135928892
04:39:19 SB.TGMgr For dialed number 6135928892, against template $, on TrunkGroup MIVB, the score is 500
04:39:19 SB.TGMgr For dialed number 6135928892, against template 6135928892, on TrunkGroup FXO, the score is 11000
04:39:19.852 SB.CCM isMappable:
04:39:19.852 SB.CCM : Call Struct 0x34d4010 : Call-ID = 610
04:39:19.852 SB.CCM : Org Acct = T01 Dst Acct = T02
04:39:19.852 SB.CCM : Org Port ID = SipTrunk 0/0.500 Dst Port ID = unknown 0/0
04:39:19.853 SB.CCM : SDP Transaction = CallID: 610
04:39:19.853 SB.CCM : SDP Offer = 0x0333c410, (192.168.101.68:3000)
04:39:19.853 SB.CCM isMappable: Call Connection Type is RTP_TO_TDM
04:39:19.854 SB.CCM isMappable: Reserving RTP Channel 0/1.1
04:39:19.854 SB.CCM translateOffer: offer codec list: PCMU
04:39:19.854 SB.CCM translateOffer: revised offer codec list: PCMU
04:39:19.855 SB.CCM translateOffer: codec list after answerer: PCMU
04:39:19.855 SB.CCM translateOffer: DTMF signaling: answerer has no restrictions configured, passing offer(inband) through
04:39:19.856 SB.CCM translateOffer: success
04:39:19.856 SB.CALL 610 Idle Call sent from T01 to T02 (6135928892)
04:39:19.856 SB.CALL 610 State change >> Idle->Delivering
04:39:19.857 SB.CALL 610 Delivering Called the deliverResponse routine from Delivering
04:39:19.857 SB.CALL 610 Delivering DeliverResponse(accept) sent from T02 to T01
04:39:19 SB.CallStructObserver 610 Created
04:39:19 SB.CallStructObserver 610 <-> 2677764336-105298886
04:39:22.856 SB.CALL 610 Delivering Called the connect routine
04:39:22.856 SB.CCM isResponseMappable:
04:39:22.856 SB.CCM : Call Struct 0x34d4010 : Call-ID = 610
04:39:22.857 SB.CCM : Org Acct = T01 Dst Acct = T02
04:39:22.857 SB.CCM : Org Port ID = SipTrunk 0/0.500 Dst Port ID = FxoTrunk 0/0
04:39:22.857 SB.CCM : SDP Transaction = CallID: 610
04:39:22.857 SB.CCM : SDP Offer = 0x0333c410, (192.168.101.68:3000)
04:39:22.858 SB.CCM : RTP Channel = 0/1.1
04:39:22.858 SB.CCM isResponseMappable: reversing call connection type to compensate for event originator direction
04:39:22.858 SB.CCM isResponseMappable: Call Connection Type is TDM_TO_RTP
04:39:22.858 SB.CCM isResponseMappable: Creating SDP Answer based on SDP Offer
04:39:22.858 SB.CCM createAnswer: creating SDP answer using RTP channel 0/1.1
04:39:22.859 SB.CCM createAnswer : offer codec list: PCMU
04:39:22.859 SB.CCM : answer codec list: PCMU
04:39:22.860 SB.CCM createAnswer : result codec list: PCMU
04:39:22.860 SB.CCM createAnswer : final DTMF signaling(inband)
04:39:22.861 SB.CCM updateMediaEntryForReinviteWithSameSdp : no associated port found for port (20016)
04:39:22.861 SB.CCM translateAnswer: offer codec list: PCMU
04:39:22.861 SB.CCM : answer codec list: PCMU
04:39:22.862 SB.CCM translateAnswer: CODEC transcoding is not required
04:39:22.862 SB.CCM translateAnswer: offer / answer DTMF signaling identical: DTMF transcoding not required
04:39:22.862 SB.CCM translateAnswer: success
04:39:22.863 SB.CALL 610 Delivering Connect sent from T02 to T01
04:39:22.863 SB.CALL 610 State change >> Delivering->Connecting
04:39:22.904 SB.CALL 610 Connecting Called the connectResponse routine
04:39:22.905 SB.CCM connect:
04:39:22.905 SB.CCM : Call Struct 0x34d4010 : Call-ID = 610
04:39:22.905 SB.CCM : Org Acct = T01 Dst Acct = T02
04:39:22.905 SB.CCM : Org Port ID = SipTrunk 0/0.500 Dst Port ID = FxoTrunk 0/0
04:39:22.905 SB.CCM : SDP Transaction = CallID: 610
04:39:22.906 SB.CCM : SDP Offer = 0x0333c410, (192.168.101.68:3000)
04:39:22.906 SB.CCM : SDP Answer = 0x033bcc10, (127.0.0.3:20018)
04:39:22.906 SB.CCM : RTP Channel = 0/1.1
04:39:22.906 SB.CCM connect: Call Connection Type is RTP_TO_TDM
04:39:22.906 SB.CCM call rtpChannel->allocateForInterface
04:39:22.907 SB.CCM SDP offer is 192.168.101.68:3000, SDP answer is 127.0.0.3:20018
04:39:22.908 SB.CCM connect: Connected RTP/TDM via MCM
04:39:22.908 SB.CCM setupRtpChannel, source 2, silence 0
04:39:22.908 SB.CCM setupRtpChannel: setup using media connection
04:39:22.909 SB.CCM Looking up source address for destination 192.168.101.68
04:39:22.909 SB.CCM setupRtpChannel: Source IP addr = 192.168.101.35, port = 20018
04:39:22.909 SB.CCM setupRtpChannel: Target IP addr = 192.168.101.68, port = 3000
04:39:22.909 SB.CCM setupRtpChannel: Undo of previous operation not required
04:39:22.910 SB.CCM getFinalCodec: PCMU
04:39:22.910 SB.CCM getFinalCodec: PCMU
04:39:22.910 SB.CCM setupRtpChannel: Configuring RTP Channel 0/1.1 to Src 192.168.101.35:20018 Trg 192.168.101.68:3000 via PCMU Rx PCMU
04:39:22.911 SB.CCM setupRtpChannel: fpp=2 echo=on dtmf=0/0 dscp=46 vad=off isOffer no
04:39:22.911 SB.CCM setupRtpChannel: Starting RTP Channel
04:39:22.911 SB.CCM firewallConnectCall: Set up firewall from media connections
04:39:22.911 SB.CCM sdpFirewall: invoked with offer - 192.168.101.68:3000, answer - 192.168.101.35:20018
04:39:22.912 SB.CCM sdpFirewallV4: Testing firewall policies
04:39:22.912 SB.CCM sdpFirewallV4: Creating firewall associations to connect 192.168.101.68:3000 to 192.168.101.35:20018
04:39:22.912 SB.CCM sdpFirewallV4: Call matches VQM user, access list, or sampling criteria.
04:39:22.912 SB.CCM sdpFirewallV4: Creating association (does not need NAT) for traffic destined to 192.168.101.68:3000 for RTP
04:39:22.913 SB.CCM sdpFirewallV4: Delete criteria: Src: 0.0.0.0:0 Dst: 192.168.101.68:3000 Vrf: 0 Proto: 17 Dir: SELF
04:39:22.913 SB.CCM sdpFirewallV4: Creating association (does not need NAT) for traffic destined to 192.168.101.68:3001 for RTCP
04:39:22.913 SB.CCM sdpFirewallV4: Delete criteria: Src: 0.0.0.0:0 Dst: 192.168.101.68:3001 Vrf: 0 Proto: 17 Dir: SELF
04:39:22.914 SB.CCM sdpFirewallV4: Creating association (does not need NAT) for traffic destined to 192.168.101.35:20018 for RTP
04:39:22.914 SB.CCM sdpFirewallV4: Delete criteria: Src: 0.0.0.0:0 Dst: 192.168.101.35:20018 Vrf: 0 Proto: 17 Dir: inside
04:39:22.914 SB.CCM sdpFirewallV4: Creating association (does not need NAT) for traffic destined to 192.168.101.35:20019 for RTCP
04:39:22.914 SB.CCM sdpFirewallV4: Delete criteria: Src: 0.0.0.0:0 Dst: 192.168.101.35:20019 Vrf: 0 Proto: 17 Dir: inside
04:39:22.915 SB.CCM connect: TDM streams: port(SipTrunk 0/1.1) to port(FxoTrunk 0/0)
04:39:22.915 SB.CALL 610 Connecting ConnectResponse sent from T01 to T02
04:39:22.917 SB.CALL 610 Connecting Called the finalizeConnect routine
04:39:22.917 SB.CCM finalizeConnect: connection already finalized(2)
04:39:22.917 SB.CALL 610 State change >> Connecting->Connected
04:39:24.968 SB.CALL 610 Connected Called the clearCall routine
04:39:24.968 SB.CALL 610 Connected ClearCall sent from T01 to T02
04:39:24.969 SB.CALL 610 State change >> Connected->Clearing
04:39:24.969 SB.CALL 610 Clearing Called the clearResponse routine
04:39:24.969 SB.CALL 610 State change >> Clearing->CallIdlePending
04:39:24.969 SB.CCM disconnect:
04:39:24.970 SB.CCM : Call Struct 0x34d4010 : Call-ID = 610
04:39:24.970 SB.CCM : Org Acct = T01 Dst Acct = T02
04:39:24.970 SB.CCM : Org Port ID = SipTrunk 0/1.1 Dst Port ID = FxoTrunk 0/0
04:39:24.970 SB.CCM : RTP Channel = 0/1.1
04:39:24.970 SB.CCM disconnect: Call Connection Type is RTP_TO_TDM
04:39:24.971 SB.CCM disconnect: Stopping RTP Channel 0/1.1
04:39:24.971 SB.CCM disconnect: Disconnecting TDM streams
04:39:24.971 SB.CCM release:
04:39:24.971 SB.CCM : Call Struct 0x34d4010 : Call-ID = 610
04:39:24.972 SB.CCM : Org Acct = T01 Dst Acct = T02
04:39:24.972 SB.CCM : Org Port ID = SipTrunk 0/1.1 Dst Port ID = FxoTrunk 0/0
04:39:24.972 SB.CCM : RTP Channel = 0/1.1
04:39:24.972 SB.CCM release: Call Connection Type is RTP_TO_TDM
04:39:24.972 SB.CCM release: Releasing RTP Channel 0/1.1
04:39:24.973 SB.CALL 610 CallIdlePending ClearResponse sent from T02 to T01
04:39:24 SB.CallStructObserver 610 Finalized
OK the PCAP from earlier was a bit tricky. It looks like there are two outside IP addresses. Voice debug is clearer.
This looks like ring-trip on the called number and not a problem with the TA908e. Is the destination number a PSTN POTS line? Can you call that number from elsewhere? Notice:
04:39:22.917 SB.CALL 610 State change >> Connecting->Connected <- Fully set up
04:39:24.968 SB.CALL 610 Connected Called the clearCall routine <- just over two seconds later the call is torn down.
An FXO interface looks like a telephone. If you connect a plain old telephone to the line instead of the 908e and dial 6135928892 does the call answer and immediately disconnect?
How about calling it from a cell phone?
Ring-trip is an analog phenomenon sometimes seen on POTS lines. There's normally -48 volts DC on the line. When the phone rings, an AC signal of 70 to 90 volts is superimposed on it. If the extra voltage causes something to break down, enough current will flow that the call will supervise as answered. Then when the ring voltage is removed the circuit will go back idle. It can also be caused by too many ringers connected.
What happens if you change the destination number to a mobile number?
1. Is the destination number a PSTN POTS line?
Ans: Yes the destination number is a PSTN pots line.
2. I am not sure whether I understood your second question correct or not. ( If you connect a plain old telephone to the line instead of the 908e and dial 6135928892 does the call answer and immediately disconnect? )
Ans : Yes, Instead of 908e if I connect a analog phone and call to the pstn the calls are getting connected and I can disconnect the call. Earlier also ( when connected to 908e ) I was able to make call and disconnect call. The only problem is with SIP signalling. I make a call and when I hear the ring back from the far end and if I disconnect the call I cannot see any cancel sent by our PBX. Because the PBX assumes the call had already got established since PBX received 200 OK from Adtran
3. What happens if you change the destination number to a mobile number?
Ans : Even when dialed to cell phone the behaviour is same.
OK, got it. The problem that you're running into is that you don't have supervision on your POTS line. By this I mean that there is no electrical signal to indicate that the far end has answered. Some old-school POTS lines reversed the polarity on answer, but unless you have a special trunk like ground-start there typically isn't an electrical answer signal passed over the loop any more.
So, when you place a call out on the FXO, the Adtran sends an OK after a timeout of a few seconds. The OK is needed to tell the SIP side of things that it's time to cut through audio, etc. Because there is no actual electrical signal coming from the POTS line, the TA908 can't tell if the line was answered, got an intercept recording, or is still ringing.
The PBX, once the OK has been sent, should then send a BYE rather than a cancel. This will tear down the call.
You can tweak settings for disconnect-supervision where the FXO can tear down the call on a disconnect or several seconds of busy signal, but if you're initiating the call from the SIP side, a BYE from the PBX should knock it down.
Thanks a lot for your reply and really appreciate for going though the issue.
Yes, PBX is responding with BYE rather than cancel. Looks like that seems the expected behaviour.
And when the PSTN disconnects the call after several seconds the calls are getting disconnected.