[asterisk-bugs] [JIRA] (ASTERISK-22911) [patch]Asterisk fails to resume WebRTC call from hold

[Jonathan Rose (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-22911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215379#comment-215379 ] 

Jonathan Rose edited comment on ASTERISK-22911 at 2/18/14 12:26 PM:
--------------------------------------------------------------------

By the first patch, I didn't mean the one that was posted here... I meant the one that was applied in r405234.

The problem with relying on that ASSERT return is that if it triggers, Asterisk crashes. At least on my box and those of a few other developers around the office. I understand you can disable those crashes, but for the purpose of Asterisk development, we want to be PJProject assertion free whenever possible.

Also that's not the only code path that is capable of returning PJ_ETOOMANY. There is a second check later on that returns PJ_ETOOMANY without asserting.
{code}
    if (clist->count >= PJ_ICE_MAX_CHECKS) {
        pj_mutex_unlock(ice->mutex);
        return PJ_ETOOMANY;
    }
{code}
Which is why I figured I still needed to be ready to anticipate that return value and clear the candidate list if that happens. I was actually under the impression that this is what you were running into since Asterisk wasn't crashing outright at the PJNATH assertion.

To be honest, I'm less concerned with fixing issues that the existing patch didn't already solve right now. This is more about fixing a regression, but I don't want to leave this issue unresolved since that would also be a regression of sorts if the problem described here was ever actually fixed.
                
      was (Author: jrose):
    By the first patch, I didn't mean the one that was posted here... I meant the one that was applied in r405234.

The problem with relying on that ASSERT return is that if it triggers, Asterisk crashes.  At least on my box and those of a few other developers around the office.

Also that's not the only code path that is capable of returning PJ_ETOOMANY. There is a second check later on that returns PJ_ETOOMANY without asserting.
{code}
    if (clist->count >= PJ_ICE_MAX_CHECKS) {
        pj_mutex_unlock(ice->mutex);
        return PJ_ETOOMANY;
    }
{code}
Which is why I figured I still needed to be ready to anticipate that return value and clear the candidate list if that happens. I was actually under the impression that this is what you were running into since Asterisk wasn't crashing outright at the PJNATH assertion.

To be honest, I'm less concerned with fixing issues that the existing patch didn't already solve right now. This is more about fixing a regression, but I don't want to leave this issue unresolved since that would also be a regression of sorts if the problem described here was ever actually fixed.
                  
> [patch]Asterisk fails to resume WebRTC call from hold
> -----------------------------------------------------
>
>                 Key: ASTERISK-22911
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22911
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_pjsip, Resources/res_rtp_asterisk
>    Affects Versions: 12.0.0-beta2
>         Environment: Server:
> asterisk:svn r403157  --with-srtp --with-pjproject
> pjproject:git asterisk/pjproject HEAD --with-external-srtp --enable-shared CFLAGS="-DNDEBUG"
> Ubuntu Precise 64, 3.2.0-23-generic.
> Client:
> Chrome 33.0.1720.0 canary
> http://sipml5.org/call.htm?svn=203
>            Reporter: Vytis Valentinavičius
>            Assignee: Vytis Valentinavičius
>      Target Release: 11.8.0, 12.1.0
>
>         Attachments: capture_asterisk_211_client_15.pcap.gz, issue_22911.full.log, issue_22911.full.log, issue_22911.full.pjsip.log, works_on_my_machine.patch
>
>
> When in call between soft-phone and WebRTC resuming from holden call does not resume the sound.
> Notices:
> 1. Hold and resume must be made by WebRTC client. Tested with sipml5.org demo.
> 2. Wireshark dump showed that after call is resumed all UDP packets do not reach WebRTC client due to wrong destination port.
> 3. Chrome stops active channel when issued hold command and creates new channel on resume. Channel is bound to new port each time.
> 4. Asterisk spits out such verbose errors:
> Before connection:
> [Nov 26 13:27:01] ERROR[2088]: pjsip:0 <?>: 	icess0x7fbe000 ..Error sending STUN request: Invalid argument
> Later in call (not related to Hold/Resume sequence):
> [Nov 26 13:28:06] WARNING[2177][C-00000000]: res_srtp.c:406 ast_srtp_unprotect: SRTP unprotect failed with: authentication failure 10

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira