Push To Talk

RSS for tag

Let people send and receive audio in your app with the push of a button.

Posts under Push To Talk tag

18 Posts

Post

Replies

Boosts

Views

Activity

CallKit and PushToTalk related changes in iOS 26
Starting in iOS 26, two notable changes have been made to CallKit, LiveCommunicationKit, and the PushToTalk framework: As a diagnostic aid, we're introducing new dialogs to warn apps of voip push related issue, for example when they fail to report a call or when when voip push delivery stops. The specific details of that behavior are still being determined and are likely to change over time, however, the critical point here is that these alerts are only intended to help developers debug and improve their app. Because of that, they're specifically tied to development and TestFlight signed builds, so the alert dialogs will not appear for customers running app store builds. The existing termination/crashes will still occur, but the new warning alerts will not appear. As PushToTalk developers have previously been warned, the last unrestricted PushKit entitlement ("com.apple.developer.pushkit.unrestricted-voip.ptt") has been disabled in the iOS 26 SDK. ALL apps that link against the iOS 26 SDK which receive a voip push through PushKit and which fail to report a call to CallKit will be now be terminated by the system, as the API contract has long specified. __ Kevin Elliott DTS Engineer, CoreOS/Hardware
0
0
1.2k
Jun ’25
New PushKit delegate in iOS 26.4
Starting in iOS 26.4, PushKit has introduced a new "didReceiveIncomingVoIPPushWithPayload" delegate, making it explicit whether or not an app is required to report a call for any given push. The new delegate passes in a PKVoIPPushMetadata object which includes a "mustReport" property. We have not documented the exact criteria that will cause a mustReport to return false, but those criteria currently include: The app being in the foreground at the point the push is received. The app being on an active call at the point the push is received. The system determines that delivery delays have made the call old enough that it may no longer be viable. When mustReport is false, apps should call the PushKit completion handler (as they previously have) but are otherwise not required to take any other action. __ Kevin Elliott DTS Engineer, CoreOS/Hardware
0
0
418
Feb ’26
PTT Framework Failing to Un-mute Microphone After Media Services Reset
Hi, I wanted to reach out about an issue we're seeing in PTT Framework. We have been investigating reports from some users that our app would run without issue for a day or so and then they would suddenly be unable to transmit audio but playback continued to work normally. After doing some digging and internal testing I was able to reproduce this by triggering a media services reset while PTT Framework was active (we had joined a channel). When this occurs everything appears to work correctly, all normal callbacks are received and the audio session is activated, but the data from the tap on the input node of our audio engine returns only silence regardless of whether the app is in the foreground or background. I'm able to reproduce this with 100% reliability using the following steps: Activate PTT Framework by joining a channel. Navigate to Settings -> Developer, tap Reset Media Services, and select Reset All Media Services. Return to the app and attempt to transmit. I've validated this behavior both in our app as well as in a separate minimal test app we use internally to validate interactions with the framework. Once we end up in this state it persists through tearing down and recreating our audio engine, deactivating and re-activating the audio session, killing the app and restarting it, etc. The only way we have found to recover from this state is to either reboot the device or leave the framework's channel and join again (basically toggle PTT Framework off and back on). Based on what I was able to find I believe this is the known CallKit issue (r.157725305) referenced in this forum post and does extend to PTT Framework. As mentioned above, we currently haven't found a good way to deal with this. Our current solution to this is to programmatically "toggle" PTT framework. This partially solves the problem but it has a couple issues: It causes the PTT Framework activation and deactivation sounds in quick succession. This is expected but not ideal UX. Because attempting to join a channel when the app is not in the foreground results in a failure with PTChannelError.appNotForeground we can only recover when in the foreground. The second issue is the more serious of the two as our users commonly rely on external wired or BLE devices to trigger PTT calls while the device is locked or the app is in the background. In this scenario we can't automatically recover so they won't know something is wrong until they realize they are only transmitting silence. We can identify when this occurs via the internal media services reset notification but again we only receive this while the app is active. Additionally, if the app was suspended when the reset occurred but then becomes active it is received after a 2-4 second delay so if the app wakes up to start a call, we commonly don't receive it until the user is already in the middle of a call trying to transmit. Is there anything we can do here other than posting a notification telling the user that there is an issue and they need to on-screen the app to resolve it? I've tried to provide as much information as possible but if there's anything else that would be helpful let me know.
0
0
13
6h
Peer to peer walkie talkie.
Subject: Architectural Inquiry: Utilizing Push to Talk Framework for Infrastructureless Peer-to-Peer (Ad-Hoc) Audio Broadcasting Dear Apple Engineering Team, I am writing to seek technical guidance regarding the background lifecycle limitations of the Push to Talk (PTT) framework when operating in completely air-gapped, infrastructureless environments. Our development goal is to build a local, decentralized communication application that allows devices to broadcast and receive real-time audio directly device-to-device (Peer-to-Peer / Ad-Hoc) without relying on a central IP network infrastructure, cellular towers, or an internet-bound connection to Apple Push Notification services (APNs). While we are exploring native frameworks like Multipeer Connectivity or Network.framework (NWListener / NWBrowser) via local Wi-Fi and Bluetooth, we run into severe background execution blocks when integrating them with the Push to Talk framework. When a device's screen is locked and the application is suspended, the operating system aggressively puts local wireless interfaces to sleep, preventing incoming peer-to-peer data packets from waking the application thread to stream incoming audio. And support real time edge language translation? Could you please clarify Apple's official stance and provide guidance on the following points: 1 APNs Bypass for Background Awakening: Does the Push to Talk framework provide any native, local mechanism—such as a specific ⁠PTChannelManager⁠ configuration or entitlement—that allows an incoming local network packet (UDP broadcast/multicast over an ad-hoc connection) to wake a suspended application into the background without a ⁠PTPushResult⁠ triggered by an external APNs token? 2 Bridging Multipeer Connectivity: If an app maintains an active local peer-to-peer session while in the foreground, what is the recommended design pattern to prevent iOS from tearing down those local ad-hoc sockets once the user transitions the app to the background via a locked screen or a system overlay? 3 Core OS Workarounds: If infrastructureless, peer-to-peer audio background wakeups are strictly forbidden or unsupported by the internal Wi-Fi/Bluetooth stacks under the PTT framework, are there any low-level Core OS or accessories-focused pathways you recommend for handling real-time, offline local group communication? Thank you for your time and for helping us understand the engineering boundaries of creating resilient, offline communication tools on iOS and iPadOS. Best regards, Ken Zakreski co Founder and marketing guy.
1
0
71
1w
External analog module
Subject: Technical Inquiry: Interfacing the Push to Talk Framework with External RF Hardware Modules (CB / Amateur Radio Bands) Dear Apple Engineering Team, We are writing to inquire about the architectural flexibility of the Push to Talk (PTT) framework when integrating iOS and iPadOS devices with external, custom RF hardware accessories. Uart. We are developing a specialized communication system that uses an external transceiver module connected via a secure, wired MFi USB-C connection. Our objective is to utilize the native system UI elements provided by the PTT framework (such as the Lock Screen controls and Dynamic Island overlays) to manage transmissions that are broadcast and received over external analog frequencies—specifically Citizens Band (CB) or licensed Amateur (Ham) Radio bands—rather than a standard cellular IP network. Could you please provide guidance on the following framework capabilities and integration boundaries: 1 Routing Audio to External Hardware Pipelines: Can a ⁠PTChannelManager⁠ instance be configured to pipe its outbound audio buffer stream directly to an external USB-C Core Audio accessory for RF modulation, rather than routing it through an internet-bound network socket? 2 Mapping Hardware Interrupts to ⁠PTChannelTransmitRequestSource⁠: When a user presses a physical push-to-talk button on an external microphone or module connected via USB-C, what is the recommended method to map that hardware interrupt so it registers natively as a system-level transmission request? 3 Handling Unsynchronized Incoming Signals: Traditional VoIP PTT apps rely on an incoming Apple Push Notification (APNs) token to wake the app via ⁠PTPushResult⁠ when someone speaks. In an air-gapped RF environment where an external hardware squelch breaks on an analog frequency, how can the external module signal the iOS device to instantly wake the background thread and initialize a receiving audio session without an internet connection? 4 Compliance and Metadata Constraints: Are there any restrictions within the ⁠PTChannelDescriptor⁠ or ⁠PTParticipant⁠ metadata structures that would prevent us from displaying analog channel frequencies, squelch codes, or Amateur Radio callsigns in place of traditional digital usernames? Thank you for your guidance on how we can best bridge Apple’s modern PTT framework with external radio hardware ecosystems. Best regards, Ken Zakreski co Founder, lead developer
1
0
67
1w
Co channel interference resolution
Hello there, We are looking at resolving audio co channel interference resolution... Googles Gemini is saying ... Data Volume: A production-grade model capable of cleanly untangling mixed broadcast channels requires between 5,000 and 10,000 hours of verified audio data to map out diverse vocal characteristics and varying signal strengths. Synthetic Data Generation: Rather than recording manual interference loops, the dataset can be entirely synthetic. Clean speech profiles are digitally mixed using Python pipelines that emulate a GroupTalk channel environment. This includes applying standard codecs, simulating varying packet loss concealment (PLC) artifacts, and injecting real-world environmental noise (like bridge wind or engine room hum). Do you believe that ? Warmest regards, Ken
5
0
124
1w
Push To Talk framework doesn't active audio session in background
We are trying to extend our app with Push To Talk functionality by integrating the Push To Talk framework. We are extensively testing what happens if the app is running in the foreground, in the background or not running at all. When the app is in the foreground, and the user has joined a channel we maintain an open connection to our server. When a remote participant starts streaming audio, we immediately call setActiveRemoteParticipant on our PTChannelManager instance. The PTT system will than call our delegate's channelManager:didActivate audioSession method and we can successfully play the incoming audio. When the app is not running at all, there is of course no active connection initially. When another participant starts talking we send a push notification. The PTT system will start our app in the background, call the incomingPushResult method on our delegate, after returning the remote participant the PTT framework will then call the channelmanager:didJoin delegate method which we will use to re-establish the server connection, the PTT framework then calls our channelManager:didActivate audioSession delegate method and we can then successfully play audio. Now the problem. When the application was initially in the foreground and has an established server connection, we initially keep the server connection active when the app enters the background state, until a certain timeout or the system decides our app needs to be killed / removed from memory. This allows us to finish an incoming audio stream, quickly react on incoming responses etc. When we then receive an incoming audio stream after a certain delay (for example 5 seconds) we call the channelManager.setRemoteParticipant method (using try await syntax). This finishes successfully, without any error, however the channelManager:didActivate audioSession delegate method is never called. Manually setting up an audio session is not allowed either and returns an error. Our current workaround for this issue is to disconnect the server connection as soon as the app goes into the background. This will make sure our server sends a push notification, which is successful in activating the audio session after which we can play audio. However, this means we need to re-establish the connection which will introduce an unnecessary delay before we can start playback (and currently means we loose some audio). This also means we need to do extra checks when going to the background to make sure there is no active incoming stream. After each incoming stream we have to check again if we are in the background and disconnect immediately to make sure we get a push notification next time. This can of course also lead to race conditions in an active conversation where we might need to disconnect between incoming streams and if we don't do this in time we might never get an activated audio session. Now this might be by design, as Apple might not want us to keep the server connection active when the application enters the background state. But if that's the case I would expect the channelManager.setRemoteParticipant method to throw an error, but it doesn't. It returns successfully after which we would expect the audio session to get activated as well. So maybe we are not setting the capabilities of our project correctly (we might need other background permissions as well, although we already experimented with that), or we need to do something else to make this work?
12
0
337
Mar ’26
iOS doesn't handle incoming call of Local PUSH when receiving a Local PUSH after receiving an APNs PUSH
I am developing an application that uses NetworkExtension (Local PUSH function) And VoIP(APNs) PUSH. Nowadays, I found a problem on this app doesn't handle incoming call of Local PUSH when receiving a Local PUSH after receiving an APNs PUSH. My confimation result of my app and server log is below. 11:00 AM: my server(PBX) requests a VoIP(APNs) PUSH notification to the APNs. But my app does not receive the VoIP(APNs) PUSH. At this time, my app is running on LAN (Wi-Fi without internet connection), as a result, NetworkExtension was running. so I think this is normal behaviour. 14:55:11 PM: There is an incoming call from the my server(PBX) via local net, and NetworkExtension calls iOS API(API name is reportIncomingCall). However, iOS does not call the delegate didReceiveIncomingCallWithUserInfo for the reportIncomingCall. 14:55:11 PM: At almost the same time, iOS calls the delegate cdidReceiveIncomingPushWithPayload of VoIP PUSH. (instead of call the delegate didReceiveIncomingCallWithUserInfo for the reportIncomingCall?) And the content of this VoIP(APNs) PUSH was the incoming call at "11:00 AM". In other words, the VoIP(APNs) PUSH at 11:00 AM is stuck inside iOS, and at 14:55:11 PM, from NetworkExtension reports it. I feel there is a problem on iOS doesn't handle incoming call of Local PUSH when receiving a Local PUSH after receiving an VoIP(APNs) PUSH. Would you tell me Apple's opioion about this? If this is known problem, Please tell me about it.
7
0
1.7k
Feb ’26
AudioOutputUnitStart takes ~500 ms when using Push-to-Talk framework after beginTransmission
I’m working with the Push-to-Talk (PTT) framework and observing a consistent delay when starting audio capture. Scenario: A PTT call is already active The AVAudioSession is fully configured I request beginTransmission on the PTT channel I start my Audio Unit for recording (AudioOutputUnitStart) Observed behavior: AudioOutputUnitStart takes ~500 ms This happens whether I start the Audio Unit: after didBeginTransmission, or after AVAudioSession didActivate Comparison: Using the same Audio Unit, same format, and same configuration Without the PTT framework, AudioOutputUnitStart takes ~200 ms Additional notes: I am not modifying or reconfiguring AVAudioSession when requesting beginTransmission The audio session is already set up when the PTT call starts There are no interruptions or route changes at the time of starting the Audio Unit Impact: This extra latency is significant for Push-to-Talk use cases where fast transmit start is critical.
1
0
542
Feb ’26
For receiving audio in PushtoTalk, channelManager(_:didActivate:) not called when app receives first push after backgrounding
I'm implementing the PushToTalk framework and have encountered an issue where channelManager(_:didActivate:) is not called under specific circumstances. What works: App is in foreground, receives PTT push → didActivate is called ✅ App receives audio in foreground, then is backgrounded → subsequent pushes trigger didActivate ✅ What doesn't work: App is launched, user joins channel, then immediately backgrounds PTT push arrives while app is backgrounded incomingPushResult is called, I return .activeRemoteParticipant(participant) The system UI shows the speaker name correctly However, didActivate is never called Audio data arrives via WebSocket but cannot be played (no audio session) Setup: Channel joined successfully before backgrounding UIBackgroundModes includes push-to-talk No manual audio session activation (setActive) anywhere in my code AVAudioEngine setup only happens inside didActivate delegate method Issue persists even after channel restoration via channelDescriptor(restoredChannelUUID:) Question: Is this expected behavior or a bug? If expected, what's the correct approach to handle incoming PTT audio when the app is backgrounded and hasn't received audio while in the foreground yet?
6
0
674
Dec ’25
Share Age Range Permission - Defect 'Ask Always'
Share Age Range Permission is set to 'Ask First'. Application requested for AgeRange via requestAgeRange API. System presented a consent window where user has to make a choice. User did not acted. Application was pushed to background. Our Application supports PushToTalk Framework and we have successfully joined the channel already. User tapped on the blue-pill , SystemUI will get presented. User tapped on the SystemUI, A New Full Screen SystemUI will get presented. User chosen 'Leave' option and our application left the active channel. 10 User brought the application to foreground and the previous "Share Age Range" system window disappeared. 11. After Step 10, We need to terminate and launch our application in order to get the "Share Age Range" system window. Is "Share Age Range" system window getting disappear is expected here or a BUG
0
0
137
Dec ’25
About Delay issues with iPhone VoIP applications
We are encountering the following issue with our VoIP application for iPhone, published on the App Store, and would appreciate your guidance on possible countermeasures. The VoIP application (callee side) utilizes a Wi-Fi network. The sequence leading to the issue is as follows: VoIP App (callee): Launches iPhone (callee): Locks (e.g., by short-pressing the power button) VoIP App (callee): Transitions to a suspended state VoIP App (caller): Initiates a VoIP call VoIP App (callee): Receives a local push notification VoIP App (callee): Answers the incoming call VoIP App (callee): Executes performAnswerCallAction() After this, the VoIP App (callee) uses "NSTimer scheduledTimerWithTimeInterval" to manage internal processing timing. However, the processing sometimes takes longer than the specified waiting time. Specifically, delays of several seconds can occur. We understood that if the user is interacting with the screen and both the iPhone and the VoIP app are in an active state, the VoIP app's processing would not be delayed. However, can significant delays (several seconds) in application processing still occur even when the iPhone is in an active state (i.e., the user is interacting with the screen)?"
5
0
751
Dec ’25
Concerning Socket Disconnection Issues in iPhone VoIP Applications
We are encountering the following issue with our VoIP application for iPhone, published on the App Store, and would appreciate your guidance on possible countermeasures. The VoIP application (callee side) utilizes a Wi-Fi network. The sequence leading to the issue is as follows: VoIP App (callee): Launches iPhone (callee): Locks (e.g., by short-pressing the power button) VoIP App (callee): Transitions to a suspended state VoIP App (caller): Initiates a VoIP call VoIP App (callee): Receives a local push notification VoIP App (callee): Creates a UDP socket for call control (for SIP send/receive) VoIP App (callee): Creates a UDP socket for audio stream (for RTP send/receive) VoIP App (callee): Exchanges SIP messages (INVITE, 100 Trying, 180 Ringing, etc.) using the call control UDP socket VoIP App (callee): Answers the incoming call VoIP App (callee): Executes performAnswerCallAction() Immediately after executing performAnswerCallAction() in the above sequence, the sendto() function for both the "UDP socket for call control (SIP send/receive)" and the "UDP socket for audio stream (RTP send/receive)" occasionally returns errno = 57 (ENOTCONN). (of course The VoIP app itself does not close the sockets in this timing) Given that the user has performed an answer operation, the iPhone is in an active state, and the VoIP app is running, what could be the possible reasons why the sockets suddenly become unusable? Could you please provide guidance on how to avoid such socket closures? Our VoIP app uses SCNetworkReachabilitySetCallback to receive network change notifications, but no notifications regarding network changes were received at the time errno = 57 occurred. Is it possible for sockets used by an application to be closed without any notification to the application itself?
6
0
692
Nov ’25
PushToTalk session sometimes returns silence data after activation
Hello! Thank you for bringing the new iPhone experience with the PushToTalk framework. I have a working walkie talkie app based on the PushToTalk framework. Everything works fine except for an intermittent bug that I face from time to time on different devices with different iOS versions, from iOS 18 to iOS 26.2 Beta. Sometimes the app goes into a state where the AVAudioInputNode input node tap returns buffers with a constant size that contain only silence. Leaving and rejoining a channel helps, but relaunching or reinstalling (from Xcode) the app does not. Rebooting the device or deleting and reinstalling the app also helps. I do not activate the audio session in my app. I only configure it on launch using setCategory(.playAndRecord, options: [.defaultToSpeaker, .allowBluetooth]) So the flow is: channelManager?.requestBeginTransmitting(channelUUID: globalChannelUUID) func channelManager( _ channelManager: PTChannelManager, channelUUID: UUID, didBeginTransmittingFrom source: PTChannelTransmitRequestSource ) func channelManager( _ channelManager: PTChannelManager, didActivate audioSession: AVAudioSession ) { /// ... installTapAndStart() } private func installTapAndStart() { let inputNode = audioEngine.inputNode let hardwareFormat = inputNode.outputFormat(forBus: 0) guard let targetFormat = AVAudioFormat( commonFormat: .pcmFormatFloat32, sampleRate: configuration.audioSampleRate, channels: configuration.audioChannelsCount, interleaved: true ) else { handleError(RecorderError.invalidAudioFormat) return } let converter = AVAudioConverter(from: hardwareFormat, to: targetFormat)! print("[QUICOpusRecorder]: installTap") inputNode.installTap(onBus: 0, bufferSize: tapBufferSize, format: hardwareFormat) { [weak self] buffer, _ in guard let self else { return } // Here I handle audio data and sometimes get silence } //... do { audioEngine.prepare() try audioEngine.start() } catch { print(" ⚠️ Audio engine start error: \(error)") handleError(error) } } Moreover, if the app is in the foreground and PushToTalk gets stuck in this “silence bug”, I can avoid relying on the PushToTalk flow and simulate audio session activation manually in code. In this case I do not request a transmission and do not use any PushToTalk related code, and the app captures audio data perfectly. Once I leave the channel and rejoin it again, the issue is fixed and I start to receive non silent buffers of varying size, as expected. It works for a while. It can work fine for a day or more, communicating without launching the app, or with the app in the foreground. But it can also go into the “silence” state 30 minutes after working normally. I have no clue why this happens. The only thing I notice is that when the app is in this “stuck silence bug” state, iOS does not play its “chirp” system sound when audio recording starts. P.S. Channel descriptor restoration code: extension PushToTalkEngine: PTChannelRestorationDelegate { public func channelDescriptor(restoredChannelUUID channelUUID: UUID) -> PTChannelDescriptor { print("☀️ \(#function) channelUUID: \(channelUUID)") Task { @MainActor in // Here I fetch more detailed channel data asynchronously do { await initChannelManagerIfNeeded(channelUUID: channelUUID) let channelDescriptor = currentChannelDescriptor() lastChannelDescriptorName = channelDescriptor.name try await channelManager?.setChannelDescriptor( channelDescriptor, channelUUID: channelUUID ) } catch { handleError(error) } } return PTChannelDescriptor(name: "Loading...", image: nil) } } private func initChannelManagerIfNeeded(channelUUID: UUID? = nil) async { guard let channelUUID = channelUUID ?? currentUser?.globalChannelUUID else { print("❌ No global channel uuid found") return } do { guard channelManager == nil else { try await channelManager?.setTransmissionMode(.halfDuplex, channelUUID: channelUUID) return } channelManager = try await PTChannelManager.channelManager( delegate: self, restorationDelegate: self ) try await channelManager?.setTransmissionMode(.halfDuplex, channelUUID: channelUUID) } catch { handleError(error) } }
1
0
655
Nov ’25
PushToTalk
Using the PushToTalk library, call requestBeginTransmitting (channelUUID: UUID) on a Bluetooth device and then use the PTChannelManagerial Delegate proxy method channelManager:(PTChannelManager *)channelManager didActivateAudioSession:(AVAudioSession *)audioSession Start recording sound inside. Completed recording
11
0
1.4k
Oct ’25
Question about PT Framework channel tone behaviour
I've been wondering if there is a way to modify or even disable tones for indicating channel states. The behaviour regarding tones seems like a black box with little documentation. During migration to Apple's PT Framework we've noticed that there are few scenarios where a tone is played which doesn't match certain certifications. For example; moving from a channel to another produces a tone which would fail a test case. I understand the reasoning fully, as it marks that the channel is ready to transmit or receive, but this doesn't mirror the behaviour of TETRA which would be wanted in this case. I'm also wondering if there would be any way to directly communicate feedback regarding PT Framework?
3
0
484
Oct ’25
[iOS 26] [PushToTalk] Not receiving microphone PCM sample when Transmission Starts from System UI.
Steps To reproduce: Login to application and App has joined the PTC channel. Push the application to background and Lock the device. From the System UI press the talk button which will start transmit. Audio Session has been activated and Audio unit has been initialised properly. On terminator side no media is being played out. Issue observed consistently on specific models which has configured audio codec with Stereo type. More details are added : FB20281626
0
0
670
Oct ’25
CallKit連携でError 4099が頻発し、NEAppPushDelegateの通知が取得できず着信画面が表示されない問題について
iOSアプリでNEAppPushSessionを使い、NEAppPushDelegateの通知を受けてCallKitの着信画面を表示する実装をしていますが、以下の問題に直面しています。 8/13 ログにて下記のエラーが頻発しました。 通知の受け取りテストを約120回してその間ずっとこのエラーが出ていました。 エラー 2025-08-14 11:27:06.793073 +0900 nesessionmanager NESMAppPushSession[SimplePushDefaultConfiguration:7B7218F3-94B5-4AE5-9B9E-94E176694D02] failed to report incoming call to CallKit, error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.callkit.networkextension.messagecontrollerhost was invalidated from this process." UserInfo={NSDebugDescription=The connection to service named com.apple.callkit.networkextension.messagecontrollerhost was invalidated from this process.} このエラーログが頻発した後、callkitの通知画面が表示されなくなりました。 ですがどうやら通知の監視は開始しているようです。 15時間後の8/14 時間をあけたからか、再度通知が来るようになりました。 ですが再度通知の受け取りテストを行った時に同じエラーログが出ました。 再度通知テストを約120回程行ったら、このエラーログが頻発した後、callkitの通知画面が表示されなくなりました。 ですがどうやら今回も通知の監視は開始しているようです。 15時間後の8/15 今日は15時間かけても通知を取得できませんでした。 ですが同じく通知の監視は開始していそうです。 iPhoneの再起動、Xcodeのクリーンアップ、アンインストールして再インストールなどしても通知は来ないままでした。 また、不思議なことに通知が来ない事象が起きた端末以外でも同じように通知を取得することができません。 他の通知は受け取ることができますが独自の通知であるNEAppPushManagerだけ通知を取得することができません。 質問です。 再度通知を出すためには何をすれば良いでしょうか。 この事象は4099エラーを出しすぎたことにより発生する障害なのでしょうか。 4099エラーを出ている原因は何でしょうか。
0
0
567
Aug ’25
Delay in Microphone Input When Talking While Receiving Audio in PTT Framework (Full Duplex Mode)
Context: I am currently developing an app using the Push-to-Talk (PTT) framework. I have reviewed both the PTT framework documentation and the CallKit demo project to better understand how to properly manage audio session activation and AVAudioEngine setup. I am not activating the audio session manually. The audio session configuration is handled in the incomingPushResult or didBeginTransmitting callbacks from the PTChannelManagerDelegate. I am using a single AVAudioEngine instance for both input and playback. The engine is started in the didActivate callback from the PTChannelManagerDelegate. When I receive a push in full duplex mode, I set the active participant to the user who is speaking. Issue When I attempt to talk while the other participant is already speaking, my input tap on the input node takes a few seconds to return valid PCM audio data. Initially, it returns an empty PCM audio block. Details: The audio session is already active and configured with .playAndRecord. The input tap is already installed when the engine is started. When I talk from a neutral state (no one is speaking), the system plays the standard "microphone activation" tone, which covers this initial delay. However, this does not happen when I am already receiving audio. Assumptions / Current Setup Because the audio session is active in play and record, I assumed that microphone input would be available immediately, even while receiving audio. However, there seems to be a delay before valid input is delivered to the tap, only occurring when switching from a receive state to simultaneously talking. Questions Is this expected behavior when using the PTT framework in full duplex mode with a shared AVAudioEngine? Should I be restarting or reconfiguring the engine or audio session when beginning to talk while receiving audio? Is there a recommended pattern for managing microphone readiness in this scenario to avoid the initial empty PCM buffer? Would using separate engines for input and output improve responsiveness? I would like to confirm the correct approach to handling simultaneous talk and receive in full duplex mode using PTT framework and AVAudioEngine. Specifically, I need guidance on ensuring the microphone is ready to capture audio immediately without the delay seen in my current implementation. Relevant Code Snippets Engine Setup func setup() { let input = audioEngine.inputNode do { try input.setVoiceProcessingEnabled(true) } catch { print("Could not enable voice processing \(error)") return } input.isVoiceProcessingAGCEnabled = false let output = audioEngine.outputNode let mainMixer = audioEngine.mainMixerNode audioEngine.connect(pttPlayerNode, to: mainMixer, format: outputFormat) audioEngine.connect(beepNode, to: mainMixer, format: outputFormat) audioEngine.connect(mainMixer, to: output, format: outputFormat) // Initialize converters converter = AVAudioConverter(from: inputFormat, to: outputFormat)! f32ToInt16Converter = AVAudioConverter(from: outputFormat, to: inputFormat)! audioEngine.prepare() } Input Tap Installation func installTap() { guard AudioHandler.shared.checkMicrophonePermission() else { print("Microphone not granted for recording") return } guard !isInputTapped else { print("[AudioEngine] Input is already tapped!") return } let input = audioEngine.inputNode let microphoneFormat = input.inputFormat(forBus: 0) let microphoneDownsampler = AVAudioConverter(from: microphoneFormat, to: outputFormat)! let desiredFormat = outputFormat let inputFramesNeeded = AVAudioFrameCount((Double(OpusCodec.DECODED_PACKET_NUM_SAMPLES) * microphoneFormat.sampleRate) / desiredFormat.sampleRate) input.installTap(onBus: 0, bufferSize: inputFramesNeeded, format: input.inputFormat(forBus: 0)) { [weak self] buffer, when in guard let self = self else { return } // Output buffer: 1920 frames at 16kHz guard let outputBuffer = AVAudioPCMBuffer(pcmFormat: desiredFormat, frameCapacity: AVAudioFrameCount(OpusCodec.DECODED_PACKET_NUM_SAMPLES)) else { return } outputBuffer.frameLength = outputBuffer.frameCapacity let inputBlock: AVAudioConverterInputBlock = { inNumPackets, outStatus in outStatus.pointee = .haveData return buffer } var error: NSError? let converterResult = microphoneDownsampler.convert(to: outputBuffer, error: &error, withInputFrom: inputBlock) if converterResult != .haveData { DebugLogger.shared.print("Downsample error \(converterResult)") } else { self.handleDownsampledBuffer(outputBuffer) } } isInputTapped = true }
4
0
561
Aug ’25
CallKit and PushToTalk related changes in iOS 26
Starting in iOS 26, two notable changes have been made to CallKit, LiveCommunicationKit, and the PushToTalk framework: As a diagnostic aid, we're introducing new dialogs to warn apps of voip push related issue, for example when they fail to report a call or when when voip push delivery stops. The specific details of that behavior are still being determined and are likely to change over time, however, the critical point here is that these alerts are only intended to help developers debug and improve their app. Because of that, they're specifically tied to development and TestFlight signed builds, so the alert dialogs will not appear for customers running app store builds. The existing termination/crashes will still occur, but the new warning alerts will not appear. As PushToTalk developers have previously been warned, the last unrestricted PushKit entitlement ("com.apple.developer.pushkit.unrestricted-voip.ptt") has been disabled in the iOS 26 SDK. ALL apps that link against the iOS 26 SDK which receive a voip push through PushKit and which fail to report a call to CallKit will be now be terminated by the system, as the API contract has long specified. __ Kevin Elliott DTS Engineer, CoreOS/Hardware
Replies
0
Boosts
0
Views
1.2k
Activity
Jun ’25
New PushKit delegate in iOS 26.4
Starting in iOS 26.4, PushKit has introduced a new "didReceiveIncomingVoIPPushWithPayload" delegate, making it explicit whether or not an app is required to report a call for any given push. The new delegate passes in a PKVoIPPushMetadata object which includes a "mustReport" property. We have not documented the exact criteria that will cause a mustReport to return false, but those criteria currently include: The app being in the foreground at the point the push is received. The app being on an active call at the point the push is received. The system determines that delivery delays have made the call old enough that it may no longer be viable. When mustReport is false, apps should call the PushKit completion handler (as they previously have) but are otherwise not required to take any other action. __ Kevin Elliott DTS Engineer, CoreOS/Hardware
Replies
0
Boosts
0
Views
418
Activity
Feb ’26
PTT Framework Failing to Un-mute Microphone After Media Services Reset
Hi, I wanted to reach out about an issue we're seeing in PTT Framework. We have been investigating reports from some users that our app would run without issue for a day or so and then they would suddenly be unable to transmit audio but playback continued to work normally. After doing some digging and internal testing I was able to reproduce this by triggering a media services reset while PTT Framework was active (we had joined a channel). When this occurs everything appears to work correctly, all normal callbacks are received and the audio session is activated, but the data from the tap on the input node of our audio engine returns only silence regardless of whether the app is in the foreground or background. I'm able to reproduce this with 100% reliability using the following steps: Activate PTT Framework by joining a channel. Navigate to Settings -> Developer, tap Reset Media Services, and select Reset All Media Services. Return to the app and attempt to transmit. I've validated this behavior both in our app as well as in a separate minimal test app we use internally to validate interactions with the framework. Once we end up in this state it persists through tearing down and recreating our audio engine, deactivating and re-activating the audio session, killing the app and restarting it, etc. The only way we have found to recover from this state is to either reboot the device or leave the framework's channel and join again (basically toggle PTT Framework off and back on). Based on what I was able to find I believe this is the known CallKit issue (r.157725305) referenced in this forum post and does extend to PTT Framework. As mentioned above, we currently haven't found a good way to deal with this. Our current solution to this is to programmatically "toggle" PTT framework. This partially solves the problem but it has a couple issues: It causes the PTT Framework activation and deactivation sounds in quick succession. This is expected but not ideal UX. Because attempting to join a channel when the app is not in the foreground results in a failure with PTChannelError.appNotForeground we can only recover when in the foreground. The second issue is the more serious of the two as our users commonly rely on external wired or BLE devices to trigger PTT calls while the device is locked or the app is in the background. In this scenario we can't automatically recover so they won't know something is wrong until they realize they are only transmitting silence. We can identify when this occurs via the internal media services reset notification but again we only receive this while the app is active. Additionally, if the app was suspended when the reset occurred but then becomes active it is received after a 2-4 second delay so if the app wakes up to start a call, we commonly don't receive it until the user is already in the middle of a call trying to transmit. Is there anything we can do here other than posting a notification telling the user that there is an issue and they need to on-screen the app to resolve it? I've tried to provide as much information as possible but if there's anything else that would be helpful let me know.
Replies
0
Boosts
0
Views
13
Activity
6h
Peer to peer walkie talkie.
Subject: Architectural Inquiry: Utilizing Push to Talk Framework for Infrastructureless Peer-to-Peer (Ad-Hoc) Audio Broadcasting Dear Apple Engineering Team, I am writing to seek technical guidance regarding the background lifecycle limitations of the Push to Talk (PTT) framework when operating in completely air-gapped, infrastructureless environments. Our development goal is to build a local, decentralized communication application that allows devices to broadcast and receive real-time audio directly device-to-device (Peer-to-Peer / Ad-Hoc) without relying on a central IP network infrastructure, cellular towers, or an internet-bound connection to Apple Push Notification services (APNs). While we are exploring native frameworks like Multipeer Connectivity or Network.framework (NWListener / NWBrowser) via local Wi-Fi and Bluetooth, we run into severe background execution blocks when integrating them with the Push to Talk framework. When a device's screen is locked and the application is suspended, the operating system aggressively puts local wireless interfaces to sleep, preventing incoming peer-to-peer data packets from waking the application thread to stream incoming audio. And support real time edge language translation? Could you please clarify Apple's official stance and provide guidance on the following points: 1 APNs Bypass for Background Awakening: Does the Push to Talk framework provide any native, local mechanism—such as a specific ⁠PTChannelManager⁠ configuration or entitlement—that allows an incoming local network packet (UDP broadcast/multicast over an ad-hoc connection) to wake a suspended application into the background without a ⁠PTPushResult⁠ triggered by an external APNs token? 2 Bridging Multipeer Connectivity: If an app maintains an active local peer-to-peer session while in the foreground, what is the recommended design pattern to prevent iOS from tearing down those local ad-hoc sockets once the user transitions the app to the background via a locked screen or a system overlay? 3 Core OS Workarounds: If infrastructureless, peer-to-peer audio background wakeups are strictly forbidden or unsupported by the internal Wi-Fi/Bluetooth stacks under the PTT framework, are there any low-level Core OS or accessories-focused pathways you recommend for handling real-time, offline local group communication? Thank you for your time and for helping us understand the engineering boundaries of creating resilient, offline communication tools on iOS and iPadOS. Best regards, Ken Zakreski co Founder and marketing guy.
Replies
1
Boosts
0
Views
71
Activity
1w
External analog module
Subject: Technical Inquiry: Interfacing the Push to Talk Framework with External RF Hardware Modules (CB / Amateur Radio Bands) Dear Apple Engineering Team, We are writing to inquire about the architectural flexibility of the Push to Talk (PTT) framework when integrating iOS and iPadOS devices with external, custom RF hardware accessories. Uart. We are developing a specialized communication system that uses an external transceiver module connected via a secure, wired MFi USB-C connection. Our objective is to utilize the native system UI elements provided by the PTT framework (such as the Lock Screen controls and Dynamic Island overlays) to manage transmissions that are broadcast and received over external analog frequencies—specifically Citizens Band (CB) or licensed Amateur (Ham) Radio bands—rather than a standard cellular IP network. Could you please provide guidance on the following framework capabilities and integration boundaries: 1 Routing Audio to External Hardware Pipelines: Can a ⁠PTChannelManager⁠ instance be configured to pipe its outbound audio buffer stream directly to an external USB-C Core Audio accessory for RF modulation, rather than routing it through an internet-bound network socket? 2 Mapping Hardware Interrupts to ⁠PTChannelTransmitRequestSource⁠: When a user presses a physical push-to-talk button on an external microphone or module connected via USB-C, what is the recommended method to map that hardware interrupt so it registers natively as a system-level transmission request? 3 Handling Unsynchronized Incoming Signals: Traditional VoIP PTT apps rely on an incoming Apple Push Notification (APNs) token to wake the app via ⁠PTPushResult⁠ when someone speaks. In an air-gapped RF environment where an external hardware squelch breaks on an analog frequency, how can the external module signal the iOS device to instantly wake the background thread and initialize a receiving audio session without an internet connection? 4 Compliance and Metadata Constraints: Are there any restrictions within the ⁠PTChannelDescriptor⁠ or ⁠PTParticipant⁠ metadata structures that would prevent us from displaying analog channel frequencies, squelch codes, or Amateur Radio callsigns in place of traditional digital usernames? Thank you for your guidance on how we can best bridge Apple’s modern PTT framework with external radio hardware ecosystems. Best regards, Ken Zakreski co Founder, lead developer
Replies
1
Boosts
0
Views
67
Activity
1w
Co channel interference resolution
Hello there, We are looking at resolving audio co channel interference resolution... Googles Gemini is saying ... Data Volume: A production-grade model capable of cleanly untangling mixed broadcast channels requires between 5,000 and 10,000 hours of verified audio data to map out diverse vocal characteristics and varying signal strengths. Synthetic Data Generation: Rather than recording manual interference loops, the dataset can be entirely synthetic. Clean speech profiles are digitally mixed using Python pipelines that emulate a GroupTalk channel environment. This includes applying standard codecs, simulating varying packet loss concealment (PLC) artifacts, and injecting real-world environmental noise (like bridge wind or engine room hum). Do you believe that ? Warmest regards, Ken
Replies
5
Boosts
0
Views
124
Activity
1w
Push To Talk framework doesn't active audio session in background
We are trying to extend our app with Push To Talk functionality by integrating the Push To Talk framework. We are extensively testing what happens if the app is running in the foreground, in the background or not running at all. When the app is in the foreground, and the user has joined a channel we maintain an open connection to our server. When a remote participant starts streaming audio, we immediately call setActiveRemoteParticipant on our PTChannelManager instance. The PTT system will than call our delegate's channelManager:didActivate audioSession method and we can successfully play the incoming audio. When the app is not running at all, there is of course no active connection initially. When another participant starts talking we send a push notification. The PTT system will start our app in the background, call the incomingPushResult method on our delegate, after returning the remote participant the PTT framework will then call the channelmanager:didJoin delegate method which we will use to re-establish the server connection, the PTT framework then calls our channelManager:didActivate audioSession delegate method and we can then successfully play audio. Now the problem. When the application was initially in the foreground and has an established server connection, we initially keep the server connection active when the app enters the background state, until a certain timeout or the system decides our app needs to be killed / removed from memory. This allows us to finish an incoming audio stream, quickly react on incoming responses etc. When we then receive an incoming audio stream after a certain delay (for example 5 seconds) we call the channelManager.setRemoteParticipant method (using try await syntax). This finishes successfully, without any error, however the channelManager:didActivate audioSession delegate method is never called. Manually setting up an audio session is not allowed either and returns an error. Our current workaround for this issue is to disconnect the server connection as soon as the app goes into the background. This will make sure our server sends a push notification, which is successful in activating the audio session after which we can play audio. However, this means we need to re-establish the connection which will introduce an unnecessary delay before we can start playback (and currently means we loose some audio). This also means we need to do extra checks when going to the background to make sure there is no active incoming stream. After each incoming stream we have to check again if we are in the background and disconnect immediately to make sure we get a push notification next time. This can of course also lead to race conditions in an active conversation where we might need to disconnect between incoming streams and if we don't do this in time we might never get an activated audio session. Now this might be by design, as Apple might not want us to keep the server connection active when the application enters the background state. But if that's the case I would expect the channelManager.setRemoteParticipant method to throw an error, but it doesn't. It returns successfully after which we would expect the audio session to get activated as well. So maybe we are not setting the capabilities of our project correctly (we might need other background permissions as well, although we already experimented with that), or we need to do something else to make this work?
Replies
12
Boosts
0
Views
337
Activity
Mar ’26
iOS doesn't handle incoming call of Local PUSH when receiving a Local PUSH after receiving an APNs PUSH
I am developing an application that uses NetworkExtension (Local PUSH function) And VoIP(APNs) PUSH. Nowadays, I found a problem on this app doesn't handle incoming call of Local PUSH when receiving a Local PUSH after receiving an APNs PUSH. My confimation result of my app and server log is below. 11:00 AM: my server(PBX) requests a VoIP(APNs) PUSH notification to the APNs. But my app does not receive the VoIP(APNs) PUSH. At this time, my app is running on LAN (Wi-Fi without internet connection), as a result, NetworkExtension was running. so I think this is normal behaviour. 14:55:11 PM: There is an incoming call from the my server(PBX) via local net, and NetworkExtension calls iOS API(API name is reportIncomingCall). However, iOS does not call the delegate didReceiveIncomingCallWithUserInfo for the reportIncomingCall. 14:55:11 PM: At almost the same time, iOS calls the delegate cdidReceiveIncomingPushWithPayload of VoIP PUSH. (instead of call the delegate didReceiveIncomingCallWithUserInfo for the reportIncomingCall?) And the content of this VoIP(APNs) PUSH was the incoming call at "11:00 AM". In other words, the VoIP(APNs) PUSH at 11:00 AM is stuck inside iOS, and at 14:55:11 PM, from NetworkExtension reports it. I feel there is a problem on iOS doesn't handle incoming call of Local PUSH when receiving a Local PUSH after receiving an VoIP(APNs) PUSH. Would you tell me Apple's opioion about this? If this is known problem, Please tell me about it.
Replies
7
Boosts
0
Views
1.7k
Activity
Feb ’26
AudioOutputUnitStart takes ~500 ms when using Push-to-Talk framework after beginTransmission
I’m working with the Push-to-Talk (PTT) framework and observing a consistent delay when starting audio capture. Scenario: A PTT call is already active The AVAudioSession is fully configured I request beginTransmission on the PTT channel I start my Audio Unit for recording (AudioOutputUnitStart) Observed behavior: AudioOutputUnitStart takes ~500 ms This happens whether I start the Audio Unit: after didBeginTransmission, or after AVAudioSession didActivate Comparison: Using the same Audio Unit, same format, and same configuration Without the PTT framework, AudioOutputUnitStart takes ~200 ms Additional notes: I am not modifying or reconfiguring AVAudioSession when requesting beginTransmission The audio session is already set up when the PTT call starts There are no interruptions or route changes at the time of starting the Audio Unit Impact: This extra latency is significant for Push-to-Talk use cases where fast transmit start is critical.
Replies
1
Boosts
0
Views
542
Activity
Feb ’26
For receiving audio in PushtoTalk, channelManager(_:didActivate:) not called when app receives first push after backgrounding
I'm implementing the PushToTalk framework and have encountered an issue where channelManager(_:didActivate:) is not called under specific circumstances. What works: App is in foreground, receives PTT push → didActivate is called ✅ App receives audio in foreground, then is backgrounded → subsequent pushes trigger didActivate ✅ What doesn't work: App is launched, user joins channel, then immediately backgrounds PTT push arrives while app is backgrounded incomingPushResult is called, I return .activeRemoteParticipant(participant) The system UI shows the speaker name correctly However, didActivate is never called Audio data arrives via WebSocket but cannot be played (no audio session) Setup: Channel joined successfully before backgrounding UIBackgroundModes includes push-to-talk No manual audio session activation (setActive) anywhere in my code AVAudioEngine setup only happens inside didActivate delegate method Issue persists even after channel restoration via channelDescriptor(restoredChannelUUID:) Question: Is this expected behavior or a bug? If expected, what's the correct approach to handle incoming PTT audio when the app is backgrounded and hasn't received audio while in the foreground yet?
Replies
6
Boosts
0
Views
674
Activity
Dec ’25
Share Age Range Permission - Defect 'Ask Always'
Share Age Range Permission is set to 'Ask First'. Application requested for AgeRange via requestAgeRange API. System presented a consent window where user has to make a choice. User did not acted. Application was pushed to background. Our Application supports PushToTalk Framework and we have successfully joined the channel already. User tapped on the blue-pill , SystemUI will get presented. User tapped on the SystemUI, A New Full Screen SystemUI will get presented. User chosen 'Leave' option and our application left the active channel. 10 User brought the application to foreground and the previous "Share Age Range" system window disappeared. 11. After Step 10, We need to terminate and launch our application in order to get the "Share Age Range" system window. Is "Share Age Range" system window getting disappear is expected here or a BUG
Replies
0
Boosts
0
Views
137
Activity
Dec ’25
About Delay issues with iPhone VoIP applications
We are encountering the following issue with our VoIP application for iPhone, published on the App Store, and would appreciate your guidance on possible countermeasures. The VoIP application (callee side) utilizes a Wi-Fi network. The sequence leading to the issue is as follows: VoIP App (callee): Launches iPhone (callee): Locks (e.g., by short-pressing the power button) VoIP App (callee): Transitions to a suspended state VoIP App (caller): Initiates a VoIP call VoIP App (callee): Receives a local push notification VoIP App (callee): Answers the incoming call VoIP App (callee): Executes performAnswerCallAction() After this, the VoIP App (callee) uses "NSTimer scheduledTimerWithTimeInterval" to manage internal processing timing. However, the processing sometimes takes longer than the specified waiting time. Specifically, delays of several seconds can occur. We understood that if the user is interacting with the screen and both the iPhone and the VoIP app are in an active state, the VoIP app's processing would not be delayed. However, can significant delays (several seconds) in application processing still occur even when the iPhone is in an active state (i.e., the user is interacting with the screen)?"
Replies
5
Boosts
0
Views
751
Activity
Dec ’25
Concerning Socket Disconnection Issues in iPhone VoIP Applications
We are encountering the following issue with our VoIP application for iPhone, published on the App Store, and would appreciate your guidance on possible countermeasures. The VoIP application (callee side) utilizes a Wi-Fi network. The sequence leading to the issue is as follows: VoIP App (callee): Launches iPhone (callee): Locks (e.g., by short-pressing the power button) VoIP App (callee): Transitions to a suspended state VoIP App (caller): Initiates a VoIP call VoIP App (callee): Receives a local push notification VoIP App (callee): Creates a UDP socket for call control (for SIP send/receive) VoIP App (callee): Creates a UDP socket for audio stream (for RTP send/receive) VoIP App (callee): Exchanges SIP messages (INVITE, 100 Trying, 180 Ringing, etc.) using the call control UDP socket VoIP App (callee): Answers the incoming call VoIP App (callee): Executes performAnswerCallAction() Immediately after executing performAnswerCallAction() in the above sequence, the sendto() function for both the "UDP socket for call control (SIP send/receive)" and the "UDP socket for audio stream (RTP send/receive)" occasionally returns errno = 57 (ENOTCONN). (of course The VoIP app itself does not close the sockets in this timing) Given that the user has performed an answer operation, the iPhone is in an active state, and the VoIP app is running, what could be the possible reasons why the sockets suddenly become unusable? Could you please provide guidance on how to avoid such socket closures? Our VoIP app uses SCNetworkReachabilitySetCallback to receive network change notifications, but no notifications regarding network changes were received at the time errno = 57 occurred. Is it possible for sockets used by an application to be closed without any notification to the application itself?
Replies
6
Boosts
0
Views
692
Activity
Nov ’25
PushToTalk session sometimes returns silence data after activation
Hello! Thank you for bringing the new iPhone experience with the PushToTalk framework. I have a working walkie talkie app based on the PushToTalk framework. Everything works fine except for an intermittent bug that I face from time to time on different devices with different iOS versions, from iOS 18 to iOS 26.2 Beta. Sometimes the app goes into a state where the AVAudioInputNode input node tap returns buffers with a constant size that contain only silence. Leaving and rejoining a channel helps, but relaunching or reinstalling (from Xcode) the app does not. Rebooting the device or deleting and reinstalling the app also helps. I do not activate the audio session in my app. I only configure it on launch using setCategory(.playAndRecord, options: [.defaultToSpeaker, .allowBluetooth]) So the flow is: channelManager?.requestBeginTransmitting(channelUUID: globalChannelUUID) func channelManager( _ channelManager: PTChannelManager, channelUUID: UUID, didBeginTransmittingFrom source: PTChannelTransmitRequestSource ) func channelManager( _ channelManager: PTChannelManager, didActivate audioSession: AVAudioSession ) { /// ... installTapAndStart() } private func installTapAndStart() { let inputNode = audioEngine.inputNode let hardwareFormat = inputNode.outputFormat(forBus: 0) guard let targetFormat = AVAudioFormat( commonFormat: .pcmFormatFloat32, sampleRate: configuration.audioSampleRate, channels: configuration.audioChannelsCount, interleaved: true ) else { handleError(RecorderError.invalidAudioFormat) return } let converter = AVAudioConverter(from: hardwareFormat, to: targetFormat)! print("[QUICOpusRecorder]: installTap") inputNode.installTap(onBus: 0, bufferSize: tapBufferSize, format: hardwareFormat) { [weak self] buffer, _ in guard let self else { return } // Here I handle audio data and sometimes get silence } //... do { audioEngine.prepare() try audioEngine.start() } catch { print(" ⚠️ Audio engine start error: \(error)") handleError(error) } } Moreover, if the app is in the foreground and PushToTalk gets stuck in this “silence bug”, I can avoid relying on the PushToTalk flow and simulate audio session activation manually in code. In this case I do not request a transmission and do not use any PushToTalk related code, and the app captures audio data perfectly. Once I leave the channel and rejoin it again, the issue is fixed and I start to receive non silent buffers of varying size, as expected. It works for a while. It can work fine for a day or more, communicating without launching the app, or with the app in the foreground. But it can also go into the “silence” state 30 minutes after working normally. I have no clue why this happens. The only thing I notice is that when the app is in this “stuck silence bug” state, iOS does not play its “chirp” system sound when audio recording starts. P.S. Channel descriptor restoration code: extension PushToTalkEngine: PTChannelRestorationDelegate { public func channelDescriptor(restoredChannelUUID channelUUID: UUID) -> PTChannelDescriptor { print("☀️ \(#function) channelUUID: \(channelUUID)") Task { @MainActor in // Here I fetch more detailed channel data asynchronously do { await initChannelManagerIfNeeded(channelUUID: channelUUID) let channelDescriptor = currentChannelDescriptor() lastChannelDescriptorName = channelDescriptor.name try await channelManager?.setChannelDescriptor( channelDescriptor, channelUUID: channelUUID ) } catch { handleError(error) } } return PTChannelDescriptor(name: "Loading...", image: nil) } } private func initChannelManagerIfNeeded(channelUUID: UUID? = nil) async { guard let channelUUID = channelUUID ?? currentUser?.globalChannelUUID else { print("❌ No global channel uuid found") return } do { guard channelManager == nil else { try await channelManager?.setTransmissionMode(.halfDuplex, channelUUID: channelUUID) return } channelManager = try await PTChannelManager.channelManager( delegate: self, restorationDelegate: self ) try await channelManager?.setTransmissionMode(.halfDuplex, channelUUID: channelUUID) } catch { handleError(error) } }
Replies
1
Boosts
0
Views
655
Activity
Nov ’25
PushToTalk
Using the PushToTalk library, call requestBeginTransmitting (channelUUID: UUID) on a Bluetooth device and then use the PTChannelManagerial Delegate proxy method channelManager:(PTChannelManager *)channelManager didActivateAudioSession:(AVAudioSession *)audioSession Start recording sound inside. Completed recording
Replies
11
Boosts
0
Views
1.4k
Activity
Oct ’25
Question about PT Framework channel tone behaviour
I've been wondering if there is a way to modify or even disable tones for indicating channel states. The behaviour regarding tones seems like a black box with little documentation. During migration to Apple's PT Framework we've noticed that there are few scenarios where a tone is played which doesn't match certain certifications. For example; moving from a channel to another produces a tone which would fail a test case. I understand the reasoning fully, as it marks that the channel is ready to transmit or receive, but this doesn't mirror the behaviour of TETRA which would be wanted in this case. I'm also wondering if there would be any way to directly communicate feedback regarding PT Framework?
Replies
3
Boosts
0
Views
484
Activity
Oct ’25
[iOS 26] [PushToTalk] Not receiving microphone PCM sample when Transmission Starts from System UI.
Steps To reproduce: Login to application and App has joined the PTC channel. Push the application to background and Lock the device. From the System UI press the talk button which will start transmit. Audio Session has been activated and Audio unit has been initialised properly. On terminator side no media is being played out. Issue observed consistently on specific models which has configured audio codec with Stereo type. More details are added : FB20281626
Replies
0
Boosts
0
Views
670
Activity
Oct ’25
CallKit連携でError 4099が頻発し、NEAppPushDelegateの通知が取得できず着信画面が表示されない問題について
iOSアプリでNEAppPushSessionを使い、NEAppPushDelegateの通知を受けてCallKitの着信画面を表示する実装をしていますが、以下の問題に直面しています。 8/13 ログにて下記のエラーが頻発しました。 通知の受け取りテストを約120回してその間ずっとこのエラーが出ていました。 エラー 2025-08-14 11:27:06.793073 +0900 nesessionmanager NESMAppPushSession[SimplePushDefaultConfiguration:7B7218F3-94B5-4AE5-9B9E-94E176694D02] failed to report incoming call to CallKit, error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.callkit.networkextension.messagecontrollerhost was invalidated from this process." UserInfo={NSDebugDescription=The connection to service named com.apple.callkit.networkextension.messagecontrollerhost was invalidated from this process.} このエラーログが頻発した後、callkitの通知画面が表示されなくなりました。 ですがどうやら通知の監視は開始しているようです。 15時間後の8/14 時間をあけたからか、再度通知が来るようになりました。 ですが再度通知の受け取りテストを行った時に同じエラーログが出ました。 再度通知テストを約120回程行ったら、このエラーログが頻発した後、callkitの通知画面が表示されなくなりました。 ですがどうやら今回も通知の監視は開始しているようです。 15時間後の8/15 今日は15時間かけても通知を取得できませんでした。 ですが同じく通知の監視は開始していそうです。 iPhoneの再起動、Xcodeのクリーンアップ、アンインストールして再インストールなどしても通知は来ないままでした。 また、不思議なことに通知が来ない事象が起きた端末以外でも同じように通知を取得することができません。 他の通知は受け取ることができますが独自の通知であるNEAppPushManagerだけ通知を取得することができません。 質問です。 再度通知を出すためには何をすれば良いでしょうか。 この事象は4099エラーを出しすぎたことにより発生する障害なのでしょうか。 4099エラーを出ている原因は何でしょうか。
Replies
0
Boosts
0
Views
567
Activity
Aug ’25
Delay in Microphone Input When Talking While Receiving Audio in PTT Framework (Full Duplex Mode)
Context: I am currently developing an app using the Push-to-Talk (PTT) framework. I have reviewed both the PTT framework documentation and the CallKit demo project to better understand how to properly manage audio session activation and AVAudioEngine setup. I am not activating the audio session manually. The audio session configuration is handled in the incomingPushResult or didBeginTransmitting callbacks from the PTChannelManagerDelegate. I am using a single AVAudioEngine instance for both input and playback. The engine is started in the didActivate callback from the PTChannelManagerDelegate. When I receive a push in full duplex mode, I set the active participant to the user who is speaking. Issue When I attempt to talk while the other participant is already speaking, my input tap on the input node takes a few seconds to return valid PCM audio data. Initially, it returns an empty PCM audio block. Details: The audio session is already active and configured with .playAndRecord. The input tap is already installed when the engine is started. When I talk from a neutral state (no one is speaking), the system plays the standard "microphone activation" tone, which covers this initial delay. However, this does not happen when I am already receiving audio. Assumptions / Current Setup Because the audio session is active in play and record, I assumed that microphone input would be available immediately, even while receiving audio. However, there seems to be a delay before valid input is delivered to the tap, only occurring when switching from a receive state to simultaneously talking. Questions Is this expected behavior when using the PTT framework in full duplex mode with a shared AVAudioEngine? Should I be restarting or reconfiguring the engine or audio session when beginning to talk while receiving audio? Is there a recommended pattern for managing microphone readiness in this scenario to avoid the initial empty PCM buffer? Would using separate engines for input and output improve responsiveness? I would like to confirm the correct approach to handling simultaneous talk and receive in full duplex mode using PTT framework and AVAudioEngine. Specifically, I need guidance on ensuring the microphone is ready to capture audio immediately without the delay seen in my current implementation. Relevant Code Snippets Engine Setup func setup() { let input = audioEngine.inputNode do { try input.setVoiceProcessingEnabled(true) } catch { print("Could not enable voice processing \(error)") return } input.isVoiceProcessingAGCEnabled = false let output = audioEngine.outputNode let mainMixer = audioEngine.mainMixerNode audioEngine.connect(pttPlayerNode, to: mainMixer, format: outputFormat) audioEngine.connect(beepNode, to: mainMixer, format: outputFormat) audioEngine.connect(mainMixer, to: output, format: outputFormat) // Initialize converters converter = AVAudioConverter(from: inputFormat, to: outputFormat)! f32ToInt16Converter = AVAudioConverter(from: outputFormat, to: inputFormat)! audioEngine.prepare() } Input Tap Installation func installTap() { guard AudioHandler.shared.checkMicrophonePermission() else { print("Microphone not granted for recording") return } guard !isInputTapped else { print("[AudioEngine] Input is already tapped!") return } let input = audioEngine.inputNode let microphoneFormat = input.inputFormat(forBus: 0) let microphoneDownsampler = AVAudioConverter(from: microphoneFormat, to: outputFormat)! let desiredFormat = outputFormat let inputFramesNeeded = AVAudioFrameCount((Double(OpusCodec.DECODED_PACKET_NUM_SAMPLES) * microphoneFormat.sampleRate) / desiredFormat.sampleRate) input.installTap(onBus: 0, bufferSize: inputFramesNeeded, format: input.inputFormat(forBus: 0)) { [weak self] buffer, when in guard let self = self else { return } // Output buffer: 1920 frames at 16kHz guard let outputBuffer = AVAudioPCMBuffer(pcmFormat: desiredFormat, frameCapacity: AVAudioFrameCount(OpusCodec.DECODED_PACKET_NUM_SAMPLES)) else { return } outputBuffer.frameLength = outputBuffer.frameCapacity let inputBlock: AVAudioConverterInputBlock = { inNumPackets, outStatus in outStatus.pointee = .haveData return buffer } var error: NSError? let converterResult = microphoneDownsampler.convert(to: outputBuffer, error: &error, withInputFrom: inputBlock) if converterResult != .haveData { DebugLogger.shared.print("Downsample error \(converterResult)") } else { self.handleDownsampledBuffer(outputBuffer) } } isInputTapped = true }
Replies
4
Boosts
0
Views
561
Activity
Aug ’25