0

I am developing a VoIP app that uses Twilio for telephony. The issue i am facing is that if the AVAudioSession is interrupted while a call is in progress, for example by an incoming FaceTime call, then i am not able continue using Audio session after the interruption ends. The call does not disconnect , but no sound is audible and the microphone is not recording anything either.

I have registered for the AVAudioSessionInterruptionNotification and in the notification handler, I do the following :

 // get the user info dictionary
NSDictionary *interuptionDict = notification.userInfo;
// get the AVAudioSessionInterruptionTypeKey enum from the dictionary
NSInteger interuptionType     = [[interuptionDict valueForKey:AVAudioSessionInterruptionTypeKey] integerValue];
// decide what to do based on interruption type here...
switch (interuptionType)
{
    case AVAudioSessionInterruptionTypeBegan:

        DLog(@"Audio Session Interruption case started.");
        [self setAudioSessionActive:NO];
        break;

    case AVAudioSessionInterruptionTypeEnded:
    {
        DLog(@"Audio Session Interruption case ended.");
        [self setAudioSessionActive:YES];
        break;
    }
    default:
        DLog(@"Audio Session Interruption Notification case default.");
        break;
}

// Activate or deactivate the app's audio session
- (void)setAudioSessionActive:(BOOL)active
{
BOOL success = NO;
NSError *error = nil;
success = [[AVAudioSession sharedInstance] setActive:active error:&error];
if (error)
{
    DLog(@"Error setting audio session : %@", [error description]);
}
else if (success)
{
    DLog(@"Audio session state set successfully :")
}
}

I do not get any errors but the ongoing call just doesn't work.

I have read the Audio session programming guide , Human interface guidelines for audio and other audio related apple documentation. I believe I am following the correct steps. Please give any suggestions as what I might be missing here.

humblePilgrim
  • 1,818
  • 4
  • 25
  • 47

1 Answers1

0

I'm apart of the Twilio Developer Network. From your post, it's not clear whether or not the notifications are being called whenever an interruption event occurs. Regardless, you'll need to make sure to register your audio session singleton for 2 sets of notifications. You've currently only registered for one notification.

First change this

 // get the user info dictionary
NSDictionary *interuptionDict = notification.userInfo;
// get the AVAudioSessionInterruptionTypeKey enum from the dictionary
NSInteger interuptionType     = [[interuptionDict valueForKey:AVAudioSessionInterruptionTypeKey] integerValue];

to this

 NSNumber *interruptionType = [notification.userInfo objectForKey:AVAudioSessionInterruptionTypeKey];
    NSNumber *interruptionOption = [notification.userInfo objectForKey:AVAudioSessionInterruptionOptionKey];

Next, you'll want to use the KVO API to register for both sets of notifications.

Notification 1 (You have this): AVAudioSessionInterruptionNotification

[[NSNotificationCenter defaultCenter] addObserver:self
                                         selector:@selector(handleAudioSessionInterruption:)
                                             name:AVAudioSessionInterruptionNotification
                                           object:aSession];

Notification 2 (Add this): AVAudioSessionMediaServicesWereResetNotification

[[NSNotificationCenter defaultCenter] addObserver:self
                                         selector:@selector(handleMediaServicesReset)
                                             name:AVAudioSessionMediaServicesWereResetNotification
                                           object:aSession];

The system may either pause an active audio session or deallocate it depending on whether or not you answer or reject an incoming call. These 2 notifications take care of both scenarios. See this link for more info on AVAudioSessionMediaServicesWereResetNotification

You also don't need to set your audio session to inactive if a notification occurs, the system does this for you. When a call comes in, the app moves to the background. When it returns, you should allow 1-2 seconds before resuming the audioSession for thread-safety. So your switch statement should look like this

    switch (interruptionType.unsignedIntegerValue) {
            case AVAudioSessionInterruptionTypeBegan:{
                // • Your session is already inactive, you can update the UI if necessary
            } break;
            case AVAudioSessionInterruptionTypeEnded:{

                if (interruptionOption.unsignedIntegerValue == AVAudioSessionInterruptionOptionShouldResume) {
 dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 1), dispatch_get_main_queue(), ^{
                   // • Update the session here 
                     [self setAudioSessionActive:YES];

                });
                }
            } break;
            default:
                break;
        }

Lastly, in the method called for the second notification, make sure to reset the audio session to active.

- (void)handleMediaServicesReset {
        [self setAudioSessionActive:YES];
}

Hope that helps! Let me know if you have any other questions.

sraval
  • 9
  • 3
  • Hi sraval , I tried the scenario after making changes to the code as per your suggestion. But the same problem persists. – humblePilgrim Oct 28 '15 at 12:09
  • Mithun, are your notifications being called when a call comes in? In other words, do you see "Audio Session Interruption case started." in your console whenever a call comes in? – sraval Oct 28 '15 at 16:08
  • 1
    Hi sraval , yes, whenever a FaceTime call comes in and the app goes to background , the audio session interruption notification is received. Likewise when the interruption ends , a notification is received. Consequently I try set the audio session active and that returns success too. But there is no audio in or out – humblePilgrim Oct 30 '15 at 11:01
  • Got it. In that case see this http://stackoverflow.com/questions/27200453/avaudiosession-reactivation-issue he had a similar issue and moving the method to a delegate fixed the problem. – sraval Oct 30 '15 at 18:35
  • 1
    Hi, sraval .. Sorry for the late response. Hope you are still following this. I went through the above post and tried out a solution, but the problem still persists. Also, could you try out the above scenario in the Basic Phone app that comes with Twilio SDK ? Because I think this is a basic use case and should be handled in the SDK itself, or at least clear info should be given as part of the Twilio developer material – humblePilgrim Dec 09 '15 at 05:57