Wow, I’m extremely puzzled. A little background: On cheap IP phones (or ATAs or softphones), the ‘conference’ function is implemented almost entirely in the phone. A three-way call is just two normal calls with the audio bridged in the phone itself. The only unusual thing that Asterisk sees is that the first call is held while the second call is being placed. Other than the re-invites to hold and unhold, Asterisk is unaware that a conference is taking place. This style of conference is usually limited to 3 or 4 parties and often adds unnecessary latency to the call. Better phones such as Polycom can be configured to bridge in the server, avoiding these disadvantages. Of course, the server needs to support the requests. I was under the impression that Asterisk did not, and the 603 status in response to the phone’s REFER requests seemed to confirm that.
This is not new: folks have been having this trouble for more than seven years; see Cisco 79xx/89xx specific local conference bridge issue . AFAICT no one has solved it.
So far, this seemed like a simple problem (though perhaps without a simple solution). Either figure out how to make the phone do the conference internally, or somehow get Asterisk to handle the REFER requests properly.
However, there is a nasty piece of evidence that refutes my simple theory – the conference sometimes works. Between the lack of timestamps and the lack of SIP traces in Conf-Hold-Softkey.txt, I can’t figure out how. Possibly, the phone decided to fall back to bridging internally. Or, a REFER request was properly executed (though it doesn’t appear that the three parties were ever in the same bridge). Or, the calls somehow got ‘crossed’ (in which case I’d expect some one-way audio or terrible quality).
If the working case has good quality (each party can hear the other two well), post a log with SIP debug and I’ll try to figure out how it differs from the failing case.