Subject: [rtcweb] JSEP Walk Through on Wednesday the 18th of September at 17.00 CEST (8 AM PDT)

From: Magnus Westerlund <[email-masked]>
Date: Wed, 11 Sep 2013 07:58:59 +0200

WG,

There will be a new version of JSEP draft coming out Monday. As a follow
up to get as much progress on this topic as possible. The chairs and
authors are offering a informal walk through session on Wednesday the
18th. People will be strongly recommended to have reviewed the new draft.

The intention of the session is enable the authors to inform you about
the latest changes, any issues to consider and what needs further
discussion. The will also enable you as participant after your review of
the document to ask clarifying questions or for motivations behind
choices, and raise issues you have spotted.

The session is not intended to solve issues or judge consensus on part
of the draft. Discussions of what is the best solution etc, will to be
cut off.

This will be a webex conference per details below.

Cheers

Magnus Westerlund

Topic: RTCWeb - JSEP
Date: Wednesday, September 18, 2013
Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
Meeting Number: 302 061 238
Meeting Password: ietf

-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to
https://cisco.webex.com/ciscosales/j.php?ED=206400898&UID=0&PW=NYjk4NmE0ODBj&RT=MiM0

2. Enter your name and email address.
3. Enter the meeting password: ietf
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://cisco.webex.com/ciscosales/j.php?ED=206400898&UID=0&PW=NYjk4NmE0ODBj&ORT=MiM0

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or
Access Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

----------------------------------------------------------------
ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE
(408) OR (919) AREA CODES
----------------------------------------------------------------
Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

Dialing the WebEx toll free numbers from within 408 or 919 area codes is
not enabled (non-Cisco phones). “ If you dial the toll-free numbers
within the 408 or 919 area codes you will be instructed to hang up and
dial the local access number.” Please use the call-back option whenever
possible and otherwise dial local numbers only. The affected toll free
numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866)
349-3520 for the RTP area.

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Sep 2013 10:38:06 +0200

WG,

I know that the new JSEP Draft is not yet submitted. I am hoping that it
will show up during the morning hours for the US based people. That way
everyone gets at least some few hours to look at the draft prior to the
call. If it hasn't we will postpone the call, but I really hope we can
avoid this. I will send a notice to the WG if we have to postpone it.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Sep 2013 10:47:50 +0200

Magnus,

what is the expected duration of the call?

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Sep 2013 10:51:08 +0200

> what is the expected duration of the call?

2 hour maximum

Magnus

-- 

Magnus Westerlund

---

From: Justin Uberti <[email-masked]>
Date: Tue, 17 Sep 2013 15:29:05 -0700

The draft has now been posted at
http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-04.txt, with 13
new pages of text.

Readers should focus on Section 5, which specifies the behavior of
createOffer/createAnswer, as well as Appendix A.2, which provides examples
of the generated SDP.

On Tue, Sep 17, 2013 at 1:51 AM, Magnus Westerlund <
[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Sep 2013 10:50:13 +0000

Hi,

I may not be able to attend the phone meeting today, so I send my input by the e-mail.

As requested by the WG chairs, I’ll focus on clarification issues/questions, and will for now not repeat the issues I have with pranswer and forking (also, we may have found a way forward to solve that).

Q_1:      Meaning of “session”:

When the document talks about “session”, I think it needs to be more clear that the scope of a session is a PeerConnection.

For example, as described in section 3.5, in the case of forking there might be multiple PeerConnections, each forming different “sessions” – eventhough they will all be part of e.g. the same higher-level SIP session.

Similar, when the text talks about “initial Offer”, it needs to be clear that it refers to a given PeerConnection.

Q_2:      Forking

I would suggest some re-wording (I am willing to provide text) of the forking sections. At least the following I want more clear:

1.       Similar to parallel forking, sequential forking can also be implemented using multiple PeerConnections.

2.       When a new PeerConnection is created, it will have different address properties than the “mother” PeerConnection, so a new Offer needs to be created immediately, in order to inform the remote peer about those properties. The draft DOES say that the same local media streams are added to the new PeerConnection, but it does not make it clear that the new PeerConnection will have different address properties, and possibly also other properties that vary. The draft also DOES talk about the “UPDATE approach”, but that is very unclear (see Q_3).

3.       Parallel forking does not necessarily mean you receive media simultaneously from multiple endpoints. You might establish a media connection (e.g. using SIP preconditions) with multiple endpoints, but that does not mean you will receive media from all of them at the same time. I can provide some 3GPP call flows that show examples of that.

Q_3:      UPDATE approach

I don’t understand the text talking about the “UPDATE approach” and “UPDATE strategy”, referring to RFC 3960. With my SIP background, I kind of understand what you’re thinking is, but I think non-SIP people will have very difficult to understand exactly what you mean. I think it is much better to simply say that, for the new PeerConnection, an Offer needs to be sent (see Q_2).

Q_4:      Appendix A.2.

As the example contains BUNDLE, I would also like to see “2nd Offer” (with identical port numbers), for completeness.

Q_5:      Appendix Forking

I would like to see some examples with forking.

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 18. syyskuuta 2013 1:29
To: Magnus Westerlund
Cc: [email-masked]
Subject: Re: [rtcweb] JSEP Walk Through on Wednesday the 18th of September at 17.00 CEST (8 AM PDT)

The draft has now been posted at http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-04.txt, with 13 new pages of text.

Readers should focus on Section 5, which specifies the behavior of createOffer/createAnswer, as well as Appendix A.2, which provides examples of the generated SDP.

On Tue, Sep 17, 2013 at 1:51 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:
2 hour maximum

Magnus

>>> San Jose, CA: +1.408.525.6800<tel:%2B1.408.525.6800> RTP: +1.919.392.3330<tel:%2B1.919.392.3330>
>>>
>>> US/Canada: +1.866.432.9903<tel:%2B1.866.432.9903> United Kingdom: +44.20.8824.0117<tel:%2B44.20.8824.0117>
>>>
>>> India: +91.80.4350.1111<tel:%2B91.80.4350.1111> Germany: +49.619.6773.9002<tel:%2B49.619.6773.9002>
>>>
>>> Japan: +81.3.5763.9394<tel:%2B81.3.5763.9394> China: +86.10.8515.5666<tel:%2B86.10.8515.5666>
>>>
>>>

--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287<tel:%2B46%2010%207148287>
Färögatan 6                | Mobile +46 73 0949079<tel:%2B46%2073%200949079>
SE-164 80 Stockholm, Sweden| mailto: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 18 Sep 2013 13:45:58 +0200 (CEST)

> Readers should focus on Section 5, which specifies the behavior of createOffer/createAnswer, as well as Appendix A.2, which provides examples of the generated SDP.

I have a question about the OfferToReceiveAudio / OfferToReceiveVideo
sections (5.2.3.1& 5.2.3.2)...

In createAnswer (I'd note that both section currently only talk about the
offerer), what is the expected behaviour when those constraints
are set to false and a MediaStreamTrack of the respective type has been
attached to the peerconnection?

Is the behaviour different when there is no MST of a certain type attached?

Does this only affect the direction attribute or also whether the m-line 
is rejected by setting the port to zero?

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 18 Sep 2013 05:21:32 -0700

I think we should include RFC5104 referenced in the sections corresponding
to RTCP feedback

Thanks
Suhas

On Tuesday, September 17, 2013, Justin Uberti wrote:

> http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-04.txt, with
> 13 new pages of text.
>
> >>> India: +91

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Sep 2013 14:47:37 +0200

On 2013-09-18 12:50, Christer Holmberg wrote:
> As requested by the WG chairs, I’ll focus on *clarification
> issues/questions*, and will for now not repeat the issues I have with
> pranswer and forking (also, we may have found a way forward to solve that).

A point of clarification.

In the phone conference we will focus getting understanding for JSEP for
the participants so that you all can provide comments, feedback and
bring proposals for improvements.

It is also okay to ask about technical issues. But in the interest of
time I think we need to focus on exposing and understanding potential
issues, not solving them.

All type of issues are fine to contribute on the list and towards the
authors. However, I would recommend to use another thread than this one.
Create a new thread or follow up on the I-D announcement for the version
you are commenting on.

Cheers

Magnus Westerlund

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Sep 2013 12:54:08 +0000

Hi,

Based on some private discussions with Cullen and Justin, I think there is a way forward regarding pranswer and forking.

Some of those ideas are already presented in the draft (using separate PeerConnections for each forked leg etc). But, there are details that need to be sorted out, and I don't think this meeting is appropriate to discuss those - especially when I may not even be able to attend :)

Regards,

Christer

-----Original Message-----
From: Magnus Westerlund 
Sent: 18. syyskuuta 2013 15:48
To: Christer Holmberg
Cc: Justin Uberti; [email-masked]
Subject: Re: [rtcweb] JSEP Walk Through on Wednesday the 18th of September at 17.00 CEST (8 AM PDT)

In the phone conference we will focus getting understanding for JSEP for the participants so that you all can provide comments, feedback and bring proposals for improvements.

It is also okay to ask about technical issues. But in the interest of time I think we need to focus on exposing and understanding potential issues, not solving them.

All type of issues are fine to contribute on the list and towards the authors. However, I would recommend to use another thread than this one.
Create a new thread or follow up on the I-D announcement for the version you are commenting on.

Cheers

Magnus Westerlund