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

[Vytis Valentinavičius (JIRA)]

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

Vytis Valentinavičius commented on ASTERISK-22911:
--------------------------------------------------

Hey Jonathan.
I have two points to make:
1. First patch DID NOT fix the problem (my original patch could not be applied since it hacked pjnath library)
2. Your patch may fail to fix this particular bug also:
There are several reasons why asterisk does not resume audio after hold. This time lets fix only on one of them: Asterisk does not change the media destination address.
This happens because Asterisk always 'append' candidates list in ice session. So after a new REINVITE is received old candidates still are at the top of ice resolve list (and are actually confirmed to work).
Thus any new packets that are dispatched to ice resolved address go to wrong (outdated) destination.
As far as I see Your patch just 'works around' the assertion in pjnath library and does not actually alter existing candidates in it. This may be enough IF webrtc client never changes it's destination address (that is client is not running on google chrome =]).
Also I am not aware about thread related issues, but
{code}ao2_container_count(rtp->remote_candidates) + rtp->ice->rcand_cnt > PJ_ICE_MAX_CAND{code}
is practically the same check that is done in pjnath, which (convieniently) is encapsulated in PJ_ASSERT_RETURN. So
{code}pj_ice_sess_create_check_list(rtp->ice, &ufrag, &passwd, ao2_container_count(rtp->remote_candidates), &candidates[0]){code}
Should never return PJ_ETOOMANY...

Maybe You are willing to alter res_rtp_asterisk engine so that an ICE session would be _actually_ recreated and started on each 'ice_start' (and 'ice_stop' should be called appropriately). Then fix proccess_sdp in chan/sip.c to do a parse step separate from ice and other logic.

=]

Either way, I know about these issues, unfortunately I have my own stuff to hack on... So any help will be highly appreciated =]
                
> [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