We are a telecom provider and do not have access to the Asterisk PBX, only SIP/RTP traces

Asterisk Asterisk SIP
1

Title: Call drops after ~2–3 seconds when routed to Asterisk (BYE sent by mobile side – Pixel Android 17)

We are a telecom provider delivering calls to a customer Asterisk PBX (no direct access to config/logs, only SIP/RTP traces).

Call flow:
Mobile (Pixel 10 Pro / Android 17 beta) → SIP-I carrier → SBC → OpenSIPS → Asterisk

The call is established normally (200 OK / ACK), but after ~2–3 seconds the caller sends BYE and disconnects.

Important detail: the BYE is generated by the mobile side, not Asterisk.

Behavior comparison:

  • Works when routed to a softphone (MicroSIP)

  • Works when routed to another PBX (Bicom)

  • Fails only when routed to this specific Asterisk

SDP offered:

v=0
o=vsi xxxx 1 IN IP4 x.x.x.x
s=SIP Media Capabilities
c=IN IP4 x.x.x.x
t=0 0
m=audio xxxx RTP/AVP 8 18 97
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:97 telephone-event/8000
a=fmtp:97 0-15
a=sendrecv
a=ptime:20

Observations:

  • No SIP errors before disconnect

  • RTP not seen or possibly not flowing correctly

  • Multiple codecs offered (PCMA + G729)

  • Likely direct media (RTP not anchored)

Questions:

  • Can Asterisk media/NAT behavior cause the caller to drop the call shortly after answer?

  • Could direct_media or RTP path issues lead to this behavior with newer Android devices?

  • Any known issues with G.729 (annexb=no) in this type of scenario?

  • Would forcing a single codec (e.g. PCMA only) help?

  • Anyone knows abou if there is any imcompatibility betwem this Pixel with Android 17 BETA version?

PCAPs available if needed.

2

I feel that this could be related to 200 or the ack not being properly delivered. The other side sees the call leg as not properly answered and hangs up.

What does your trace show?

3

Hi,

I would think of missing media at the providers side. Timeouts on SIP layer last 15 seconds (or more like 15 minutes).
HTH
Karsten

1 Like
5

image
image1127×853 79.3 KB

6

It’s somewhat of a partial pcap, but it seems asterisk is re-transmitting the 200 OK multiple times before getting ACK back. Is this a normal INVITE or a re-invite? Also 100 is not being forwarded back to the mobile pixel.

I can’t tell just from that sorry, I am only guessing here. This pcap doesn’t feel normal though. I stand by my original idea that this is a signaling issue. Is mobile consistent on what time it sends back BYE? Does it look like there is a timeout being triggered?

7

I don’t think 100 should be forwarded. I think the proxy will already have sent 100 in response to the INVITE.

Although the UAC is rather slow in sending the ACK, or is losing many final responses, that isn’t in the time frame for the final failure, which is significantly later. Note it is the UAC that has initiated the disconnect, and it is happening rather fast, for any normal timeout setting, but rather slow for an unacceptable offer.

One thing I would eliminate is the G.729. Something might be objecting because of a lack of licences, and it is not normally a sensible choice, in the modern world.

1 Like
8

Hi all,

I’m investigating a possible interoperability issue between Asterisk and a Pixel 10 Pro XL running Android 17 Beta, and I would appreciate any insights from the community.

9

Anyone else with Pixel / Android 17 can confirm?

10

I´ve compared with a pcap from another mobile Network provider on a inbuond call the same way for tha same destination number and it´s work fine, and also the pcap teh behavior is equal, 200 OK, ACK, 100 … And I also opened a ticket with the Mobile compan that this phone number use and they said that was de device that hangups the call on the origim with 2 seconds.

11

Thanks for the input.

I initially suspected that the Android device might be forcing G.729, but I was not able to confirm this.

From what I observed, the call is established using RTP with G.711 (PCMA/PCMU) before the drop occurs.

Also, RTP is confirmed before the teardown, so this does not appear to be a typical no-media timeout scenario.

The device sends a BYE after approximately 2 seconds, which is significantly shorter than standard RTP timeout behavior.

I have also opened an issue on the Google Issue Tracker, as this may be related to a change or regression in the Android 17 Beta media/SIP stack.

Still investigating SDP/RTP consistency and media handling behavior.

12

Unfortunately for Brazilian users I´ve found this.
5g and VoLTE - Google Pixel Community.