The unwritten rule of SDP is that if possible you use the first codec of a
type listed, but you don’t have to. If the sender says he can do
something, he had better be prepared to handle media of that type no matter
in what order it was listed.
So when you send OK with ulaw as first priority and
Hi Marie
That's why I asked about thread safety for global vars, cause it was
appearing that global variables was going to be the only way to send data
between the two instances - e. g. between the running call and the
queue-triggered macro.
So the inherited (_ prepend) channel variables are
On Fri, May 11, 2018, at 10:36 AM, Steve Edwards wrote:
> On Fri, 11 May 2018, Joshua Colp wrote:
>
> >> In the above example, even though the INVITE/SDP says they prefer gsm
> >> over ulaw and the OK/SDP says I prefer ulaw over gsm, they can choose
> >> to use gsm or ulaw?
> >
> > Yes.
> >
>
On Fri, 11 May 2018, Joshua Colp wrote:
In the above example, even though the INVITE/SDP says they prefer gsm
over ulaw and the OK/SDP says I prefer ulaw over gsm, they can choose
to use gsm or ulaw?
Yes.
Can it be asymmetrical? They send gsm and I send ulaw?
Technically, yes. In
Hi Stefan,
glad you got it solved.
Just to clarify, those are not global, but channel variables you are using - so
they should be visible only to their respective channel (and child channels
with inheritance).
Global variables are defined in a [globals] section in extensions.conf.
On Fri, May 11, 2018, at 10:07 AM, Steve Edwards wrote:
>
> So, without examining the RTP, you cannot tell which codec was actually
> used?
>From an Asterisk perspective "core show channel" will also show you what is
>currently flowing.
> In the above example, even though the INVITE/SDP
On Thu, May 10, 2018 at 11:44:14AM -0700, Steve Edwards wrote:
I receive an INVITE/SDP containing:
m=audio 11310 RTP/AVP 3 0 101
which I interpret as gsm, ulaw, rfc2833.
and I reply with an OK/SDP containing:
m=audio 15884 RTP/AVP 0 3 101
which I interpret as ulaw, gsm,
Hi Marie
Thanks!
I was just worried about thread safety if I had to use a global variable, e.
g. it might be set to a value by one call (since I'm using the same global
for every incoming call to transfer the accountcode gotten from my HTTP
endpoint to the same macro, and there can be several
