New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 3349 link

Starred by 31 users

Issue metadata

Status: Assigned
Last visit > 30 days ago
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Sign in to add a comment

pranswer with BUNDLE doesn't enable bundling

Reported by, May 14 2014

Issue description

What steps will reproduce the problem?
1. start a call with Chrome
2. setRemoteDescription call with type=pranswer and setup=active
3. DTLS client hello message sent to Chrome
4. DTLS server hello message received

What is the expected result?
  I expect to receive in DTLS server hello message an use_srtp extension attribute but with no success. 
  using bouncy castle library following error is printed out: "DTLS extended server hello does not include the use_srtp extension!" and in fact no use_srtp attribute is present in the server hello message (while with type=answer all works perfectly).

  Chrome behavior is correct? 

  What are the differences between an answer and a pranswer? Is accepted (or maybe is mandatory) to receive unencrypted rtp packets in pranswer state?

What version of the product are you using? On what operating system?
  Chrome 34.0.1847.137 m, Windows 8

Please provide any additional information below.

type: pranswer, sdp: v=0
o=ZTE 8992120731499920000 1088450255 IN IP4
c=IN IP4
t=0 0
m=audio 20000 RTP/SAVPF 8
c=IN IP4
a=rtcp:20000 IN IP4
a=fingerprint:sha-256 C7:26:60:EF:BD:FE:D7:6B:63:50:D9:E5:32:C4:98:5A:D5:FD:A5:51:EA:F6:A6:F7:2C:F5:17:43:0B:AF:CA:B6
a=ssrc:628730 cname:mwg@C-
a=ssrc:628730 msid:mwg@M-1412918751 mwg@L-audio
a=ssrc:628730 mslabel:mwg@M-1412918751
a=ssrc:628730 label:mwg@L-audio
a=rtpmap:8 PCMA/8000
a=candidate:dc894 1 udp 2130706431 20000 typ host
a=candidate:dc895 2 udp 2130706431 20000 typ host

69.4 KB Download
1.4 KB Download
Project Member

Comment 1 by, May 15 2014

@jiay, please help to comment on this.
Project Member

Comment 2 by, May 15 2014

We probably don't set up the DTLS adapter properly on a PRANSWER.

Comment 3 by, May 19 2014

For PRANSWER, WebRtcSession does not call BaseSession::MaybeEnableMuxingSupport, which triggers pushing the ciphers down to DtlsTransportChannlWrapper if it's an ANSWER.


is not calling BaseSession::MaybeEnableMuxingSupport for PRANSWER intentional? Why?
Project Member

Comment 4 by, May 19 2014

Status: Available
When we first added BUNDLE, I don't think we had PRANSWER at all. And we wanted to wait until we have the final answer on BUNDLE. If we have BUNDLE in the PRANSWER, I think it should be ok to call BaseSession::MaybeEnableMuxingSupport
Project Member

Comment 6 by, May 20 2014

There are more problems:
1. The TransportChannelImpl is not connected to the TransportChannelProxy before negotiation is completed (i.e. TransportProxy::CompleteNegotiation). So the DtlsTransportChannel OPEN state is not populated up. 
I'm not sure how to fix this.

2. DtlsTransportChannelWrapper::SetSrtpCiphers is not called until negotiation is completed, which is after DTLS handshake started. 
This can be fixed by calling DtlsTransportChannelWrapper::SetupDtls again.

Project Member

Comment 7 by, May 27 2014

Project Member

Comment 8 by, Jul 7 2014

 Issue 3530  has been merged into this issue.

Comment 9 by, Oct 14 2014

Labels: Area-Network
any news on this issue?

Comment 11 by, Nov 3 2014

Labels: Area-Compliance-1.0 EngTriaged IceBox
As a workaround, can you either
- Not use bundle with pranswer, or
- Start out not using bundle, then do a second offer/answer to turn on bundle?

Comment 12 by, Nov 3 2014

Status: Assigned
Project Member

Comment 13 by, Nov 7 2014

 Issue 3982  has been merged into this issue.
What is the status for this problem? Not being able to play out early media when calling from webrtc into the SIP-world is a big problem, we play currently local ringback instead as a workaround, but this is not close to sufficient if the early media is an anouncement.
Project Member

Comment 15 by, Jul 17 2015

 Issue 4837  has been merged into this issue.
Project Member

Comment 16 by, Aug 28 2015

Ping, jiayl@ do you have cycles to fix this soonish? If so, could you add a milestone label?
Project Member

Comment 17 by, Aug 28 2015

Project Member

Comment 18 by, Aug 28 2015

We've refactored our network code a lot since this bug was reported.  And we're doing so even more with this CL:

Could someone please try reproing this bug with a new version of Chrome.  If that still repros, we can try a build of Chrome with that CL and see if it fixes it. 

Project Member

Comment 19 by, Aug 28 2015

Labels: -IceBox Mstone-47
Project Member

Comment 20 by, Sep 1 2015

I was directed here from

Using today's Chrome Canary (47.0.2498.0):
1) Open
2) Click the Call button (and click allow if you see a gUM prompt)
3) Click the Accept button

Issue - I still see this error in the js console:
Uncaught (in promise) Failed to set local  sdp: Session error code: ERROR_TRANSPORT. Session error description: Couldn't set up DTLS-SRTP on RTP channel..
Facing the same issue
rtcninja:ERROR:RTCPeerConnection setRemoteDescription() | error: +1ms Failed to set remote answer sdp: Session error code: ERROR_TRANSPORT. Session error description: Couldn't set up DTLS-SRTP on RTP channel..
Project Member

Comment 22 by, Oct 6 2015

Labels: -EngTriaged
Project Member

Comment 23 by, Oct 26 2015

Labels: EngTriaged
Taylor, can you figure out where our support for pranswer is?
Project Member

Comment 24 by, Nov 5 2015

Since I'm working on this related area, I'm grabbing this bug.
Project Member

Comment 25 by, Nov 5 2015

Taylor's change might have addressed this issue. I don't see error from the the testing page with most recent chrome build.
Issue - I still see this error in the js console:Failed to set local  sdp: Session error code: ERROR_TRANSPORT. Session error description: Couldn't set up DTLS-SRTP on RTP channel..

Who can tell me how to solve this problem? Thanks a lot.
Project Member

Comment 27 by, Nov 11 2015

panpancui1993@ What version of Chrome are you using? Could you try Canary or Dev?
version 46.0.2490.86 m 
I had a try to use Google Chrome 48.0.2561.0 canary. Pranswer does work. I want to know What version of Chrome stable will support pranswer?
Project Member

Comment 30 by, Nov 12 2015

Labels: -Mstone-47 Mstone-48
By the looks of it, M48 I guess since it's too late to merge this to M47.
Project Member

Comment 31 by, Dec 21 2015

 Issue 5196  has been merged into this issue.
Project Member

Comment 32 by, Dec 28 2015

Labels: -Mstone-48 Mstone-49

'pranswer' is not working for me with Chrome build number: "Version 49.0.2614.4 canary". My client initiates an audio call & receives early answer media. It applies the early answer media as 'pranswer'. After this, IceConnectionState got stuck at 'checking'.

Please have a look at the attached Chrome debug logs. 
694 KB View Download
The time stamp in the logs to check offer-answer:

offer: [2060:1972:0107/203147:INFO:CONSOLE(1170)] "Offer:
provisional-answer: [2060:1972:0107/203148:INFO:CONSOLE(672)] "early media answer: 

Adding to above comment, 
If I set the same 'provisional answer' as 'answer', then, no issues. voice path is fine.
Looks like, Audio channel is not becoming 'writable'. May be because of this issue:

[Working case when early media sdp set as 'answer']
[604:1236:0108/]  -- success
[604:1236:0108/] Jingle:Channel[audio|1|__]: DTLS handshake complete.
[604:1236:0108/] Jingle:Channel[audio|1|__]: set_dtls_state from:1 to 2
[604:1236:0108/] Jingle:Channel[audio|1|__]: set_writable from:0 to 1
[604:1236:0108/] audio TransportChannel 1 writability changed to 1.
[604:1236:0108/] Channel writable (audio) for the first time
[604:1236:0108/] Using Cand[15648896:1:udp:2122260223:10.133.134.x:5820:local::0:a10EHLuA1seykpQq:wWK6SOCZl715nxknHaiDojxj]->Cand[41:1:udp:2130706431:135.27.108.x:56044:local::0:22Rh3eri:e2taTaWSIBpBtBIxqmOBPNYl]
[604:1236:0108/] Installing keys from DTLS-SRTP on audio RTP

[Non-Working case when early media sdp set as 'pranswer']
[3352:1380:0107/] Jingle:Channel[audio|1|__]: DTLS handshake complete.
[3352:1380:0107/] Jingle:Channel[audio|1|__]: set_dtls_state from:1 to 2
[3352:1380:0107/] Jingle:Channel[audio|1|__]: set_writable from:0 to 1
[3352:1380:0107/] audio TransportChannel 1 writability changed to 1.
[3352:1380:0107/] OpenSSLStreamAdapter::Read(2048)
[3352:1380:0107/]  -- error want read
Project Member

Comment 37 by, Jan 25 2016

Labels: -Mstone-49 Mstone-51
Project Member

Comment 38 by, Jan 28 2016

Labels: -Mstone-51
Removing milestone, since fixing this isn't a Q1 OKR.
Project Member

Comment 39 by, Jan 29 2016

From the log, it appears that the issue is that we don't enable BUNDLE or rtcp-mux on the pranswer. So we're still waiting for RTCP candidates, which never arrive.

Justin: Is there any reason NOT to enable BUNDLE/rtcp-mux on a pranswer? JSEP seems to indicate we should.
Project Member

Comment 40 by, Mar 24 2016

The rationale for not enabling was that in the original implementation it was an irreversible change - once we discarded the unused transportchannels, we couldn't bring them back to life. (IOW, if pranswer had BUNDLE, but the answer didn't, it would fail).

Do you see an easy way to deal with this?
Project Member

Comment 41 by, Mar 24 2016

Summary: pranswer with BUNDLE doesn't enable bundling (was: DTLS use_rtp extension and pranswer)
It seems like we should start bundling on the transport suggested by the pranswer, but keep around the other transport channels just in case a new pranswer or answer decides to bundle on a different transport. From an implementation perspective this wouldn't be too complex. Are there any problems you can think of from an API perspective? 
Project Member

Comment 42 by, Nov 3 2016

Components: SpecConformance>WebRTC-1_0
Project Member

Comment 43 by, Nov 3 2016

Components: SpecConformance
Project Member

Comment 44 by, Nov 12 2016

Just to note, there's some talk about removing pranswer from the spec. So we may want to hold off on any major work to make pranswer work better.
And in case pranswer will be removed how you can handle the early media ?

Kind regards,

Strictly speaking, 'pranswer' and 'answer' are just variations on each other, catering largely for traditional telephony integration. If you use 'pranswer', 'answer' is really adding little more than a timestamp to say that 'this is where I want to start billing'

Because of this bug#3349 (and several others which prevent 'pranswer' from working reliably), for the past year I have replaced 'pranswer' with 'answer' and when the traditional 'answer' occurs, I simply record a state-change in my application. I am fairly sure this will apply to 99% of applications that use 'pranswer'

If you have a case where this workaround does not apply, I would be interested to hear it in case it affects me later on :)

On our webrtc fork we fixed this bug and we have integration with PSTN working fine with pranswer. No matter what solution is picked we are fine as time the protocol will allow to make a difference between early media and actually call answer without everyone implementing their own strategies that will lead in a mess. 

Project Member

Comment 48 by, Nov 14 2016

The reasoning is that anything you can do with pranswer, you can also do with the RTCRtpTransceiver and RTCRtpSender APIs. RtpSender will let you start/stop sending different tracks without renegotiation. Example:

This is slightly different than the use case you gave, though. In this example, the early warmup is done to give time for GetUserMedia. But in your example, it's done to give time for the call to be accepted, which requires signaling.

Here's a link to discussion thread I was referring to:

Comment 49 by, Nov 15 2016

@silviu did you contribute the patch back upstream?

Do you have any forecast date for the fix?

Sign in to add a comment