the a in the codec its in the admin
section of the UI on the ATA.
/b
On Nov 3, 2009, at 11:47 AM, Mariano de Llano wrote:
Hi,
I'm having a problem with a Sipura, it is sending for the G729 the
tag G729a witch is not correct due the RFC.
Media Attribute (a): rtpmap:18 G729a/8000
FS is returning (200OK
Hi,
I'm having a problem with a Sipura, it is sending for the G729 the
tag G729a witch is not correct due the RFC.
Media Attribute (a): rtpmap:18 G729a/8000
FS is returning (200OK)
Media Attribute (a): rtpmap:96 G729/8000
I think that the problem is that FS is not matching the codec, so it
:
NO, proxy media and bypass media are wildly different behaviors and do
process things a little differently.
/b
On Sep 29, 2009, at 12:40 AM, Mariano de Llano wrote:
it seams very weird to me
that Sofia uses different approach to parse the mappings depending if
it is handling
Hi,
I'm having a strange behavior with the FS when I'm using it with
inboud-late-negotiation=true and with the both scenarios proxy-
media=true or bypass-media=true. The FS is acting as a pseudo
proxy (I know that it is not intend for that).
The configuration is similar to this:
is not valid for 0 which is a single channel of ulaw. I don't know
about you but I have yet to see a gateway able to do three channels of
PCMU :P
/b
On Sep 28, 2009, at 11:08 PM, Mariano de Llano wrote:
v=0
o=9499 1254144425 1254144425 IN IP4 [AddPac IP]
s=AddPac Gateway SDP
c=IN IP4 [AddPac IP]
t
You are right, it seams that it can not be done.
In the past I've tried to do something similiar but with no success.
Apperently the documentation is wrong.
If I have some time I will look at the code and I will give you some
feedback.
Cheers,
PS: The transcoding question has nothing to
