Displaying 4 results from an estimated 4 matches for "00021a0d".
Did you mean:
000214d0
2020 Sep 24
2
Negotiates g729 but RTP contains g711
...OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:0100000000 at 52.22.22.22:5160>
Content-Length: 0
<------------>
[2020-09-19 23:42:19] VERBOSE[15153][C-00021a1f] pbx.c: Executing [0100000000 at incoming:1] Set("SIP/Upstream-00021a0d", "1?SIP_CODEC=g729") in new stack
[2020-09-19 23:42:19] VERBOSE[15153][C-00021a1f] pbx.c: Executing [0100000000 at incoming:2] NoOp("SIP/Upstream-00021a0d", "SIP Call ID: 7030be5a09d89a9543234da051897a49 at 41.11.11.11") in new stack
[2020-09-19 23:42:19] VERBOSE...
2020 Sep 25
0
Negotiates g729 but RTP contains g711
...09-19 23:42:19] VERBOSE[2637][C-00021a1f] chan_sip.c: Capabilities: us - (g722|alaw|g729), peer - audio=(alaw|g729)/video=(nothing)/text=(nothing), combined - (alaw|g729)
<snip>
[2020-09-19 23:42:19] VERBOSE[15153][C-00021a1f] pbx.c: Executing [0100000000 at incoming:1] Set("SIP/Upstream-00021a0d", "1?SIP_CODEC=g729") in new stack
[2020-09-19 23:42:19] VERBOSE[15153][C-00021a1f] pbx.c: Executing [0100000000 at incoming:2] NoOp("SIP/Upstream-00021a0d", "SIP Call ID: 7030be5a09d89a9543234da051897a49 at 41.11.11.11<mailto:7030be5a09d89a9543234da051897a49 at 41....
2020 Sep 25
0
Negotiates g729 but RTP contains g711
...09-19 23:42:19] VERBOSE[2637][C-00021a1f] chan_sip.c: Capabilities: us - (g722|alaw|g729), peer - audio=(alaw|g729)/video=(nothing)/text=(nothing), combined - (alaw|g729)
<snip>
[2020-09-19 23:42:19] VERBOSE[15153][C-00021a1f] pbx.c: Executing [0100000000 at incoming:1] Set("SIP/Upstream-00021a0d", "1?SIP_CODEC=g729") in new stack
[2020-09-19 23:42:19] VERBOSE[15153][C-00021a1f] pbx.c: Executing [0100000000 at incoming:2] NoOp("SIP/Upstream-00021a0d", "SIP Call ID: 7030be5a09d89a9543234da051897a49 at 41.11.11.11<mailto:7030be5a09d89a9543234da051897a49 at 41....
2020 Sep 22
2
Negotiates g729 but RTP contains g711
Hi,
We have a scenario where inbound calls from an upstream provider (chan_sip) sent downstream (chan_iax2) negotiates only g729 yet RTP media contains g711. Both the upstream and downstream trunks are limited to only offering g729 whilst the initial invite from our upstream provider offers both g711 and g729. Asterisk presumably simply forwards the media from iax2 trunk encapsulation to sip