SIP one way audio issue

Hi,
I am facing strange issue with my asterisk, this is my Dialplan

exten => _X.,1,Ringing()
;exten => _X.,n,Dial(SIP/${EXTEN:1}@192.168.82.11:5060);
exten => _X.,n,Dial(SIP/GW1/${EXTEN:1});
exten => _X.,n,Hangup

Sip Trunk Below

[GW1]
type=friend
host=192.168.82.11
call-limit=32
disallow=all
allow=g723
allow=g729
qualify=yes

So my issue is that if I send the call direct from asterisk to IP using this dialpaln

exten => _X.,n,Dial(SIP/${EXTEN:1}@192.168.82.11:5060)

Call is passing & get connected also & I can hear the other party but he/she cannot hear me at all.

But if I use this dialplan exten => _X.,n,Dial(SIP/GW1/${EXTEN:1});

Then everything is just fine both party can hear each other, I just don’t understand where I am wrong why is not work directly but with trunk is fine.

please if anyone understand my issue, help me about this.

Have you compared the general configuration in sip.conf to the GW1 to see if there are differences (such as codecs)?

Here is my SIP General Config

[general]
context=default
useragent=VPN4GW
allowoverlap=no
udpbindaddr=0.0.0.0:6030
bindaddr=0.0.0.0
bindport=6030
maxexpiry=3600
minexpiry=60
defaultexpiry=120
keepalive=120
transport=udp
insecure=invite,port
dtmfmode=rfc2833
disallow=all
allow=g723
allow=g729
srvlookup=no

SIP Debug Log… to check the issues

<--- SIP read from UDP:192.168.82.11:5060 --->
BYE sip:0012022447830@172.162.152.1:6030 SIP/2.0
Via: SIP/2.0/UDP 192.168.82.11;branch=z9hG4bKecf53a7d3a98335505300a87d019aae1;rport
From: <sip:01566336368@192.168.82.11:5060>;tag=a75080a38520a1e55351992a2ea0de36
To: "VMER Dialplan Test" <sip:0012022447830@172.162.152.1:6030>;tag=as7c85b406
Call-ID: 7a285093698f78156034af6b42e90cb6@172.162.152.1:6030
CSeq: 103 BYE
Supported: replaces
Max-Forwards: 70
Content-Length: 0

<------------->
--- (9 headers 0 lines) ---
Sending to 192.168.82.11:5060 (no NAT)
Scheduling destruction of SIP dialog '7a285093698f78156034af6b42e90cb6@172.162.152.1:6030' in 32000 ms (Method: BYE)

<--- Transmitting (no NAT) to 192.168.82.11:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.82.11;branch=z9hG4bKecf53a7d3a98335505300a87d019aae1;received=192.168.82.11;rport=5060
From: <sip:01566336368@192.168.82.11:5060>;tag=a75080a38520a1e55351992a2ea0de36
To: "VMER Dialplan Test" <sip:0012022447830@172.162.152.1:6030>;tag=as7c85b406
Call-ID: 7a285093698f78156034af6b42e90cb6@172.162.152.1:6030
CSeq: 103 BYE
Server: VPN4GW
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


<------------>
set_destination: Parsing <sip:0012022447830@244.51.91.58:6030> for address/port to send to
set_destination: set destination to 244.51.91.58:6030
Audio is at 6030
    -- peer joint caps (0x100 (g729))
Adding codec 0x100 (g729) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 244.51.91.58:6030:
INVITE sip:0012022447830@244.51.91.58:6030 SIP/2.0
Via: SIP/2.0/UDP 116.203.219.64:6030;branch=z9hG4bK4a6cbabe
Max-Forwards: 70
From: <sip:801566336368@116.203.219.64:6030>;tag=as4e3387b7
To: "VMER Dialplan Test" <sip:0012022447830@244.51.91.58:6030>;tag=as618ee6e0
Contact: <sip:801566336368@116.203.219.64:6030>
Call-ID: 18f16ffb0442bd67269d6e6948bdf7f3@244.51.91.58:6030
CSeq: 103 INVITE
User-Agent: VPN4GW
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
X-asterisk-Info: SIP re-invite (External RTP bridge)
Content-Type: application/sdp
Content-Length: 279

v=0
o=root 1551384722 1551384725 IN IP4 116.203.219.64
s=Asterisk PBX SVN-branch-1.8-r331578M
c=IN IP4 116.203.219.64
t=0 0
m=audio 18778 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

---

<--- SIP read from UDP:244.51.91.58:6030 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 116.203.219.64:6030;branch=z9hG4bK4a6cbabe;received=116.203.219.64
From: <sip:801566336368@116.203.219.64:6030>;tag=as4e3387b7
To: "VMER Dialplan Test" <sip:0012022447830@244.51.91.58:6030>;tag=as618ee6e0
Call-ID: 18f16ffb0442bd67269d6e6948bdf7f3@244.51.91.58:6030
CSeq: 103 INVITE
Server: VPN4GW
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:0012022447830@244.51.91.58:6030>
Content-Length: 0

<------------->
--- (11 headers 0 lines) ---

<--- SIP read from UDP:244.51.91.58:6030 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 116.203.219.64:6030;branch=z9hG4bK4a6cbabe;received=116.203.219.64
From: <sip:801566336368@116.203.219.64:6030>;tag=as4e3387b7
To: "VMER Dialplan Test" <sip:0012022447830@244.51.91.58:6030>;tag=as618ee6e0
Call-ID: 18f16ffb0442bd67269d6e6948bdf7f3@244.51.91.58:6030
CSeq: 103 INVITE
Server: VPN4GW
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:0012022447830@244.51.91.58:6030>
Content-Type: application/sdp
Content-Length: 273

v=0
o=root 784523396 784523398 IN IP4 244.51.91.58
s=Asterisk PBX SVN-branch-1.8-r331578M
c=IN IP4 244.51.91.58
t=0 0
m=audio 18836 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
<------------->
--- (12 headers 12 lines) ---
Found RTP audio format 18
Found RTP audio format 101
Found audio description format G729 for ID 18
Found audio description format telephone-event for ID 101
Capabilities: us - 0x501 (g723|g729|ilbc), peer - audio=0x100 (g729)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x100 (g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 244.51.91.58:18836
set_destination: Parsing <sip:0012022447830@244.51.91.58:6030> for address/port to send to
set_destination: set destination to 244.51.91.58:6030
Transmitting (no NAT) to 244.51.91.58:6030:
ACK sip:0012022447830@244.51.91.58:6030 SIP/2.0
Via: SIP/2.0/UDP 116.203.219.64:6030;branch=z9hG4bK76ab8db4
Max-Forwards: 70
From: <sip:801566336368@116.203.219.64:6030>;tag=as4e3387b7
To: "VMER Dialplan Test" <sip:0012022447830@244.51.91.58:6030>;tag=as618ee6e0
Contact: <sip:801566336368@116.203.219.64:6030>
Call-ID: 18f16ffb0442bd67269d6e6948bdf7f3@244.51.91.58:6030
CSeq: 103 ACK
User-Agent: VPN4GW
Content-Length: 0


---
  == Spawn extension (VPN4GW, 801566336368, 2) exited non-zero on 'SIP/Test_Carrier-00000000'
Scheduling destruction of SIP dialog '18f16ffb0442bd67269d6e6948bdf7f3@244.51.91.58:6030' in 6400 ms (Method: ACK)
set_destination: Parsing <sip:0012022447830@244.51.91.58:6030> for address/port to send to
set_destination: set destination to 244.51.91.58:6030
Reliably Transmitting (no NAT) to 244.51.91.58:6030:
BYE sip:0012022447830@244.51.91.58:6030 SIP/2.0
Via: SIP/2.0/UDP 116.203.219.64:6030;branch=z9hG4bK0fd82e88
Max-Forwards: 70
From: <sip:801566336368@116.203.219.64:6030>;tag=as4e3387b7
To: "VMER Dialplan Test" <sip:0012022447830@244.51.91.58:6030>;tag=as618ee6e0
Call-ID: 18f16ffb0442bd67269d6e6948bdf7f3@244.51.91.58:6030
CSeq: 104 BYE
User-Agent: VPN4GW
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


---

<--- SIP read from UDP:244.51.91.58:6030 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 116.203.219.64:6030;branch=z9hG4bK0fd82e88;received=116.203.219.64
From: <sip:801566336368@116.203.219.64:6030>;tag=as4e3387b7
To: "VMER Dialplan Test" <sip:0012022447830@244.51.91.58:6030>;tag=as618ee6e0
Call-ID: 18f16ffb0442bd67269d6e6948bdf7f3@244.51.91.58:6030
CSeq: 104 BYE
Server: VPN4GW
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

<------------->
--- (10 headers 0 lines) ---
Really destroying SIP dialog '18f16ffb0442bd67269d6e6948bdf7f3@244.51.91.58:6030' Method: ACK

please check & see where is the issues

This version hasn’t been supported for about half a decade! It/s also been built from a working version, rather than an official sub-version.

You need to compare the SDP, and also whether there is a re-INVITE to direct media, against the alternative configuration.

You don’t have sufficient verbosity to see the dialplan used, and it is not clear which case the log refers to.

Do you have a G.729 codec licence (not necessary in the case shown, but may be needed if the re-INVITE isn’t done).

Although not relevant to the problem, specifying insecure in general isn’t normally a good idea.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.