Hi

I am hoping that somebody might be able to help, I have just had this back from my VOIP provider and wondered if you maybe able to help with this.

I currently have a Quadro 16ml and Smon 320 phones...

..........Does anybody know why each leg is setting up with a different codec? is that because it is sending sendonly / recvonly ?

Thanks for that I've got the trace. So the 200 OK from the destination contains a recvonly media attribute, which is usually associated with a call being placed on hold and instructs the audio to stop being sent in one direction.
About half a second later we see a re-invite coming in from the destination address with a attibute of sendrecv, which is instructing the audio to go both directions instead.
We then see a rather strange SDP from you guys, with both sendonly and recvonly attributes rather than sendrecv:
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 794 191 IN IP4 87.127.209.222
Session Name (s): -
Connection Information (c): IN IP4 87.127.209.222
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 6108 RTP/AVP 8 0 18 101
Media Attribute (a): recvonly
Media Attribute (a): ptime:20
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-16
Media Description, name and address (m): audio 6108 RTP/AVP 0 101
Media Attribute (a): sendonly
Media Attribute (a): ptime:20
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
However, each leg of the call is setting up with a different flavour of G.711, one of the RTP streams sets up in G.711a and the other sets up in G.711u which I suspect is going to be the cause of your one-way audio issues.
So it looks like we've got a couple of issues in the same trace:
a) the destination appears to be trying to put the call on hold or muting it as soon as it's picked up.
b) When the destination tries to fix it with a re-invite the 200 OK response from you is trying to set up 2 audio legs with different codecs.
I may still have the ticket open with the upstream carrier so I'll fire this example up to them to try and find out why the destination is trying to hold the call as soon as it's picked up!
Interestingly, if I cal this number from the office I'm not able to re-create the issue.
As soon as I hear back I'll let you know.