One way audio after transfert

[srigaud]

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

[ralph]

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
   

[srigaud]

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)

[petr.necas]

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?

[x-man]

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?

[x-man]

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.

[srigaud]

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

[srigaud]

Is it possible Mitel do RTP proxy ?

[x-man]

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...

[ralph]

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