Passthrough

moferreira · November 16, 2013, 12:49pm

Hi,

I have been trying to setup the following scenario: Internet VoIP ISP <-> Asterisk <-> My private LAN.

My Asterisk box is a dual NIC system but is not LAN the gateway. My provider uses G729 and my internal phones can also use it. I have tried everything I can to get G729 pass-through working but with no success. I don’t need any other Asterisk feature but having it working as a UAC for my internal phones.

Can someone give me a hint how to accomplish G729 pass-through in this scenario?

Many thanks,

Mo

I am running Asterisk 11 and the only 4 configuration files I have are:

asterisk.conf
directories
astetcdir => /etc/asterisk
astmoddir => /usr/lib/asterisk/modules
astvarlibdir => /var/lib/asterisk
astdbdir => /var/lib/asterisk
astkeydir => /var/lib/asterisk
astdatadir => /var/lib/asterisk
astagidir => /var/lib/asterisk/agi-bin
astspooldir => /var/spool/asterisk
astrundir => /var/run/asterisk
astlogdir => /var/log/asterisk
astsbindir => /usr/sbin

[options]
runuser = asterisk
rungroup = asterisk
documentation_language = en_US ; Set the language you want documentation

[compat]
pbx_realtime=1.6
res_agi=1.6
app_set=1.6

modules.conf
[modules]
autoload=no
load=res_rtp_asterisk.so
load=chan_sip.so
load=app_dial.so
load=pbx_config.so

sip.conf
[general]
localnet=192.168.1.0/24
disallow=all
allow=g729
allow=ulaw

register => 12345678:XYZ@sip.provider.com/12345678

[provider]
type=peer
context=incoming
host=sip.provider.com
defaultuser=12345678
fromuser=12345678
secret=XYZ
canreinvite=no
disallow=all
allow=g729
allow=ulaw

[phone-1]
type=peer
context=outgoing
host=192.168.1.100
canreinvite=no
disallow=all
allow=g729
allow=ulaw

extensions.conf
[incoming]
exten => 12345678,1,Dial(SIP/phone-1,60)
exten => 12345678,n,Hangup()

[outgoing]
exten => _X.,1,Dial(SIP/${EXTEN}@provider)
exten => _X.,n,Hangup()

david55 · November 16, 2013, 1:25pm

You don’t seem to have any means for the machine to determine its public address.

If you want to guarantee G.729 pass through, you should not allow any other codecs.

I would expect incoming calls from the provider to fail to authenticate. You need remotesecret, instead of secret on the latest versions (I think that includes 11; for earlier versions, you will need insecure=invite).

You didn’t provide any logging.

moferreira · November 16, 2013, 3:47pm

Thanks for your feedback David. I will take the chance and challenge you a little bit more

If I understood correctly, I have to remove the “allow” codec statements in sip.conf and let only the “disallow=all” one. I will give it try and post here the results.

Regarding to the means for the machine to determine its public address, I can state the local network using the “localnet=192.168.1.0/24” under [general]. Would this be enough or I have really to state the public IP address? Also, is it possible to state the internal/external interfaces instead of using their IP address/network? Why? Because the public IP will be quite difficult to state as during my tests it is got by DHCP.

Finally, as it failed for the outgoing call I never tested an incoming call . But great! You saved me a lot of research to find why it would not work. Thanks again. And yes, I will test it.

If it still failing after your suggestions I will attach the logs I get. But the reality is that I thought I was doing some really stupid thing usually a beginner like me does…

Mo

moferreira · November 16, 2013, 5:57pm

Did the test. It failed. The logs and configs are:

###########################################################
sip.conf
###########################################################
[general]
localnet=192.168.1.0/24
disallow=all ; only used at firt test. Then removed line

register => 9765432:XYZ@sip.inphonex.com/9765432

[provider]
type=peer
context=incoming
host=sip.inphonex.com
defaultuser=9765432
fromuser=9765432
secret=XYZ
canreinvite=no
disallow=all ; only used at firt test. Then removed line

[client]
type=peer
context=outgoing
host=192.168.1.119
canreinvite=no
disallow=all ; only used at firt test. Then removed line

###########################################################
A call log with Asterisk with sip.conf with “disallow=all”
###########################################################
*CLI> == Using SIP RTP CoS mark 5
No compatible codecs, not accepting this offer!

###########################################################
A call log with Asterisk sip.conf with no "disallow=all"
and neither “allow” statements
###########################################################
*CLI> == Using SIP RTP CoS mark 5
Agent policy for SIP/client-00000002 is ‘never’. CC not possible
– Executing [011351211972855@outgoing:1] Dial(“SIP/client-00000002”, “SIP/011351211972855@provider”) in new stack
== Using SIP RTP CoS mark 5
– Called SIP/011351211972855@provider
> 0x7f6be8007e70 – Probation passed - setting RTP source address to 93.186.130.50:13116
– SIP/provider-00000003 is ringing
– SIP/provider-00000003 is making progress passing it to SIP/client-00000002
> 0x7f6be8007e70 – Probation passed - setting RTP source address to 93.186.130.50:13116
Unable to find a codec translation path from (gsm) to (ulaw)
> 0x7f6bf000aee0 – Probation passed - setting RTP source address to 192.168.1.119:7078
Unable to find a codec translation path from (gsm) to (ulaw)
Codec mismatch on channel SIP/provider-00000003 setting write format to gsm from ulaw native formats (ulaw)
Unable to find a codec translation path from (ulaw) to (gsm)
Asked to transmit frame type gsm, while native formats is (ulaw) read/write = ulaw/ulaw
Codec mismatch on channel SIP/provider-00000003 setting write format to gsm from ulaw native formats (ulaw)
Unable to find a codec translation path from (ulaw) to (gsm)
Asked to transmit frame type gsm, while native formats is (ulaw) read/write = ulaw/ulaw
Asked to transmit frame type ulaw, while native formats is (gsm) read/write = ulaw/ulaw
Asked to transmit frame type ulaw, while native formats is (gsm) read/write = ulaw/ulaw
Codec mismatch on channel SIP/provider-00000003 setting write format to gsm from ulaw native formats (ulaw)

###########################################################
SIP log of a call
###########################################################
U 2013/11/16 17:39:39.625458 192.168.1.119:5060 -> 192.168.1.160:5060
INVITE sip:011055123456789@192.168.1.119 SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.119:5060;rport;branch=z9hG4bK7323.
From: sip:1001@192.168.1.119;tag=26287.
To: sip:011055123456789@192.168.1.119.
Call-ID: 3032.
CSeq: 20 INVITE.
Contact: sip:1001@192.168.1.119.
Content-Type: application/sdp.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO.
Max-Forwards: 70.
User-Agent: Linphone/3.6.1 (eXosip2/3.6.0).
Subject: Phone call.
Content-Length: 255.
.
v=0.
o=1001 2462 404 IN IP4 192.168.1.119.
s=Talk.
c=IN IP4 192.168.1.119.
t=0 0.
m=audio 7078 RTP/AVP 0 8 9 3 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:9 G722/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11.

U 2013/11/16 17:39:39.643092 192.168.1.160:5060 -> 192.168.1.119:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 192.168.1.119:5060;branch=z9hG4bK7323;received=192.168.1.119;rport=5060.
From: sip:1001@192.168.1.119;tag=26287.
To: sip:011055123456789@192.168.1.119.
Call-ID: 3032.
CSeq: 20 INVITE.
Server: Asterisk PBX SVN-branch-11-r402709.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Contact: sip:011055123456789@192.168.1.160:5060.
Content-Length: 0.
.

U 2013/11/16 17:39:39.644543 95.136.84.177:5060 -> 208.239.76.169:5060
INVITE sip:011055123456789@sip.inphonex.com SIP/2.0.
Via: SIP/2.0/UDP 95.136.84.177:5060;branch=z9hG4bK05027122.
Max-Forwards: 70.
From: sip:9765432@95.136.84.177;tag=as0f86965b.
To: sip:011055123456789@sip.inphonex.com.
Contact: sip:9765432@95.136.84.177:5060.
Call-ID: 267e180963e03597310bcee630afc13b@95.136.84.177:5060.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX SVN-branch-11-r402709.
Date: Sat, 16 Nov 2013 17:39:39 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 324.
.
v=0.
o=root 840637508 840637508 IN IP4 95.136.84.177.
s=Asterisk PBX SVN-branch-11-r402709.
c=IN IP4 95.136.84.177.
t=0 0.
m=audio 15970 RTP/AVP 0 3 8 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

U 2013/11/16 17:39:39.799448 208.239.76.169:5060 -> 95.136.84.177:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 95.136.84.177:5060;branch=z9hG4bK05027122.
From: sip:9765432@95.136.84.177;tag=as0f86965b.
To: sip:011055123456789@sip.inphonex.com.
Call-ID: 267e180963e03597310bcee630afc13b@95.136.84.177:5060.
CSeq: 102 INVITE.
Content-Length: 0.
.

U 2013/11/16 17:39:39.816624 208.239.76.169:5060 -> 95.136.84.177:5060
SIP/2.0 407 Proxy Authentication required.
Via: SIP/2.0/UDP 95.136.84.177:5060;branch=z9hG4bK05027122.
From: sip:9765432@95.136.84.177;tag=as0f86965b.
To: sip:011055123456789@sip.inphonex.com;tag=SD2fr4f99-65007518_8cce6d4f_ba42d4e5-fb47-449f-b4a6-7b6a97ac38fe.
Call-ID: 267e180963e03597310bcee630afc13b@95.136.84.177:5060.
CSeq: 102 INVITE.
Contact: sip:208.239.76.169:5060;transport=udp.
Proxy-Authenticate: Digest realm=“95.136.84.177”,nonce=“0043ef2a3de570c2e55a6ba8d3effdf8”,opaque=“652dcd2fad06ba2116a65d73b47ab9fd”.
Content-Length: 0.
.

U 2013/11/16 17:39:39.816895 95.136.84.177:5060 -> 208.239.76.169:5060
ACK sip:011055123456789@sip.inphonex.com SIP/2.0.
Via: SIP/2.0/UDP 95.136.84.177:5060;branch=z9hG4bK05027122.
Max-Forwards: 70.
From: sip:9765432@95.136.84.177;tag=as0f86965b.
To: sip:011055123456789@sip.inphonex.com;tag=SD2fr4f99-65007518_8cce6d4f_ba42d4e5-fb47-449f-b4a6-7b6a97ac38fe.
Contact: sip:9765432@95.136.84.177:5060.
Call-ID: 267e180963e03597310bcee630afc13b@95.136.84.177:5060.
CSeq: 102 ACK.
User-Agent: Asterisk PBX SVN-branch-11-r402709.
Content-Length: 0.
.

U 2013/11/16 17:39:39.817259 95.136.84.177:5060 -> 208.239.76.169:5060
INVITE sip:011055123456789@sip.inphonex.com SIP/2.0.
Via: SIP/2.0/UDP 95.136.84.177:5060;branch=z9hG4bK6a64880e.
Max-Forwards: 70.
From: sip:9765432@95.136.84.177;tag=as0f86965b.
To: sip:011055123456789@sip.inphonex.com.
Contact: sip:9765432@95.136.84.177:5060.
Call-ID: 267e180963e03597310bcee630afc13b@95.136.84.177:5060.
CSeq: 103 INVITE.
User-Agent: Asterisk PBX SVN-branch-11-r402709.
Proxy-Authorization: Digest username=“9765432”, realm=“95.136.84.177”, algorithm=MD5, uri="sip:011055123456789@sip.inphonex.com", nonce=“0043ef2a3de570c2e55a6ba8d3effdf8”, response=“5dcee625fa291a3299706baf62fd48ea”, opaque=“652dcd2fad06ba2116a65d73b47ab9fd”.
Date: Sat, 16 Nov 2013 17:39:39 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Type: application/sdp.
Content-Length: 324.
.
v=0.
o=root 840637508 840637509 IN IP4 95.136.84.177.
s=Asterisk PBX SVN-branch-11-r402709.
c=IN IP4 95.136.84.177.
t=0 0.
m=audio 15970 RTP/AVP 0 3 8 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

U 2013/11/16 17:39:39.973010 208.239.76.169:5060 -> 95.136.84.177:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 95.136.84.177:5060;branch=z9hG4bK6a64880e.
From: sip:9765432@95.136.84.177;tag=as0f86965b.
To: sip:011055123456789@sip.inphonex.com.
Call-ID: 267e180963e03597310bcee630afc13b@95.136.84.177:5060.
CSeq: 103 INVITE.
Content-Length: 0.
.

U 2013/11/16 17:39:43.127392 208.239.76.169:5060 -> 95.136.84.177:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 95.136.84.177:5060;branch=z9hG4bK6a64880e.
From: sip:9765432@95.136.84.177;tag=as0f86965b.
To: sip:011055123456789@sip.inphonex.com;tag=SD2fr4f99-74378198_8cce6d4f_b2b10335-6bc5-46fe-8c47-a7b299167377.
Call-ID: 267e180963e03597310bcee630afc13b@95.136.84.177:5060.
CSeq: 103 INVITE.
Contact: sip:208.239.76.169:5060;transport=udp.
P-Early-Media: sendrecv.
X-UUID: 5bd320bafa524e69a6387e3d687ff004.
Accept: application/sdp.
Allow: INVITE.
Content-Type: application/sdp.
Content-Length: 207.
.
v=0.
o=- 30625 0 IN IP4 93.186.130.50.
s=IMSS.
c=IN IP4 93.186.130.50.
t=0 0.
m=audio 13116 RTP/AVP 0 101.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=sendrecv.
a=sqn:0.
a=cdsc: 1 image udptl t38.

U 2013/11/16 17:39:43.128317 192.168.1.160:5060 -> 192.168.1.119:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 192.168.1.119:5060;branch=z9hG4bK7323;received=192.168.1.119;rport=5060.
From: sip:1001@192.168.1.119;tag=26287.
To: sip:011055123456789@192.168.1.119;tag=as24b3eff7.
Call-ID: 3032.
CSeq: 20 INVITE.
Server: Asterisk PBX SVN-branch-11-r402709.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Contact: sip:011055123456789@192.168.1.160:5060.
Content-Length: 0.
.

U 2013/11/16 17:39:43.128604 192.168.1.160:5060 -> 192.168.1.119:5060
SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP 192.168.1.119:5060;branch=z9hG4bK7323;received=192.168.1.119;rport=5060.
From: sip:1001@192.168.1.119;tag=26287.
To: sip:011055123456789@192.168.1.119;tag=as24b3eff7.
Call-ID: 3032.
CSeq: 20 INVITE.
Server: Asterisk PBX SVN-branch-11-r402709.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Contact: sip:011055123456789@192.168.1.160:5060.
Content-Type: application/sdp.
Content-Length: 324.
.
v=0.
o=root 985460714 985460714 IN IP4 192.168.1.160.
s=Asterisk PBX SVN-branch-11-r402709.
c=IN IP4 192.168.1.160.
t=0 0.
m=audio 15688 RTP/AVP 3 0 8 101.
a=rtpmap:3 GSM/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

U 2013/11/16 17:39:45.019159 192.168.1.119:5060 -> 192.168.1.160:5060
CANCEL sip:011055123456789@192.168.1.119 SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.119:5060;rport;branch=z9hG4bK7323.
From: sip:1001@192.168.1.119;tag=26287.
To: sip:011055123456789@192.168.1.119.
Call-ID: 3032.
CSeq: 20 CANCEL.
Max-Forwards: 70.
User-Agent: Linphone/3.6.1 (eXosip2/3.6.0).
Content-Length: 0.
.

U 2013/11/16 17:39:45.019424 192.168.1.160:5060 -> 192.168.1.119:5060
SIP/2.0 487 Request Terminated.
Via: SIP/2.0/UDP 192.168.1.119:5060;branch=z9hG4bK7323;received=192.168.1.119;rport=5060.
From: sip:1001@192.168.1.119;tag=26287.
To: sip:011055123456789@192.168.1.119;tag=as24b3eff7.
Call-ID: 3032.
CSeq: 20 INVITE.
Server: Asterisk PBX SVN-branch-11-r402709.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Length: 0.
.

U 2013/11/16 17:39:45.019581 192.168.1.160:5060 -> 192.168.1.119:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.1.119:5060;branch=z9hG4bK7323;received=192.168.1.119;rport=5060.
From: sip:1001@192.168.1.119;tag=26287.
To: sip:011055123456789@192.168.1.119;tag=as24b3eff7.
Call-ID: 3032.
CSeq: 20 CANCEL.
Server: Asterisk PBX SVN-branch-11-r402709.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH.
Supported: replaces, timer.
Content-Length: 0.
.

U 2013/11/16 17:39:45.020062 95.136.84.177:5060 -> 208.239.76.169:5060
CANCEL sip:011055123456789@sip.inphonex.com SIP/2.0.
Via: SIP/2.0/UDP 95.136.84.177:5060;branch=z9hG4bK6a64880e.
Max-Forwards: 70.
From: sip:9765432@95.136.84.177;tag=as0f86965b.
To: sip:011055123456789@sip.inphonex.com.
Call-ID: 267e180963e03597310bcee630afc13b@95.136.84.177:5060.
CSeq: 103 CANCEL.
User-Agent: Asterisk PBX SVN-branch-11-r402709.
Content-Length: 0.
.

U 2013/11/16 17:39:45.024589 192.168.1.119:5060 -> 192.168.1.160:5060
ACK sip:011055123456789@192.168.1.119 SIP/2.0.
Via: SIP/2.0/UDP 192.168.1.119:5060;rport;branch=z9hG4bK7323.
Route: sip:192.168.1.160;lr.
From: sip:1001@192.168.1.119;tag=26287.
To: sip:011055123456789@192.168.1.119;tag=as24b3eff7.
Call-ID: 3032.
CSeq: 20 ACK.
Content-Length: 0.
.

U 2013/11/16 17:39:45.173483 208.239.76.169:5060 -> 95.136.84.177:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 95.136.84.177:5060;branch=z9hG4bK6a64880e.
From: sip:9765432@95.136.84.177;tag=as0f86965b.
To: sip:011055123456789@sip.inphonex.com;tag=SD2fr4f99-74378198_8cce6d4f_b2b10335-6bc5-46fe-8c47-a7b299167377.
Call-ID: 267e180963e03597310bcee630afc13b@95.136.84.177:5060.
CSeq: 103 CANCEL.
Content-Length: 0.
.

U 2013/11/16 17:39:45.179262 208.239.76.169:5060 -> 95.136.84.177:5060
SIP/2.0 487 Request Terminated.
Via: SIP/2.0/UDP 95.136.84.177:5060;branch=z9hG4bK6a64880e.
From: sip:9765432@95.136.84.177;tag=as0f86965b.
To: sip:011055123456789@sip.inphonex.com;tag=SD2fr4f99-74378198_8cce6d4f_b2b10335-6bc5-46fe-8c47-a7b299167377.
Call-ID: 267e180963e03597310bcee630afc13b@95.136.84.177:5060.
CSeq: 103 INVITE.
Contact: sip:208.239.76.169:5060;transport=udp.
Content-Length: 0.
.

U 2013/11/16 17:39:45.179387 95.136.84.177:5060 -> 208.239.76.169:5060
ACK sip:208.239.76.169:5060;transport=udp SIP/2.0.
Via: SIP/2.0/UDP 95.136.84.177:5060;branch=z9hG4bK6a64880e.
Max-Forwards: 70.
From: sip:9765432@95.136.84.177;tag=as0f86965b.
To: sip:011055123456789@sip.inphonex.com;tag=SD2fr4f99-74378198_8cce6d4f_b2b10335-6bc5-46fe-8c47-a7b299167377.
Contact: sip:9765432@95.136.84.177:5060.
Call-ID: 267e180963e03597310bcee630afc13b@95.136.84.177:5060.
CSeq: 103 ACK.
User-Agent: Asterisk PBX SVN-branch-11-r402709.
Content-Length: 0.

david55 · November 16, 2013, 10:56pm

You still need to allow G.729. You were also allowing G.711 and you could have ended up with one side having G.729 and the other G.711.

If you are stuck with a dynamic external address, you sill need to use a STUN server. That’s not something I’ve done, but your ISP should provide one if they allow you to run servers.

ambiorixg12 · November 17, 2013, 2:04am

[provider]
disallow=all
allow=g729

[client]
disallow=all
allow=g729

moferreira · November 17, 2013, 11:02am

Hi,

Did you notice the Asterisk console logs? It says:

“Unable to find a codec translation path from (ulaw) to (gsm)
Asked to transmit frame type gsm, while native formats is (ulaw) read/write = ulaw/ulaw”

Although the provider offers ulaw and the SIP phone also allows for ulaw, Asterisk is trying to translate something that would not be necessary as both ends have a codec in common… I still don’t get it or may be I don’t understand Asterisk’s “working philosophy”.

Can anyone provide me an example of a working config to allow G729 pass-through in a scenario where Asterisk has two NICs, one to the Internet and another to the LAN? The key question is: is it possible at all?

Mo

david55 · November 17, 2013, 12:01pm

The originating phone will offer the codecs that it supports. Asterisk could offer the ones it is configured to support for that peer, but will actually offer the intersection of those and the offer it received and will give the incoming first choice as its outgoing first choice, if it is in common.

Note that some devices use late offer, so Asterisk will offer before it knows the capabilities of the caller.

That intersection then becomes the preferred choices for the outgoing leg (for late offer, no account can be taken of the caller), and will be placed at the front of Asterisk’s offer. The callee will then respond with its selection, which should have at least one codec in common with the outgoing offer.

The sending phone now has a list of acceptable codecs, based only on what it offered and what was configured in sip.conf, for its device entry. It can choose any of the codecs in Asterisk’s offer, although it will normally choose the first allowable one…

Asterisk will pass this through the bridge. If it matches one of the codecs acceptable to the other party, it will be passed through, otherwise it will be transcoded.

Note that, at no stage do the external parties get restricted to a single codec and there is no mechanism to pass the result of the called party negotiation back to the calling party, even though the called party SDP may be received before SDP is sent to the calling party.

Codecs can change during the call, without any further SDP exchange, if included in the initial exchange.

If you turn SIP debugging on, set core debug level to 5 and enable the debugging log category, you will see the codec decision logic choices, in the SDP exchange.

moferreira · November 17, 2013, 12:28pm

So, the best way to make sure it will always work with no translation is to define a single codec, like it was suggested by ambiorixg12, right? So, if I use:

[provider]
disallow=all
allow=g729

[client]
disallow=all
allow=g729

Then the RTP should be relayed with no translation as both legs can only use G729. Is this correct? (I will try it anyway…)

Mo

moferreira · November 17, 2013, 4:38pm

Hi,

If you configure “disallow=all” and only “allow=g729”, it works perfectly. Asterisk will pass-through G729 in between the two NICs/networks.

I thank you all for your support!

Mo

Topic		Replies	Views
No g729 Passthrough Asterisk Support	18	984	September 18, 2007
Help with setting Asterisk as Sip Client Asterisk Support	7	288	September 30, 2005
G729 Passthru Asterisk Support	1	254	July 27, 2008
Dual LAN VOIP Setup Asterisk Support	1	188	September 21, 2014
G729 Question Asterisk Support	4	236	September 28, 2007

Passthrough

Related topics