New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 26 users
Status: Assigned
Owner:
Cc:
Components:
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment
pranswer with BUNDLE doesn't enable bundling
Reported by flavioba...@gmail.com, May 14 2014 Back to list
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.

setRemoteDescription:
type: pranswer, sdp: v=0
o=ZTE 8992120731499920000 1088450255 IN IP4 10.139.246.98
s=phone-call
c=IN IP4 10.139.246.98
t=0 0
m=audio 20000 RTP/SAVPF 8
c=IN IP4 10.139.246.98
a=rtcp:20000 IN IP4 10.139.246.98
a=sendrecv
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-10.139.246.119-6228-1400077677919
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=ice-pwd:1hc6vdu1olehl50c24ioef3s1a
a=rtpmap:8 PCMA/8000
a=ice-ufrag:7i2cj
a=setup:active
a=rtcp-mux
a=candidate:dc894 1 udp 2130706431 10.139.246.98 20000 typ host
a=candidate:dc895 2 udp 2130706431 10.139.246.98 20000 typ host


 
3d9c0ebd-9737-4fa5-b5d2-e6e42f5a9035.dump
69.4 KB Download
3d9c0ebd-9737-4fa5-b5d2-e6e42f5a9035.pcapng
1.4 KB Download
Project Member Comment 1 by braveyao@webrtc.org, May 15 2014
Cc: juberti@webrtc.org braveyao@webrtc.org vikasmarwaha@webrtc.org
Owner: jiayl@webrtc.org
@jiay, please help to comment on this.
Project Member Comment 2 by juberti@webrtc.org, May 15 2014
We probably don't set up the DTLS adapter properly on a PRANSWER.


Comment 3 by jiayl@chromium.org, May 19 2014
For PRANSWER, WebRtcSession does not call BaseSession::MaybeEnableMuxingSupport, which triggers pushing the ciphers down to DtlsTransportChannlWrapper if it's an ANSWER.

Justin,

is not calling BaseSession::MaybeEnableMuxingSupport for PRANSWER intentional? Why?
Project Member Comment 4 by jiayl@webrtc.org, May 19 2014
Cc: mallinath@webrtc.org
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 jiayl@webrtc.org, 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 jiayl@webrtc.org, May 27 2014
Owner: juberti@webrtc.org
Project Member Comment 8 by jiayl@webrtc.org, Jul 7 2014
 Issue 3530  has been merged into this issue.
Comment 9 by vrk@webrtc.org, Oct 14 2014
Labels: Area-Network
any news on this issue?
Comment 11 by vrk@webrtc.org, 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 vrk@webrtc.org, Nov 3 2014
Owner: jiayl@webrtc.org
Status: Assigned
Project Member Comment 13 by braveyao@webrtc.org, Nov 7 2014
Cc: jiayl@webrtc.org
 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 jbauch@webrtc.org, Jul 17 2015
 Issue 4837  has been merged into this issue.
Project Member Comment 16 by jansson@webrtc.org, Aug 28 2015
Cc: -mallinath@webrtc.org
Ping, jiayl@ do you have cycles to fix this soonish? If so, could you add a milestone label?
Project Member Comment 17 by jiayl@webrtc.org, Aug 28 2015
Owner: pthatcher@webrtc.org
Project Member Comment 18 by pthatcher@google.com, 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: https://codereview.webrtc.org/1246913005/.

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 pthatcher@google.com, Aug 28 2015
Labels: -IceBox Mstone-47
Project Member Comment 20 by tnakamura@webrtc.org, Sep 1 2015
Cc: tnakamura@webrtc.org jansson@webrtc.org
I was directed here from https://github.com/webrtc/samples/issues/178.

Using today's Chrome Canary (47.0.2498.0):
1) Open https://webrtc.github.io/samples/src/content/peerconnection/pr-answer/
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 pthatcher@google.com, Oct 6 2015
Labels: -EngTriaged
Project Member Comment 23 by pthatcher@webrtc.org, Oct 26 2015
Labels: EngTriaged
Owner: deadbeef@webrtc.org
Taylor, can you figure out where our support for pranswer is?
Project Member Comment 24 by guoweis@webrtc.org, Nov 5 2015
Owner: guoweis@webrtc.org
Since I'm working on this related area, I'm grabbing this bug.
Project Member Comment 25 by guoweis@webrtc.org, Nov 5 2015
Cc: deadbeef@webrtc.org
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 jansson@webrtc.org, 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 jansson@webrtc.org, 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 jbauch@webrtc.org, Dec 21 2015
 Issue 5196  has been merged into this issue.
Project Member Comment 32 by tnakamura@webrtc.org, Dec 28 2015
Cc: -vikasmarwaha@webrtc.org
Labels: -Mstone-48 Mstone-49
Hi,

'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. 
chrome_debug.log
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: 

Thanks,
ganesh
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: https://code.google.com/p/chromium/issues/detail?id=149100

[Working case when early media sdp set as 'answer']
[604:1236:0108/162121:VERBOSE1:opensslstreamadapter.cc(812)]  -- success
[604:1236:0108/162121:INFO:dtlstransportchannel.cc(534)] Jingle:Channel[audio|1|__]: DTLS handshake complete.
[604:1236:0108/162121:VERBOSE1:transportchannel.cc(51)] Jingle:Channel[audio|1|__]: set_dtls_state from:1 to 2
[604:1236:0108/162121:VERBOSE1:transportchannel.cc(38)] Jingle:Channel[audio|1|__]: set_writable from:0 to 1
[604:1236:0108/162121:INFO:transportcontroller.cc(483)] audio TransportChannel 1 writability changed to 1.
[604:1236:0108/162121:INFO:channel.cc(822)] Channel writable (audio) for the first time
[604:1236:0108/162121:INFO:channel.cc(830)] 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/162121:INFO:channel.cc(887)] Installing keys from DTLS-SRTP on audio RTP

[Non-Working case when early media sdp set as 'pranswer']
[3352:1380:0107/203150:INFO:dtlstransportchannel.cc(534)] Jingle:Channel[audio|1|__]: DTLS handshake complete.
[3352:1380:0107/203150:VERBOSE1:transportchannel.cc(51)] Jingle:Channel[audio|1|__]: set_dtls_state from:1 to 2
[3352:1380:0107/203150:VERBOSE1:transportchannel.cc(38)] Jingle:Channel[audio|1|__]: set_writable from:0 to 1
[3352:1380:0107/203150:INFO:transportcontroller.cc(483)] audio TransportChannel 1 writability changed to 1.
[3352:1380:0107/203150:VERBOSE1:opensslstreamadapter.cc(558)] OpenSSLStreamAdapter::Read(2048)
[3352:1380:0107/203150:VERBOSE1:opensslstreamadapter.cc(613)]  -- error want read
Project Member Comment 37 by pthatcher@webrtc.org, Jan 25 2016
Labels: -Mstone-49 Mstone-51
Owner: deadbeef@webrtc.org
Project Member Comment 38 by deadbeef@webrtc.org, Jan 28 2016
Labels: -Mstone-51
Removing milestone, since fixing this isn't a Q1 OKR.
Project Member Comment 39 by deadbeef@webrtc.org, 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 juberti@webrtc.org, 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 deadbeef@webrtc.org, 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 kjellander@webrtc.org, Nov 3 2016
Components: SpecConformance>WebRTC-1_0
Project Member Comment 43 by kjellander@webrtc.org, Nov 3 2016
Components: SpecConformance
Project Member Comment 44 by deadbeef@webrtc.org, 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,
Silviu
Silviu,

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 :)

Regards,
Steve
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. 

Silviu
Project Member Comment 48 by deadbeef@webrtc.org, 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: http://w3c.github.io/webrtc-pc/#simple-peer-to-peer-example-with-warm-up

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: https://mailarchive.ietf.org/arch/msg/rtcweb/fTZs9aW6tWlJpAiKDeIKelxgKDU
Comment 49 by hta@chromium.org, 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