Asterisk sending BYE just after call is connected

Asterisk Asterisk Support
1

Asterisk sending BYE immediately after call is answered and connected. My extensions was working okay for the last six months, all on a sudden it is broken. Provider said it received CSeq: 103 BYE just after call is connected.I have no idea why that’s happening.
Thanks in advance for help.

Here are the console output:
– Executing [start@subMakecall:8] Dial(“SIP/PROVIDER_inbound-00000000”, “SIP/PROVIDER/00111010118801713098400”) in new stack
== Using SIP RTP CoS mark 5
– Called SIP/PROVIDER/00111010118801713098400
– SIP/PROVIDER-00000001 is ringing
[Dec 16 11:25:52] WARNING[11119]: chan_sip.c:8942 process_sdp: Unsupported SDP media type in offer: audio 0 RTP/AVP 0 8
[Dec 16 11:25:52] WARNING[11119]: chan_sip.c:9029 process_sdp: Failing due to no acceptable offer found
– SIP/PROVIDER-00000001 is ringing
– SIP/PROVIDER-00000001 is making progress passing it to SIP/PROVIDER_inbound-00000000
[Dec 16 11:26:14] WARNING[11119]: chan_sip.c:8942 process_sdp: Unsupported SDP media type in offer: audio 0 RTP/AVP 0 8

Here are Debug output:
[Dec 16 11:26:14] DEBUG[11119] chan_sip.c: SIP response 200 to standard invite
[Dec 16 11:26:14] DEBUG[11119] chan_sip.c: Processing session-level SDP v=0… UNSUPPORTED.
[Dec 16 11:26:14] DEBUG[11119] chan_sip.c: Processing session-level SDP o=HuaweiSoftX3000 45492955 45492956 IN IP4 10.0.0.2… UNSUPPORTED.
[Dec 16 11:26:14] DEBUG[11119] chan_sip.c: Processing session-level SDP s=Sip Call… UNSUPPORTED.
[Dec 16 11:26:14] DEBUG[11119] netsock2.c: Splitting ‘0.0.0.0’ into…
[Dec 16 11:26:14] DEBUG[11119] netsock2.c: …host ‘0.0.0.0’ and port ‘’.
[Dec 16 11:26:14] DEBUG[11119] chan_sip.c: Processing session-level SDP c=IN IP4 0.0.0.0… OK.
[Dec 16 11:26:14] DEBUG[11119] chan_sip.c: Processing session-level SDP t=0 0… UNSUPPORTED.
[Dec 16 11:26:14] WARNING[11119] chan_sip.c: Unsupported SDP media type in offer: audio 0 RTP/AVP 0 8
[Dec 16 11:26:14] WARNING[11119] chan_sip.c: Failing due to no acceptable offer found
[Dec 16 11:26:14] DEBUG[11119] chan_sip.c: Updating call counter for outgoing call
[Dec 16 11:26:14] DEBUG[11119] chan_sip.c: build_route: Retaining previous route: sip:callee@108.59.2.133;did=bc3.f014bde5
[Dec 16 11:26:14] DEBUG[11119] netsock2.c: Splitting ‘108.59.2.133’ into…
[Dec 16 11:26:14] DEBUG[11119] netsock2.c: …host ‘108.59.2.133’ and port ‘’.
[Dec 16 11:26:14] DEBUG[11119] chan_sip.c: Trying to put ‘ACK sip:cal’ onto UDP socket destined for 108.59.2.133:5060
[Dec 16 11:26:14] DEBUG[11119] channel.c: Soft-Hanging up channel ‘SIP/PROVIDER-00000001’
[Dec 16 11:26:14] DEBUG[11119] netsock2.c: Splitting ‘108.59.2.133’ into…
[Dec 16 11:26:14] DEBUG[11119] netsock2.c: …host ‘108.59.2.133’ and port ‘’.
[Dec 16 11:26:14] DEBUG[11119] chan_sip.c: Trying to put ‘ACK sip:cal’ onto UDP socket destined for 108.59.2.133:5060
[Dec 16 11:26:14] DEBUG[11119] channel.c: Soft-Hanging up channel ‘SIP/PROVIDER-00000001’
[Dec 16 11:26:14] DEBUG[11119] netsock2.c: Splitting ‘108.59.2.133’ into…
[Dec 16 11:26:14] DEBUG[11119] netsock2.c: …host ‘108.59.2.133’ and port ‘’.
[Dec 16 11:26:14] DEBUG[11119] chan_sip.c: Trying to put ‘BYE sip:cal’ onto UDP socket destined for 108.59.2.133:5060
[Dec 16 11:26:14] DEBUG[11111] devicestate.c: No provider found, checking channel drivers for SIP - PROVIDER
[Dec 16 11:26:14] DEBUG[11111] chan_sip.c: Checking device state for peer PROVIDER
[Dec 16 11:26:14] DEBUG[11111] devicestate.c: Changing state for SIP/PROVIDER - state 1 (Not in use)
[Dec 16 11:26:14] DEBUG[11111] devicestate.c: device ‘SIP/PROVIDER’ state ‘1’
[Dec 16 11:26:14] DEBUG[11143] app_queue.c: Device ‘SIP/PROVIDER’ changed to state ‘1’ (Not in use) but we don’t care because they’re not a member of any queue.
[Dec 16 11:26:14] DEBUG[11174] rtp_engine.c: Setting early bridge SDP of ‘SIP/PROVIDER_inbound-00000000’ with that of ‘SIP/PROVIDER-00000001’
[Dec 16 11:26:14] DEBUG[11174] channel.c: Set channel SIP/PROVIDER_inbound-00000000 to write format ulaw
[Dec 16 11:26:14] DEBUG[11174] channel.c: Scheduling timer at (0 requested / 0 actual) timer ticks per second
[Dec 16 11:26:14] DEBUG[11174] features.c: bridge answer set, chan answer set
[Dec 16 11:26:14] DEBUG[11174] features.c: Removing dialed interfaces datastore on SIP/PROVIDER-00000001 since we’re bridging
[Dec 16 11:26:14] DEBUG[11174] channel.c: Soft-Hanging up channel 'SIP/PROVIDER_inbound-00000000’u]

[Dec 16 11:26:14] WARNING[11119]: chan_sip.c:9029 process_sdp: Failing due to no acceptable offer found
– SIP/PROVIDER-00000001 answered SIP/PROVIDER_inbound-00000000

2

You need SIP debugging on.

However:

Dec 16 11:25:52] WARNING[11119]: chan_sip.c:8942 process_sdp: Unsupported SDP media type in offer: audio 0 RTP/AVP 0 8

almost certainly means that the peer system rejected your audio stream.

3

okay, I will turn on sip debugging.
Meanwhile, how to fix the problem of peer rejecting audio stream?

4

  1. Configure it to support audio.

  2. Offer it codecs that it is prepared to accept.

Normally you would get a Not Acceptable response, which suggests this peer is behaving oddly, or you also offered video, and it accepted that.

5

CLI>> sip show peer peer_name
…
Codecs : 0x80000008000e (gsm|ulaw|alaw|h263|testlaw)
Codec Order : (alaw:20,ulaw:20,gsm:20)
…
I have not explicitly allowed any codecs in sip.conf. But it seems, by default above are set. Are not these codecs sufficient? Is there anything else I need to add?
Also, calls within US networks holds okay without any problem. It is the international calls that have problems.

6

My provider supports G.729a and G.723 codecs
When I allowed both, I got an error
[Dec 16 23:11:02] WARNING[17481]: channel.c:5104 set_format: Unable to find a codec translation path from 0x100 (g729) to 0x4 (ulaw)

So, just allowed g723. sip show peer-
Codecs : 0x80000008000f (g723|gsm|ulaw|alaw|h263|testlaw)

Still getting same errors:
[Dec 16 23:52:59] WARNING[17624]: chan_sip.c:8942 process_sdp: Unsupported SDP media type in offer: audio 0 RTP/AVP 0 8
[Dec 16 23:52:59] WARNING[17624]: chan_sip.c:9029 process_sdp: Failing due to no acceptable offer found

Here are the traces with sip debug on
<— SIP read from UDP:108.59.2.133:5060 —>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 54.85.26.195:5060;branch=z9hG4bK427a2c2a;rport
Call-ID: 7e82fca933a509447f4302942f8c0f00@54.85.26.195:5060
From: "18455272179"sip:18455272179@54.85.26.195;tag=as6dced068
To: sip:00111010118801712021160@sbc.PROVIDER.com;tag=sbc0509v7ahglki-CC-23
CSeq: 102 INVITE
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
Contact: sip:callee@108.59.2.133;did=421.b8bd8d12
Content-Length: 238
Content-Type: application/sdp

v=0
o=HuaweiSoftX3000 59207585 59207585 IN IP4 10.0.0.2
s=Sip Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 0 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
a=silenceSupp:off - - - -
a=ecan:fb on -
a=X-fax
a=inactive
<------------->
— (10 headers 13 lines) —
[Dec 16 23:52:43] WARNING[17624]: chan_sip.c:8942 process_sdp: Unsupported SDP media type in offer: audio 0 RTP/AVP 0 8
[Dec 16 23:52:43] WARNING[17624]: chan_sip.c:9029 process_sdp: Failing due to no acceptable offer found
– SIP/PROVIDER-00000009 is ringing
– SIP/PROVIDER-00000009 is making progress passing it to SIP/PROVIDER_inbound-00000008

<— SIP read from UDP:108.59.2.133:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 54.85.26.195:5060;branch=z9hG4bK427a2c2a;rport
Call-ID: 7e82fca933a509447f4302942f8c0f00@54.85.26.195:5060
From: "18455272179"sip:18455272179@54.85.26.195;tag=as6dced068
To: sip:00111010118801712021160@sbc.PROVIDER.com;tag=sbc0509v7ahglki-CC-23
CSeq: 102 INVITE
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER
Contact: sip:callee@108.59.2.133;did=421.b8bd8d12
Content-Length: 238
Content-Type: application/sdp

v=0
o=HuaweiSoftX3000 59207585 59207586 IN IP4 10.0.0.2
s=Sip Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 0 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
a=silenceSupp:off - - - -
a=ecan:fb on -
a=X-fax
a=inactive
<------------->
— (10 headers 13 lines) —
[Dec 16 23:52:59] WARNING[17624]: chan_sip.c:8942 process_sdp: Unsupported SDP media type in offer: audio 0 RTP/AVP 0 8
[Dec 16 23:52:59] WARNING[17624]: chan_sip.c:9029 process_sdp: Failing due to no acceptable offer found
set_destination: Parsing sip:callee@108.59.2.133;did=421.b8bd8d12 for address/port to send to
set_destination: set destination to 108.59.2.133:5060
Transmitting (NAT) to 108.59.2.133:5060:
ACK sip:callee@108.59.2.133;did=421.b8bd8d12 SIP/2.0
Via: SIP/2.0/UDP 54.85.26.195:5060;branch=z9hG4bK668975bf;rport
Max-Forwards: 70
From: “18455272179” sip:18455272179@54.85.26.195;tag=as6dced068
To: sip:00111010118801712021160@sbc.PROVIDER.com;tag=sbc0509v7ahglki-CC-23
Contact: sip:18455272179@54.85.26.195:5060
Call-ID: 7e82fca933a509447f4302942f8c0f00@54.85.26.195:5060
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.8.9.0
Content-Length: 0

set_destination: Parsing sip:callee@108.59.2.133;did=421.b8bd8d12 for address/port to send to
set_destination: set destination to 108.59.2.133:5060
Reliably Transmitting (NAT) to 108.59.2.133:5060:
BYE sip:callee@108.59.2.133;did=421.b8bd8d12 SIP/2.0
Via: SIP/2.0/UDP 54.85.26.195:5060;branch=z9hG4bK694fd391;rport
Max-Forwards: 70
From: “18455272179” sip:18455272179@54.85.26.195;tag=as6dced068
To: sip:00111010118801712021160@sbc.PROVIDER.com;tag=sbc0509v7ahglki-CC-23
Call-ID: 7e82fca933a509447f4302942f8c0f00@54.85.26.195:5060
CSeq: 103 BYE
User-Agent: Asterisk PBX 1.8.9.0
X-Asterisk-HangupCause: Unknown
X-Asterisk-HangupCauseCode: 0
Content-Length: 0

Scheduling destruction of SIP dialog ‘7e82fca933a509447f4302942f8c0f00@54.85.26.195:5060’ in 32000 ms (Method: INVITE)

7

You didn’t include your offer, but, in any case, you will need to ask your ITSP.

8

Where to look for the offer?

9

In the first INVITE of the transaction. Ringing is a response to that, and not normally even the first response.