New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error: 506637 -> Inside makeCall, failed to make outgoing call (Previous call is never terminated) #13

Closed
5fcgdaeb opened this Issue Nov 22, 2016 · 21 comments

Comments

Projects
None yet
3 participants
@5fcgdaeb

5fcgdaeb commented Nov 22, 2016

Hello team,

I am using the beta4 version of the new TwilioVoiceClient and we seem to have an issue cleaning up the calls. The very first call works well but after that, the client can't make any more calls. Details are below, do you know why the call is never terminated?

  • I am setting the incomingCall and outgoingCall to nil when the call is over.
  • The incomingConnectionDidDisconnect is never invoked even though I explicitly say self.incomingCall.disconnect().

2016-11-22 11:34:10.594853 RandomTaps[856:704145] [VERBOSE Twilio] Inside constructUri: Registration URL: sip:None@chunderm.gll.twilio.com;transport=tls
2016-11-22 11:34:10.595217 RandomTaps[856:704145] [INFO TVOMakeCallCommand] Call URI: sip:None@chunderm.gll.twilio.com;transport=tls
2016-11-22 11:34:10.595550 RandomTaps[856:704145] PJSIP(4): pjsua_call.c !Making call with acc #0 to sip:None@chunderm.gll.twilio.com;transport=tls
2016-11-22 11:34:10.595841 RandomTaps[856:704145] PJSIP(4): pjsua_aud.c .Set sound device: capture=-1, playback=-2
2016-11-22 11:34:10.596051 RandomTaps[856:704145] PJSIP(4): pjsua_aud.c ..Opening sound device (speaker + mic) PCM@16000/1/20ms
2016-11-22 11:34:10.596228 RandomTaps[856:704145] PJSIP(4): coreaudio_dev. ...Using VoiceProcessingIO audio unit
2016-11-22 11:34:10.923144 RandomTaps[856:704145] [aurioc] 1316: AUIOClient_StartIO failed (-66637)
2016-11-22 11:34:10.930137 RandomTaps[856:704145] PJSIP(4): pjsua_aud.c ..Opening sound device (speaker + mic) PCM@44100/1/20ms
2016-11-22 11:34:10.930346 RandomTaps[856:704145] PJSIP(4): coreaudio_dev. ...Using VoiceProcessingIO audio unit
2016-11-22 11:34:11.015948 RandomTaps[856:704145] [aurioc] 1316: AUIOClient_StartIO failed (-66637)
2016-11-22 11:34:11.019137 RandomTaps[856:704145] PJSIP(4): pjsua_aud.c ..Opening sound device (speaker + mic) PCM@48000/1/20ms
2016-11-22 11:34:11.019336 RandomTaps[856:704145] PJSIP(4): coreaudio_dev. ...Using VoiceProcessingIO audio unit
2016-11-22 11:34:11.108904 RandomTaps[856:704145] [aurioc] 1316: AUIOClient_StartIO failed (-66637)
2016-11-22 11:34:11.114036 RandomTaps[856:704145] PJSIP(4): pjsua_aud.c ..Opening sound device (speaker + mic) PCM@32000/1/20ms
2016-11-22 11:34:11.114227 RandomTaps[856:704145] PJSIP(4): coreaudio_dev. ...Using VoiceProcessingIO audio unit
2016-11-22 11:34:11.201626 RandomTaps[856:704145] [aurioc] 1316: AUIOClient_StartIO failed (-66637)
2016-11-22 11:34:11.204496 RandomTaps[856:704145] PJSIP(4): pjsua_aud.c ..Opening sound device (speaker + mic) PCM@16000/1/20ms
2016-11-22 11:34:11.204682 RandomTaps[856:704145] PJSIP(4): coreaudio_dev. ...Using VoiceProcessingIO audio unit
2016-11-22 11:34:11.294944 RandomTaps[856:704145] [aurioc] 1316: AUIOClient_StartIO failed (-66637)
2016-11-22 11:34:11.300710 RandomTaps[856:704145] PJSIP(4): pjsua_aud.c ..Opening sound device (speaker + mic) PCM@8000/1/20ms
2016-11-22 11:34:11.300905 RandomTaps[856:704145] PJSIP(4): coreaudio_dev. ...Using VoiceProcessingIO audio unit
2016-11-22 11:34:11.388315 RandomTaps[856:704145] [aurioc] 1316: AUIOClient_StartIO failed (-66637)
2016-11-22 11:34:11.391866 RandomTaps[856:704145] PJSIP(1): pjsua_aud.c ..Unable to open sound device: Unknown OpenSSL error 503317117 [status=506637]
2016-11-22 11:34:11.392397 RandomTaps[856:704145] [DEBUG TVOCall] Inside makeCall, failed to make outgoing call. Error: 506637
2016-11-22 11:34:11.392667 RandomTaps[856:704145] [ERROR TVOOutgoingCall] Outgoing call failed with error: Inside makeCall, failed to make outgoing call. Error: 506637
outgoingCall:didFailWithError: Inside makeCall, failed to make outgoing call. Error: 506637
[DEBUG VoiceClient] Inside makeCall:params:delegate:, cannot make call while another active call is in progress.

@5fcgdaeb 5fcgdaeb changed the title from Error: 506637 -> Inside makeCall, failed to make outgoing call (Call is never terminated) to Error: 506637 -> Inside makeCall, failed to make outgoing call (Previous call is never terminated) Nov 22, 2016

@bchen-twilio

This comment has been minimized.

Show comment
Hide comment
@bchen-twilio

bchen-twilio Nov 22, 2016

Contributor

Hi @5fcgdaeb,
Bobie here from the Voice SDK team. Thanks for reporting the issue.
Looks like you are having trouble hanging up the first call. Could you provide the verbose SDK log of disconnecting the first incoming/outgoing call? would also be great if could share some more code details of how the first call and the subsequent call are made/accepted/disconnected.
Are you seeing the incomingCall:didFailWithError: or outgoingCall:didFailWithError: being called during the first call?
By the way I would imagine that you are integrating CallKit with your app?

Contributor

bchen-twilio commented Nov 22, 2016

Hi @5fcgdaeb,
Bobie here from the Voice SDK team. Thanks for reporting the issue.
Looks like you are having trouble hanging up the first call. Could you provide the verbose SDK log of disconnecting the first incoming/outgoing call? would also be great if could share some more code details of how the first call and the subsequent call are made/accepted/disconnected.
Are you seeing the incomingCall:didFailWithError: or outgoingCall:didFailWithError: being called during the first call?
By the way I would imagine that you are integrating CallKit with your app?

@5fcgdaeb

This comment has been minimized.

Show comment
Hide comment
@5fcgdaeb

5fcgdaeb Nov 22, 2016

Hello,

  • The logs are attached. There are 2 log files: First one is for the Caller where the caller makes 2 calls. Second call fails due to the error. Second log file is for the Receiver where it successfully receives the first call. All the hang-up related logs are there. To me, the logs look pretty good; the clean-up seems successful.

  • Another attachment is for the relevant piece of code. Please let me know if you need more info.

  • There is no CallKit integration yet.
    Caller_2.txt
    Receiver_2.txt
    Relevant_Code.txt

5fcgdaeb commented Nov 22, 2016

Hello,

  • The logs are attached. There are 2 log files: First one is for the Caller where the caller makes 2 calls. Second call fails due to the error. Second log file is for the Receiver where it successfully receives the first call. All the hang-up related logs are there. To me, the logs look pretty good; the clean-up seems successful.

  • Another attachment is for the relevant piece of code. Please let me know if you need more info.

  • There is no CallKit integration yet.
    Caller_2.txt
    Receiver_2.txt
    Relevant_Code.txt

@5fcgdaeb

This comment has been minimized.

Show comment
Hide comment
@5fcgdaeb

5fcgdaeb Nov 22, 2016

Also:

  • There are no didFailWithError: invocations during the successful first call. It only happens during the second call; that is expected.

5fcgdaeb commented Nov 22, 2016

Also:

  • There are no didFailWithError: invocations during the successful first call. It only happens during the second call; that is expected.
@bchen-twilio

This comment has been minimized.

Show comment
Hide comment
@bchen-twilio

bchen-twilio Nov 22, 2016

Contributor

Thanks @5fcgdaeb,
Let me take a look and see if I can find anything suspicious.
In the meantime, could you also try the latest release-candidate of the next beta? We've actually fixed a few bugs related to AVAudioSession.
Here's the link: https://drive.google.com/file/d/0B0jCXbOI9plrWlpLRWdfQm5zeTQ/view?usp=sharing
It would be great if you could give it a go and let us know if it helps.

Contributor

bchen-twilio commented Nov 22, 2016

Thanks @5fcgdaeb,
Let me take a look and see if I can find anything suspicious.
In the meantime, could you also try the latest release-candidate of the next beta? We've actually fixed a few bugs related to AVAudioSession.
Here's the link: https://drive.google.com/file/d/0B0jCXbOI9plrWlpLRWdfQm5zeTQ/view?usp=sharing
It would be great if you could give it a go and let us know if it helps.

@5fcgdaeb

This comment has been minimized.

Show comment
Hide comment
@5fcgdaeb

5fcgdaeb Nov 22, 2016

Hello @bchen-twilio ,

  • Sure, I can do that. Any plans to make it available via CocoaPods? That would be easier to integrate.

  • We will be going live with the beta4 at the end of this week. So, it would be great if you could take a look at what the problem might be when you have the time.

Thanks,
Guven.

5fcgdaeb commented Nov 22, 2016

Hello @bchen-twilio ,

  • Sure, I can do that. Any plans to make it available via CocoaPods? That would be easier to integrate.

  • We will be going live with the beta4 at the end of this week. So, it would be great if you could take a look at what the problem might be when you have the time.

Thanks,
Guven.

@5fcgdaeb

This comment has been minimized.

Show comment
Hide comment
@5fcgdaeb

5fcgdaeb Nov 23, 2016

One more detail about the bug:

  • If the receiving party doesn't pick up the call but instead rejects it, then this problem doesn't occur. So, the problem only occurs if there is an established call.

  • Any pointers that you can think of? I can start looking in that direction to fix the issue. Perhaps invoking call() and disconnect() from different threads? I made sure that they are invoked from the main thread.

Thanks,
Guven.

5fcgdaeb commented Nov 23, 2016

One more detail about the bug:

  • If the receiving party doesn't pick up the call but instead rejects it, then this problem doesn't occur. So, the problem only occurs if there is an established call.

  • Any pointers that you can think of? I can start looking in that direction to fix the issue. Perhaps invoking call() and disconnect() from different threads? I made sure that they are invoked from the main thread.

Thanks,
Guven.

@bchen-twilio

This comment has been minimized.

Show comment
Hide comment
@bchen-twilio

bchen-twilio Nov 23, 2016

Contributor

Hi @5fcgdaeb,
So if I am understanding the steps correctly:

  1. the caller first made a call to the receiver
  2. the receiver accepted the call
  3. the receiver hung up the call
  4. the call tried to make another outgoing call to the receiver, after the first call was disconnected
    then the audio error caused the failure.

I need a few more pieces of info from you to dig into the issue:

  • I didn't see any did-disconnect callback message in the caller log. Can you confirm that?
  • Does this happen to all your devices or just the specific device with specific iOS version?
  • Do you see the same error if you run the objc/swift quickstart sample app the team provided?
  • Do you have any special handler about audio or push notification? asking because from the logs I saw a lot of them and just curious to find out what are those.

As for Cocoapods, unfortunately we will only update until the next public beta is ready.

thanks

Contributor

bchen-twilio commented Nov 23, 2016

Hi @5fcgdaeb,
So if I am understanding the steps correctly:

  1. the caller first made a call to the receiver
  2. the receiver accepted the call
  3. the receiver hung up the call
  4. the call tried to make another outgoing call to the receiver, after the first call was disconnected
    then the audio error caused the failure.

I need a few more pieces of info from you to dig into the issue:

  • I didn't see any did-disconnect callback message in the caller log. Can you confirm that?
  • Does this happen to all your devices or just the specific device with specific iOS version?
  • Do you see the same error if you run the objc/swift quickstart sample app the team provided?
  • Do you have any special handler about audio or push notification? asking because from the logs I saw a lot of them and just curious to find out what are those.

As for Cocoapods, unfortunately we will only update until the next public beta is ready.

thanks

@5fcgdaeb

This comment has been minimized.

Show comment
Hide comment
@5fcgdaeb

5fcgdaeb Nov 24, 2016

  • Yes, the steps are correct.

  • I see the disconnect message. Take a look at this line, that is what I print during disconnect:
    2016-11-22 15:50:44.662250 RandomTaps[890:719821] [VERBOSE TVOOutgoingCall] handlePJSIPInviteStateDisconnected. Error: (null)
    SIXAM: OUTGOING DISCONNECT:

  • I have tried two iOS Devices both on 10.1; I didn't have a chance to try it on something else.

  • I haven't run the sample code. I am not sure if the sample code has the hangUp() logic though.

  • No special handler on audio. I mean, I turn on/off the audio via AVAudioSession but nothing special. Also nothing special with the push notifications either; simply call Twilio's method when a push notification is received.

I have a feeling that this bug will not be easy to fix, so I reverted back to the old Twilio SDK and we are going live with that. I will not spend more time on the new one for now.

Also, the old SDK did give an interesting error when I first used it with iOS 10 devices. Much later I have found out the cause and it is documented here: http://stackoverflow.com/questions/36541133/crashed-twilio-pj-pool-alloc/40769003#40769003. The Twilio support actually had no idea, which was a big inconvenience for me since I tried to switch to the new SDK. And the new SDK has this bug now :) Anyway, I just wanted to let you know.

5fcgdaeb commented Nov 24, 2016

  • Yes, the steps are correct.

  • I see the disconnect message. Take a look at this line, that is what I print during disconnect:
    2016-11-22 15:50:44.662250 RandomTaps[890:719821] [VERBOSE TVOOutgoingCall] handlePJSIPInviteStateDisconnected. Error: (null)
    SIXAM: OUTGOING DISCONNECT:

  • I have tried two iOS Devices both on 10.1; I didn't have a chance to try it on something else.

  • I haven't run the sample code. I am not sure if the sample code has the hangUp() logic though.

  • No special handler on audio. I mean, I turn on/off the audio via AVAudioSession but nothing special. Also nothing special with the push notifications either; simply call Twilio's method when a push notification is received.

I have a feeling that this bug will not be easy to fix, so I reverted back to the old Twilio SDK and we are going live with that. I will not spend more time on the new one for now.

Also, the old SDK did give an interesting error when I first used it with iOS 10 devices. Much later I have found out the cause and it is documented here: http://stackoverflow.com/questions/36541133/crashed-twilio-pj-pool-alloc/40769003#40769003. The Twilio support actually had no idea, which was a big inconvenience for me since I tried to switch to the new SDK. And the new SDK has this bug now :) Anyway, I just wanted to let you know.

@bchen-twilio

This comment has been minimized.

Show comment
Hide comment
@bchen-twilio

bchen-twilio Nov 29, 2016

Contributor

Hi @5fcgdaeb,
Sorry for keeping you waiting for the update.
Could you provide us the lines where your application turns on/off audio? The Voice/Client SDK might not happily cooperate in such case but we would definitely love to hear your use case and see if we could provide a fix or workaround.
Thanks.

Contributor

bchen-twilio commented Nov 29, 2016

Hi @5fcgdaeb,
Sorry for keeping you waiting for the update.
Could you provide us the lines where your application turns on/off audio? The Voice/Client SDK might not happily cooperate in such case but we would definitely love to hear your use case and see if we could provide a fix or workaround.
Thanks.

@5fcgdaeb

This comment has been minimized.

Show comment
Hide comment
@5fcgdaeb

5fcgdaeb Nov 29, 2016

Sure, the relevant audio code is attached.

Audio_Code.txt

Quick question: Will the old Twilio SDK be able to pick up background calls when compiled with the iOS 10 base SDK?
To elaborate:

  1. App receives a VoIP Push notification indicating that an incoming call is coming soon (via PushKit).
  2. The app might be dead; so once it wakes up, it registers with Twilio via the register() call.
  3. The result is sometimes good, but sometimes a connection is not established. So, the incoming call is not received. I see the following error in device logs: App linked on IOS_VERSION_10_0+, but doesnt have legacyVoip entitlement.

If the old SDK doesn't properly background connection, we will be forced back to the new Twilio SDK.

Thanks,
Guven.

5fcgdaeb commented Nov 29, 2016

Sure, the relevant audio code is attached.

Audio_Code.txt

Quick question: Will the old Twilio SDK be able to pick up background calls when compiled with the iOS 10 base SDK?
To elaborate:

  1. App receives a VoIP Push notification indicating that an incoming call is coming soon (via PushKit).
  2. The app might be dead; so once it wakes up, it registers with Twilio via the register() call.
  3. The result is sometimes good, but sometimes a connection is not established. So, the incoming call is not received. I see the following error in device logs: App linked on IOS_VERSION_10_0+, but doesnt have legacyVoip entitlement.

If the old SDK doesn't properly background connection, we will be forced back to the new Twilio SDK.

Thanks,
Guven.

@bchen-twilio

This comment has been minimized.

Show comment
Hide comment
@bchen-twilio

bchen-twilio Nov 29, 2016

Contributor

Hi @5fcgdaeb,
Thanks for the �codes. The SDK requires the AVAudioSession category to be AVAudioSessionCategoryPlayAndRecord and mode to be AVAudioSessionModeVoiceChat. I'll try to experiment the category that can happily do the ringtone playback and won't conflict the SDK audio settings.
As for iOS 10 SDK + TwilioClient iOS SDK, unfortunately  had dropped the (background) VoIP socket support in iOS 9/10, the SDK cannot refresh the mobile client's SIP URI to the Twilio Service for incoming connections when the app is not in the active state. This leads to the new Programmable Voice iOS SDK, which leverages 's VoIP Push Service for more reliable incoming connections.
The Programmable Voice iOS SDK 2.0.0 beta5 is coming. Please stay tuned.

Thanks.
bobie

Contributor

bchen-twilio commented Nov 29, 2016

Hi @5fcgdaeb,
Thanks for the �codes. The SDK requires the AVAudioSession category to be AVAudioSessionCategoryPlayAndRecord and mode to be AVAudioSessionModeVoiceChat. I'll try to experiment the category that can happily do the ringtone playback and won't conflict the SDK audio settings.
As for iOS 10 SDK + TwilioClient iOS SDK, unfortunately  had dropped the (background) VoIP socket support in iOS 9/10, the SDK cannot refresh the mobile client's SIP URI to the Twilio Service for incoming connections when the app is not in the active state. This leads to the new Programmable Voice iOS SDK, which leverages 's VoIP Push Service for more reliable incoming connections.
The Programmable Voice iOS SDK 2.0.0 beta5 is coming. Please stay tuned.

Thanks.
bobie

@5fcgdaeb

This comment has been minimized.

Show comment
Hide comment
@5fcgdaeb

5fcgdaeb Nov 29, 2016

Got it. One question here: I am also relying on VoIP Push Service to wake the app up. What else is Twilio offering here that I can't do myself?

5fcgdaeb commented Nov 29, 2016

Got it. One question here: I am also relying on VoIP Push Service to wake the app up. What else is Twilio offering here that I can't do myself?

@bchen-twilio

This comment has been minimized.

Show comment
Hide comment
@bchen-twilio

bchen-twilio Nov 29, 2016

Contributor

Hi @5fcgdaeb,
With the new Programmable Voice iOS SDK, you need to hand off the VoIP Push to Twilio. Instead of sending a VoIP Push to the callee prior to making the real outgoing call, you need to set up the Twilio Push Notification service and credential in the console, so that when Twilio receives the call from the caller, it knows to send the VoIP Push to the callee with the registered identity. Upon receiving the VoIP Push, the callee needs to use the encrypted (security yeah!) token to accept the incoming call. Without the token (if you implement and send the VoIP Push yourself), the callee won't be able to accept the incoming call in the Programmable Voice SDK world.

Thanks
bobie

Contributor

bchen-twilio commented Nov 29, 2016

Hi @5fcgdaeb,
With the new Programmable Voice iOS SDK, you need to hand off the VoIP Push to Twilio. Instead of sending a VoIP Push to the callee prior to making the real outgoing call, you need to set up the Twilio Push Notification service and credential in the console, so that when Twilio receives the call from the caller, it knows to send the VoIP Push to the callee with the registered identity. Upon receiving the VoIP Push, the callee needs to use the encrypted (security yeah!) token to accept the incoming call. Without the token (if you implement and send the VoIP Push yourself), the callee won't be able to accept the incoming call in the Programmable Voice SDK world.

Thanks
bobie

@5fcgdaeb

This comment has been minimized.

Show comment
Hide comment
@5fcgdaeb

5fcgdaeb Nov 29, 2016

Thanks Bobie. I have actually implemented the whole flow with the new Twilio SDK, so I have seen this work in action. One thing I don't understand is that how the new Twilio SDK can establish VoIP connections in the background (after being woken up) while the old SDK cannot. What has changed in the SDK that allows you to do that?

5fcgdaeb commented Nov 29, 2016

Thanks Bobie. I have actually implemented the whole flow with the new Twilio SDK, so I have seen this work in action. One thing I don't understand is that how the new Twilio SDK can establish VoIP connections in the background (after being woken up) while the old SDK cannot. What has changed in the SDK that allows you to do that?

@bchen-twilio

This comment has been minimized.

Show comment
Hide comment
@bchen-twilio

bchen-twilio Nov 29, 2016

Contributor

Actually there is no longer any persistent connection for incoming calls anymore. Unlike the old Client SDK which used to send keep-alive packets and refresh SIP registrations, the Programmable Voice SDK relies on the token in the push notification payload to answer the incoming call, therefore no need to try keeping the persistent SIP URI entry anymore.

Contributor

bchen-twilio commented Nov 29, 2016

Actually there is no longer any persistent connection for incoming calls anymore. Unlike the old Client SDK which used to send keep-alive packets and refresh SIP registrations, the Programmable Voice SDK relies on the token in the push notification payload to answer the incoming call, therefore no need to try keeping the persistent SIP URI entry anymore.

@bchen-twilio

This comment has been minimized.

Show comment
Hide comment
@bchen-twilio

bchen-twilio Dec 1, 2016

Contributor

Hey @5fcgdaeb,
We've just released beta5 to include a couple of bugfixes. Would be great if you could give it a try. Thanks.

Contributor

bchen-twilio commented Dec 1, 2016

Hey @5fcgdaeb,
We've just released beta5 to include a couple of bugfixes. Would be great if you could give it a try. Thanks.

@secondbreakfast

This comment has been minimized.

Show comment
Hide comment
@secondbreakfast

secondbreakfast Jan 20, 2017

Hey @bchen-twilio, I'm experiencing this same error in implementing the beta5 SDK. Similar situation where, if the caller picks up, the previous call is never terminated.

I have not integrated the call with a CXProviderDelegate yet, if that matters.

secondbreakfast commented Jan 20, 2017

Hey @bchen-twilio, I'm experiencing this same error in implementing the beta5 SDK. Similar situation where, if the caller picks up, the previous call is never terminated.

I have not integrated the call with a CXProviderDelegate yet, if that matters.

@bchen-twilio

This comment has been minimized.

Show comment
Hide comment
@bchen-twilio

bchen-twilio Jan 20, 2017

Contributor

@wlschreiber
Hi Will,
Thanks for contacting us. I have a few questions for you while I am trying to understand the situation you are experiencing:

  • what is the scenario you are trying to do in your app and what are the steps that get you into this issue?
  • by "no CXProviderDelegate", did you mean that there is no CallKit integration to your app?
  • do you have any of your own AVAudioSession implementations in your app?

Thanks
bobie

Contributor

bchen-twilio commented Jan 20, 2017

@wlschreiber
Hi Will,
Thanks for contacting us. I have a few questions for you while I am trying to understand the situation you are experiencing:

  • what is the scenario you are trying to do in your app and what are the steps that get you into this issue?
  • by "no CXProviderDelegate", did you mean that there is no CallKit integration to your app?
  • do you have any of your own AVAudioSession implementations in your app?

Thanks
bobie

@secondbreakfast

This comment has been minimized.

Show comment
Hide comment
@secondbreakfast

secondbreakfast Jan 20, 2017

what is the scenario you are trying to do in your app and what are the steps that get you into this issue?
Specifically, was experiencing the issue when trying to place a new outbound call after already placing one. Steps to create an outbound call:

  1. Initialized a PKPushRegistryDelegate and TVONotificationDelegate
  2. Started a call using VoiceClient.sharedInstance().call(accessToken: params: delegate:)
  3. Passed the TVOOutgoingCall object along to a UIViewController, which was a TVOIncomingCallDelegate and TVOOutgoingCallDelegate
  4. Initialized an AVAudioSession using category AVAudioSessionCategoryPlayAndRecord and mode AVAudioSessionModeVoiceChat
  5. Handled outgoingCallDidConnect (and other methods) on the UIViewController
  6. Dismissed the UIViewController on both outgoingCallDidDisconnect and didFailWithError
  7. When attempting to then place another outbound call, got the 506637 error.

by "no CXProviderDelegate", did you mean that there is no CallKit integration to your app?

Correct, I've created a view controller to handle the audio controls for now but am planning on integrating deeper with CallKit once I know everything is working between the app and the server properly.

do you have any of your own AVAudioSession implementations in your app?

Yes, as described above.

Update

Instead of using the UIViewController as the delegate for the TVOIncomingCall/TVOOutgoingCall, I've left those on the same class as the PKPushRegistryDelegate and am using Notifications to just signal the UIViewController when it should dismiss.

This seems to have fixed the issue (I am no longer seeing the "previous call still in session error"), despite the fact that I'm not handling the actual call object any differently. Maybe it was being retained by the ViewController when it shouldn't have? (although I made sure that the view controller was being deinitialized).

secondbreakfast commented Jan 20, 2017

what is the scenario you are trying to do in your app and what are the steps that get you into this issue?
Specifically, was experiencing the issue when trying to place a new outbound call after already placing one. Steps to create an outbound call:

  1. Initialized a PKPushRegistryDelegate and TVONotificationDelegate
  2. Started a call using VoiceClient.sharedInstance().call(accessToken: params: delegate:)
  3. Passed the TVOOutgoingCall object along to a UIViewController, which was a TVOIncomingCallDelegate and TVOOutgoingCallDelegate
  4. Initialized an AVAudioSession using category AVAudioSessionCategoryPlayAndRecord and mode AVAudioSessionModeVoiceChat
  5. Handled outgoingCallDidConnect (and other methods) on the UIViewController
  6. Dismissed the UIViewController on both outgoingCallDidDisconnect and didFailWithError
  7. When attempting to then place another outbound call, got the 506637 error.

by "no CXProviderDelegate", did you mean that there is no CallKit integration to your app?

Correct, I've created a view controller to handle the audio controls for now but am planning on integrating deeper with CallKit once I know everything is working between the app and the server properly.

do you have any of your own AVAudioSession implementations in your app?

Yes, as described above.

Update

Instead of using the UIViewController as the delegate for the TVOIncomingCall/TVOOutgoingCall, I've left those on the same class as the PKPushRegistryDelegate and am using Notifications to just signal the UIViewController when it should dismiss.

This seems to have fixed the issue (I am no longer seeing the "previous call still in session error"), despite the fact that I'm not handling the actual call object any differently. Maybe it was being retained by the ViewController when it shouldn't have? (although I made sure that the view controller was being deinitialized).

@bchen-twilio

This comment has been minimized.

Show comment
Hide comment
@bchen-twilio

bchen-twilio Jan 20, 2017

Contributor

Hi Will,
Thanks for your update.
As I wrote in my previous comment, the SDK manages the AVAudioSession under the hood to provide appropriate audio capabilities for Twilio to use the audio device. For now we would suggest that you don't manually configure the delicate AVAudioSession settings and leave it for the SDK. Could you please try an experiment to do the calls again but without the AVAudioSession lines?
I am guessing you are using the AVFoundation framework in order to play some sound files? If that's the case, we've recently updated our quickstart sample apps, both ObjC and Swift, to demonstrate how to play your own ringtone files in your app without messing up the audio session.

Please let us know if this helps.
Thanks.

Contributor

bchen-twilio commented Jan 20, 2017

Hi Will,
Thanks for your update.
As I wrote in my previous comment, the SDK manages the AVAudioSession under the hood to provide appropriate audio capabilities for Twilio to use the audio device. For now we would suggest that you don't manually configure the delicate AVAudioSession settings and leave it for the SDK. Could you please try an experiment to do the calls again but without the AVAudioSession lines?
I am guessing you are using the AVFoundation framework in order to play some sound files? If that's the case, we've recently updated our quickstart sample apps, both ObjC and Swift, to demonstrate how to play your own ringtone files in your app without messing up the audio session.

Please let us know if this helps.
Thanks.

@bchen-twilio

This comment has been minimized.

Show comment
Hide comment
@bchen-twilio

bchen-twilio Mar 17, 2017

Contributor

Closing this issue. Please re-open or create a new ticket if you run into any trouble in the future.

Contributor

bchen-twilio commented Mar 17, 2017

Closing this issue. Please re-open or create a new ticket if you run into any trouble in the future.

bchen-twilio added a commit to bchen-twilio/voice-quickstart-objc that referenced this issue Jul 5, 2018

Consolidate both swift quickstarts into one repository (#13)
* Consolidate both swift quickstarts into one repository

* Delete old cocoapods framework dependency from the project settings

* Add "use_frameworks!" in the Podfile
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment