Adtran 908e responding with 200 OK as soon as it receives initial Invite

[rajneesh_ramakrishna]

Hi Guys,

I am dialing a PSTN phone from our IP-PBX  through FXO port of Adtran. Even though I am cancelling the call, PBX is not able to send CANCEL. Because according to the sip signalling call had already got established as soon as Adtran forwards the Invite to the far end.

Is there a mechanisim in Adtran wherein I could configure 200 OK / ACK should be sent only when the far end responds.

Thanks in Advance.

[jayh]

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.

[rajneesh_ramakrishna]

Hi Jayh,

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

  description "MIVB"

  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

  caller-id

  trunk-number 6132872055

  connect fxo 0/0

  match dnis "$" substitute "6135928892"

  rtp delay-mode adaptive

!

!

voice grouped-trunk MIVB

  trunk T01

  accept $ cost 0

!

!

voice grouped-trunk FXO

  trunk T02

  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

[jayh]

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?

[rajneesh_ramakrishna]

Hi Jayh,

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.

[jayh · Accepted solution]

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.

[rajneesh_ramakrishna]

Hi Jayh,

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.