Asterisk Sending Unsupported Media Immediately after INVITE

Hi, We are facing issues while handling inbound calls from a particular operator. Asterisk is straight away sending “415 Unsupported Media Type”. We have enabled the common codecs (alaw, ulaw, RFC4733 for DTMF). I am pasting the Asterisk Console logs below:

<--- Received SIP request (1594 bytes) from UDP:10.222.222.34:5060 --->
INVITE sip:09898989898@10.222.222.37:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.222.222.34:5060;branch=z9hG4bK0b93i60008af6lpe17f0.1
X-PILOT-B: +919898989898
From: <sip:+918989898989@10.222.222.34;user=phone>;tag=Cec9b278ZAa6W985
To: <sip:+919898989898@10.222.222.37;user=phone>
Call-ID: FAFF5D5DCCF2B049CD762717@0870ffffffff
CSeq: 1 INVITE
Max-Forwards: 68
Request-Disposition: no-fork
P-Asserted-Identity: <sip:08989898989@10.80.64.138:5060;user=phone>
P-Asserted-Identity: <tel:08989898989>
Session-Expires: 1800;refresher=uac
Contact: <sip:10.222.222.34:5060;yop=00.00.DFB8B1D5.0000.7008;transport=udp>
Supported: timer,100rel
Allow: INVITE,ACK,CANCEL,BYE,INFO,NOTIFY,PRACK,UPDATE,OPTIONS
P-Charging-Vector: icid-value=GXkxhigBmdGrEQTdCHDMBQEf;icid-generated-at=10.68.170.4;orig-ioi=10.68.170.4
P-Early-Media: supported
Content-Length: 629
Content-Type: multipart/mixed;boundary=1D1C8098E821159758471B35DFC362F83B99CD94
MIME-Version: 1.0

--1D1C8098E821159758471B35DFC362F83B99CD94
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=- 0 0 IN IP4 10.222.222.34
s=-
c=IN IP4 10.222.222.34
t=0 0
m=audio 39120 RTP/AVP 18 8 96
b=AS:80
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=ptime:20
a=maxptime:20

--1D1C8098E821159758471B35DFC362F83B99CD94
Content-Type:application/ISUP;base=itu-t92+;version=ITUT92+
Content-Disposition:signal;handling=required
Content-Transfer-Encoding:binary


[Aug 17 21:30:35] DEBUG[25255]: res_pjsip/pjsip_distributor.c:391 find_dialog: Could not find matching transaction for Request msg INVITE/cseq=1 (rdata0x7fdca00125f8)
[Aug 17 21:30:35] DEBUG[25255]: res_pjsip/pjsip_distributor.c:469 ast_sip_get_distributor_serializer: Calculated serializer pjsip/distributor-00000023 to use for Request msg INVITE/cseq=1 (rdata0x7fdca00125f8)
[Aug 17 21:30:35] DEBUG[25256]: netsock2.c:170 ast_sockaddr_split_hostport: Splitting '10.222.222.34' into...
[Aug 17 21:30:35] DEBUG[25256]: netsock2.c:224 ast_sockaddr_split_hostport: ...host '10.222.222.34' and port ''.
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_endpoint_identifier_ip.c:255 ip_identify_match_check: Source address 10.222.222.34:5060 matches identify 'INDVODA1'
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_endpoint_identifier_ip.c:288 common_identify: Identify 'INDVODA1' SIP message matched to endpoint INDVODA1
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4309 session_on_rx_request:  (null session) Request: INVITE sip:09898989898@10.222.222.37:5060;user=phone
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4135 handle_new_invite_request:  Request: sip:09898989898@10.222.222.37:5060;user=phone
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip/pjsip_distributor.c:469 ast_sip_get_distributor_serializer: Calculated serializer pjsip/distributor-00000023 to use for Request msg INVITE/cseq=1 (rdata0x7fdca0028818)
[Aug 17 21:30:35] DEBUG[25256]: chan_pjsip.c:2904 chan_pjsip_session_begin:  INDVODA1
[Aug 17 21:30:35] DEBUG[25256]: chan_pjsip.c:2908 chan_pjsip_session_begin:  Direct media no glare mitigation
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:3984 new_invite:  INDVODA1
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4602 handle_outgoing_response:  INDVODA1: Method is INVITE, Response is 415 Unsupported Media Type
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4618 handle_outgoing_response:  INDVODA1
<--- Transmitting SIP response (423 bytes) to UDP:10.222.222.34:5060 --->
SIP/2.0 415 Unsupported Media Type
Via: SIP/2.0/UDP 10.222.222.34:5060;rport=5060;received=10.222.222.34;branch=z9hG4bK0b93i60008af6lpe17f0.1
Call-ID: FAFF5D5DCCF2B049CD762717@0870ffffffff
From: <sip:+918989898989@10.222.222.34;user=phone>;tag=Cec9b278ZAa6W985
To: <sip:+919898989898@10.222.222.37;user=phone>;tag=f8ff3b42-f81d-4826-a86a-ab255b5ca039
CSeq: 1 INVITE
Server: Asterisk PBX 20.6.0
Content-Length:  0


[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4716 session_inv_on_state_changed:  INDVODA1 Event: TSX_STATE  Inv State: DISCONNCTD
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4453 __print_debug_details: Function session_inv_on_state_changed called on event TSX_STATE
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4467 __print_debug_details: The state change pertains to the endpoint 'INDVODA1()'
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4472 __print_debug_details: The inv session still has an invite_tsx (0x7fdd4c04dfc8)
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4487 __print_debug_details: There is no transaction involved in this state change
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4489 __print_debug_details: The current inv state is DISCONNCTD
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4742 session_inv_on_state_changed: INDVODA1: Source of transaction state change is TX_MSG
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4789 session_inv_on_state_changed:  
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4834 session_inv_on_tsx_state_changed:  INDVODA1 TSX State: Completed  Inv State: DISCONNCTD
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4453 __print_debug_details: Function session_inv_on_tsx_state_changed called on event TSX_STATE[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4467 __print_debug_details: The state change pertains to the endpoint 'INDVODA1()'
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4472 __print_debug_details: The inv session still has an invite_tsx (0x7fdd4c04dfc8)
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4478 __print_debug_details: The UAS INVITE transaction involved in this state change is 0x7fdd4c04dfc8
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4482 __print_debug_details: The current transaction state is Completed
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4484 __print_debug_details: The transaction state change event is TX_MSG
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4489 __print_debug_details: The current inv state is DISCONNCTD
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4855 session_inv_on_tsx_state_changed:  Disconnected
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4254 session_on_tsx_state:  (null session) TSX State: Completed  Inv State: DISCONNCTD
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4262 session_on_tsx_state:  
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4118 new_invite:  INDVODA1
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4209 handle_new_invite_request:  Request: sip:09898989898@10.222.222.37:5060;user=phone Session: INDVODA1
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4329 session_on_rx_request:  (null session) Handled request INVITE sip:09898989898@10.222.222.37:5060;user=phone ? yes
[Aug 17 21:30:35] DEBUG[25256]: chan_pjsip.c:2925 chan_pjsip_session_end:  INDVODA1
[Aug 17 21:30:35] DEBUG[25256]: chan_pjsip.c:2928 chan_pjsip_session_end:  No channel
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:2920 session_destructor: INDVODA1: Destroying SIP session
<--- Received SIP request (397 bytes) from UDP:10.222.222.34:5060 --->
ACK sip:09898989898@10.222.222.37:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.222.222.34:5060;branch=z9hG4bK0b93i60008af6lpe17f0.1
CSeq: 1 ACK
From: <sip:+918989898989@10.222.222.34;user=phone>;tag=Cec9b278ZAa6W985
To: <sip:+919898989898@10.222.222.37;user=phone>;tag=f8ff3b42-f81d-4826-a86a-ab255b5ca039
Call-ID: FAFF5D5DCCF2B049CD762717@0870ffffffff
Max-Forwards: 68
Content-Length: 0


[Aug 17 21:30:35] DEBUG[25255]: res_pjsip/pjsip_distributor.c:500 distributor: Searching for serializer associated with dialog dlg0x7fdd4c039dd8 for Request msg ACK/cseq=1 (rdata0x7fdca00125f8)
[Aug 17 21:30:35] DEBUG[25255]: res_pjsip/pjsip_distributor.c:469 ast_sip_get_distributor_serializer: Calculated serializer pjsip/distributor-00000023 to use for Request msg ACK/cseq=1 (rdata0x7fdca00125f8)
[Aug 17 21:30:35] DEBUG[25256]: netsock2.c:170 ast_sockaddr_split_hostport: Splitting '10.222.222.34' into...
[Aug 17 21:30:35] DEBUG[25256]: netsock2.c:224 ast_sockaddr_split_hostport: ...host '10.222.222.34' and port ''.
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_endpoint_identifier_ip.c:255 ip_identify_match_check: Source address 10.222.222.34:5060 matches identify 'INDVODA1'
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_endpoint_identifier_ip.c:288 common_identify: Identify 'INDVODA1' SIP message matched to endpoint INDVODA1
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4834 session_inv_on_tsx_state_changed:  (null session) TSX State: Confirmed  Inv State: DISCONNCTD
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4453 __print_debug_details: Function session_inv_on_tsx_state_changed called on event TSX_STATE[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4465 __print_debug_details: inv_session 0x7fdd4c01e018 has no ast session
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4472 __print_debug_details: The inv session still has an invite_tsx (0x7fdd4c04dfc8)
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4478 __print_debug_details: The UAS INVITE transaction involved in this state change is 0x7fdd4c04dfc8
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4482 __print_debug_details: The current transaction state is Confirmed
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4484 __print_debug_details: The transaction state change event is RX_MSG
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4489 __print_debug_details: The current inv state is DISCONNCTD
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4845 session_inv_on_tsx_state_changed:  Session ended
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4254 session_on_tsx_state:  (null session) TSX State: Confirmed  Inv State: DISCONNCTD
[Aug 17 21:30:35] DEBUG[25256]: res_pjsip_session.c:4262 session_on_tsx_state:  
smscloud*CLI> 
[Aug 17 21:30:40] DEBUG[25255]: res_pjsip_session.c:4834 session_inv_on_tsx_state_changed:  (null session) TSX State: Terminated  Inv State: DISCONNCTD
[Aug 17 21:30:40] DEBUG[25255]: res_pjsip_session.c:4453 __print_debug_details: Function session_inv_on_tsx_state_changed called on event TSX_STATE[Aug 17 21:30:40] DEBUG[25255]: res_pjsip_session.c:4465 __print_debug_details: inv_session 0x7fdd4c01e018 has no ast session
[Aug 17 21:30:40] DEBUG[25255]: res_pjsip_session.c:4475 __print_debug_details: The inv session does NOT have an invite_tsx
[Aug 17 21:30:40] DEBUG[25255]: res_pjsip_session.c:4478 __print_debug_details: The UAS INVITE transaction involved in this state change is 0x7fdd4c04dfc8
[Aug 17 21:30:40] DEBUG[25255]: res_pjsip_session.c:4482 __print_debug_details: The current transaction state is Terminated
[Aug 17 21:30:40] DEBUG[25255]: res_pjsip_session.c:4484 __print_debug_details: The transaction state change event is TIMER
[Aug 17 21:30:40] DEBUG[25255]: res_pjsip_session.c:4489 __print_debug_details: The current inv state is DISCONNCTD
[Aug 17 21:30:40] DEBUG[25255]: res_pjsip_session.c:4845 session_inv_on_tsx_state_changed:  Session ended
[Aug 17 21:30:40] DEBUG[25255]: res_pjsip_session.c:4254 session_on_tsx_state:  (null session) TSX State: Terminated  Inv State: DISCONNCTD
[Aug 17 21:30:40] DEBUG[25255]: res_pjsip_session.c:4262 session_on_tsx_state:

Following is the pjsip.conf file:

[transport-op-1]
type=transport
protocol=udp    ;udp,tcp,tls,ws,wss
bind=10.222.222.37

[INDOP1]
type=endpoint
transport=transport-op-1
context=in_router
disallow=all
allow=alaw
allow=ulaw
aors=INDOP1
send_pai=yes    ; Send the P Asserted Identity header (default: "no")
;dtmf_mode=auto
dtmf_mode=rfc4733

direct_media=no    ;of these options
contact_user=+919898989898

[INDOP1]
type=aor
contact=sip:10.222.222.34:5060

[INDOP1]
type=identify
endpoint=INDOP1
match=10.222.222.34/32

“Content-Type:application/ISUP;base=itu-t92+;version=ITUT92+”

That is not supported by Asterisk so it’s sending back a 415.

@jcolp thanks for the response. Ok, I will ask the operator to remove this header, but in case they don’t agree, is there any option that I have in Asterisk to handle this ? Can’t I ignore this parameter in Asterisk, since rest of the parameters all seem fine ?

No, there is no option to ignore it.

1 Like