Author Topic: One way audio after transfert  (Read 5697 times)

Offline srigaud

  • New Member
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
One way audio after transfert
« on: December 12, 2013, 10:00:44 AM »
Hello,

I have an one way audio issue after transfert call. We use sip trunking for external call.

The outside caller hears correctly but inside caller hears nothing.

Any idea ?

Thanks for your help

S. Rigaud


Offline ralph

  • Mitel Forums Admin
  • Hero Member
  • *****
  • Posts: 5767
  • Country: us
  • Karma: +469/-0
  • Published Author: http://amzn.to/2dcYSY5
    • View Profile
Re: One way audio after transfert
« Reply #1 on: December 12, 2013, 10:05:53 AM »
Are the phones on the same subnet?
One thing you can look at is an option in the SIP trunk profile "Avoid signaling hold to peer"   Set it to yes.

Ralph
   

Offline srigaud

  • New Member
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: One way audio after transfert
« Reply #2 on: December 12, 2013, 10:24:51 AM »
All phones are in the same subnet.

Avoid Signaling Hold on the Peer is already Yes

If the inside caller puts call on hold and retake it we have voice in 2 way (only for no mitel phone)

Same cos between mitel phone and thomson ST2030 (where tricks works)

Offline petr.necas

  • Sr. Member
  • ****
  • Posts: 393
  • Country: cz
  • Karma: +8/-0
    • View Profile
Re: One way audio after transfert
« Reply #3 on: December 12, 2013, 01:08:29 PM »
Do following:
   - run maintenance command "SIP TCPDUMP ON"
   - do a test call
   - run command "SIP TCPDUMP OFF" to turn off the SIP signalling sniffing
   - FTP to the ICP using your ICP username and password and download /vmail/*.pcap file.
   - open the file in Wireshark and try to analyze it if you find something wrong in the SIP signalling.

I have similar issue on one of the sites, but not yet resolved.

What MCD version do you have?

Offline x-man

  • Hero Member
  • *****
  • Posts: 1129
  • Country: gb
  • Karma: +25/-0
    • View Profile
Re: One way audio after transfert
« Reply #4 on: December 12, 2013, 01:48:46 PM »
Now this is just a guess you understand but that sound like the RTP stream is being interrupted after the transfer so I wonder if you have something internally that is blocking ports?

Offline x-man

  • Hero Member
  • *****
  • Posts: 1129
  • Country: gb
  • Karma: +25/-0
    • View Profile
Re: One way audio after transfert
« Reply #5 on: December 12, 2013, 01:51:01 PM »
possibly something that is 'SIP aware' and that is causing headers to be misreported. I had something similar with a router where I had to turn off the sip aware stuff to allow the NAT to function.

Offline srigaud

  • New Member
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: One way audio after transfert
« Reply #6 on: December 13, 2013, 03:34:13 AM »
Thanks for your help.

I have a firewall (pfsense) nothing blocked or rejected in logs.

Before, we had Asterisk server and everything worked fine with same firewall.

I'll take trace and will share them with my provider



Offline srigaud

  • New Member
  • *
  • Posts: 4
  • Karma: +0/-0
    • View Profile
Re: One way audio after transfert
« Reply #7 on: December 13, 2013, 07:42:39 AM »
Is it possible Mitel do RTP proxy ?

Offline x-man

  • Hero Member
  • *****
  • Posts: 1129
  • Country: gb
  • Karma: +25/-0
    • View Profile
Re: One way audio after transfert
« Reply #8 on: December 13, 2013, 07:51:47 AM »
Yup, nothing blocked or logged on the router logs either, just that the sip stuff was altering the headers and causing the RTP to fail with one way transmission. Funnily enough it didn't affect analog extensions in the same way...

Offline ralph

  • Mitel Forums Admin
  • Hero Member
  • *****
  • Posts: 5767
  • Country: us
  • Karma: +469/-0
  • Published Author: http://amzn.to/2dcYSY5
    • View Profile
Re: One way audio after transfert
« Reply #9 on: December 13, 2013, 08:26:04 AM »
I'm with X-man on this.   Check your firewall and turn off any SIP ALG.
There won't be any logs showing blocked packets.  What the ALG is doing is changing the headers so that the far end now attempts to send the packets somewhere other than it should be.
If you did a Wireshark sniff on both the internal and external interfaces of the firewall you would probably see the changed packets.

Ralph


 

Sitemap 1 2 3 4 5 6 7 8 9 10