Does the OS has dedicated volume levels for each AVAudioSessionCategory.

Application will also set the AVAudioSessionCategory to AVAudioSessionCategoryPlayback Provided the User has chosen the output to Speaker.

Why are you doing this instead of just staying in PlayAndRecord?

More specifically, as a CallKit app, you need to leave your category alone, as changing your category state can mean you're no longer running with the "phone" category. That can have much broader and unpleasant consequences like, for example, allowing other apps to interrupt your calls without warning.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Also, on the specific question here:

Could you please explain about this inconsistency w.r.t. Volume level.

There are actually at least two different factors at work here:

1. I don't know the full details of the entire system, but the system does maintain separate volume states for at least CallKit and "other audio", so that phone calls start at a consistent volume regardless of other activity.

2. Different audio session configurations have different maximum volumes and, in particular, "Playback" is louder than "PlayAndRecord". In addition, the CallKit AudioSession has a noticeably higher max than a standard "PlayAndRecord".

Either/both of those factors mean that it's normal for the playback volume to change when the audio category changes. This doesn't matter for most apps, as they simply pick the category that best fits their overall requirements and don't change it.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

For CallKit Call Reported Calls As it is having the highest priority as a phone call , we are not changing the category to AVAudioSessionCategoryPlayback , we will remain in AVAudioSessionCategoryPlayAndRecord. Even if we attempt to change the category , it will fail, we are kind of aware of this. This behaviour is applicable even for PusToTalk reported calls , can you please confirm?

For CallKit, Call Reported Calls As it is having the highest priority as a phone call , we are not changing the category to AVAudioSessionCategoryPlayback , we will remain in AVAudioSessionCategoryPlayAndRecord.

Sort of. Strictly, the "phone" audio session is a different, private audio category that is similarly to AVAudioSessionCategoryPlayAndRecord but not identical.

Even if we attempt to change the category , it will fail; we are kind of aware of this.

This is actually standard behavior within the audio system, as you're not allowed to change categories while your session is active. CallKit adds two complications to that:

1. CallKit handles session activation, so you don't directly "know" that you're activating your session.

2. Your app cannot reliably reactivate the phone session, so if you manually deactivate, you may not be able to reactivate.

This behaviour is applicable even for PusToTalk reported calls; can you please confirm?

Yes. The PushToTalk framework is actually implemented as a variant of the same call architecture, so its audio session should be managed in the same way.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

We have one more follow up query on this. If we chose to stay in AVAudioSessionCategoryPlayAndRecord

And consider our application supports both the output when there is an active call running [Built-In Receiver, Speaker]

At any given time, if user choses his preferred output route then the volume level should remain same, that is our expectation. Could you please let us know is there any deviation from Apple frameworks from this?

Just to make it clear, if user has set the volume level to say 60% when the output was set to BuiltIn Receiver and then user switches the output to Speaker, we expect the volume level to remain in 60%

We have one more follow-up query on this. If we choose to stay in AVAudioSessionCategoryPlayAndRecord

Just to be clear, I think choosing to avoid CallKit is an extremely poor choice for any VoIP app. Without CallKit, your app is subject to the standard system interruption rules, with means things like the now playing app can seize the audio session, at which point your app will suspend (assuming it's in the background).

More critically, incoming CallKit calls have a higher audio priority than ANY other audio on the system, which means an incoming call from any CallKit app will IMMEDIATELY interrupt your app’s audio session, forcing it to suspend. In practice, this effectively means that either user receiving any call (not even answering, just receiving) will force your app to hang up its call.

That issue was the primary factor that led to CallKit's introduction in iOS 10.

At any given time, if the user chooses his preferred output route, then the volume level should remain the same; that is our expectation.

What do you mean by "remain the same"? The problem here is that there isn't any standard way to represent the user-perceived volume level, which means actual volume level varies WIDELY between audio accessories. There's a fairly wide band that particular accessories tend to fall between, but the variation between accessories is very wide. More to the point, in all accessory categories, there are outliers and/or configurations that fall FAR outside the "normal" range.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware