[asterisk-bugs] [JIRA] (ASTERISK-22911) 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=212406#comment-212406 ] 

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

> Just so we know how to try and reproduce this, you are running a version of Asterisk 12, using chan_sip with a websocket connection on one end of the bridge and a standard SIP over UDP channel on the other end of the bridge. The bridge chosen is a simple_bridge, as one channel is encrypting media using SDES-SRTP while the other is unencrypted.

Absolutely correct.

> You stated earlier that wireshark showed that Asterisk was sending RTP to the wrong port; it is clear that Chrome is changing the port number on the re-INVITE that initiates the hold. Can you attach a pcap demonstrating this?

I checked the 'chrome://webrtc-internals/' regarding the last notice. It surely shows the changed port. Bottom of attached pcap shows UDP traffic with ICMP 'Port unreachable' responses for each server->client packet.
                
> 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: Channels/chan_sip/WebSocket, 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
>         Attachments: capture_asterisk_211_client_15.pcap.gz, issue_22911.full.log, issue_22911.full.log, issue_22911.full.pjsip.log
>
>
> 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