6 Replies Latest reply on Jun 9, 2017 12:50 PM by rajneesh.ramakrishnan

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

    rajneesh.ramakrishnan New Member

      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.

        • Re: Adtran 908e responding with 200 OK as soon as it receives initial Invite
          jayh Hall_of_Fame

          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.

            • Re: Adtran 908e responding with 200 OK as soon as it receives initial Invite
              rajneesh.ramakrishnan New Member

              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

                • Re: Adtran 908e responding with 200 OK as soon as it receives initial Invite
                  jayh Hall_of_Fame

                  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?

                    • Re: Adtran 908e responding with 200 OK as soon as it receives initial Invite
                      rajneesh.ramakrishnan New Member

                      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.

                        • Re: Adtran 908e responding with 200 OK as soon as it receives initial Invite
                          jayh Hall_of_Fame

                          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.

                  • Re: Adtran 908e responding with 200 OK as soon as it receives initial Invite
                    rajneesh.ramakrishnan New Member

                    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.