On Fri, Jul 22, 2011 at 8:07 PM, Matthew J. Roth mr...@imminc.com wrote:
Luckily, there is an option to force Asterisk to ignore the SDP
session version number and treat all SDP data as new data. Try adding
ignoresdpversion=yes to the phone's configuration in sip.conf.
COOL!!! OK, so
Michael,
It looks like your problem is caused by a phone with a non-standard
SDP session version implementation. The phone is sending an INVITE
with SDP that contains an a=sendonly line. Asterisk should respond
with an OK that contains an a=recvonly line, but it responds with
a=sendrecv
On Tue, Jul 19, 2011 at 10:12 PM, Matthew J. Roth mr...@imminc.com wrote:
Michael wrote:
True. In the working system, LAN calls are also using G.729, while
in the non-working system, LAN calls are in G.711 (supported but
not prioritized by the phones) and only the SIP trunk to the ITSP
On 19/07/11 08:20, Michael wrote:
On the AsteriskNow system, it gives an OK, but nothing happens, there's
no music and after some time, the call even drops for empty RTP. That's
the log there:
What does the Asterisk CLI show when this happens on your AsteriskNow
system?
--
Michael,
Here are the differences between the systems that I determined from the two SIP
traces:
* Working system: no NAT, phone codec: G.729, Asterisk codec: G.729
* Non-working system: NAT, phone codec: G.729, Asterisk codec: A-law
Does the conversation have two-way audio prior to the
On Tue, Jul 19, 2011 at 12:36 PM, Paul Hayes p...@provu.co.uk wrote:
What does the Asterisk CLI show when this happens on your AsteriskNow
system?
Absolutely nothing, unlike the working system, where the CLI clearly
indicates that MOH is activated
--
Michael wrote:
True. In the working system, LAN calls are also using G.729, while
in the non-working system, LAN calls are in G.711 (supported but
not prioritized by the phones) and only the SIP trunk to the ITSP
is set to G.729.
Can you set the phone to G.711 and try making a LAN call on
