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

[Kevin Harwell (JIRA)]

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

Kevin Harwell commented on ASTERISK-22911:
------------------------------------------

Probably not much to add.  r405234 was basically the original patch on the issue refactored a bit ([re]initialized the pjproject values without having to change pjproject source).

I think the intent was that if the session check list could be created and a path found then it would always just use those candidates from then on (it had found a valid path no reason to redo).  Otherwise if it failed then on subsequent reinvites retry in hopes that it might succeed.

The patch had fixed a couple of things (albeit insufficiently), one it no longer crashed, two the call would resume after a hold/unhold.  Unfortunately, the latter was only in one direction it seems.

Apparently the assumption that remote candidates won't change on subsequent reinvites is wrong, so yeah I would agree with the idea of that list having to be "refreshed" somehow each time.  However, that probably depends on how pjsip handles things.
                
> [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