Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Oct 2013 12:16:24 +0000

Hi,

Any comments on this issue? I'd like to have some e-mail discussions before Vancouver.

I'd also like it to be listed as an issue - unless, of course, I have missed something, and it really isn't an issue :)

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 30. syyskuuta 2013 11:08
To: [email-masked]
Subject: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections

Hi,

JSEP talks about the usage of multiple PeerConnection to support forking, i.e. for each new forked leg (SIP: early dialog) a new PeerConnection is created.

As has been indicated, as each new PeerConnection will have its own set of address properties, ICE properties etc, so a new Offer will have to be created and sent to inform the remote about the new properties.

So far so I good.

I also assume that the same camera/mic/etc sources are connection to each PeerConnection, so the number of m- lines in the Offer of the new PeerConnection should be the same.

However, according the 3264, the ORDER of the m- lines also need to be kept the same.

So, my question is: how can I ensure that the order of the m- lines in an Offer for a new PeerConnection is the same as in an Offer for an old PeerConnection?

Regards,

Christer

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 18 Oct 2013 01:06:02 +0000

Perhaps in the parallel forking section, we should replace UPDATE with "INVITE with replaces" . Would that work ?

Alternatively we could just remove the parallel forking section. 

On Oct 16, 2013, at 5:16 AM, Christer Holmberg <[email-masked]> wrote:

> Hi,
>  
> Any comments on this issue? I’d like to have some e-mail discussions before Vancouver.
>  
> I’d also like it to be listed as an issue – unless, of course, I have missed something, and it really isn’t an issue :)
>  
> Regards,
>  
> Christer
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 17 Oct 2013 18:15:59 -0700

Hi Christer,

One idea is to pass the Peer Connection Object to be forked as input to the
Fork API when creating the new Peer Connection.

This way the implementation knows that the order of m=lines must   be
matched to the ones in the passed in reference peer connection object ..

Any thoughts ??

Thanks
Suhas

On Mon, Sep 30, 2013 at 1:07 AM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,****
>
> ** **
>
> JSEP talks about the usage of multiple PeerConnection to support forking,
> i.e. for each new forked leg (SIP: early dialog) a new PeerConnection is
> created.****
>
> ** **
>
> As has been indicated, as each new PeerConnection will have its own set of
> address properties, ICE properties etc, so a new Offer will have to be
> created and sent to inform the remote about the new properties.****
>
> ** **
>
> So far so I good.****
>
> ** **
>
> I also assume that the same camera/mic/etc sources are connection to each
> PeerConnection, so the number of m- lines in the Offer of the new
> PeerConnection should be the same.****
>
> ** **
>
> However, according the 3264, the *ORDER of the m- lines* also need to be
> kept the same.****
>
> ** **
>
> So, my question is: how can I ensure that the order of the m- lines in an
> Offer for a new PeerConnection is the same as in an Offer for an old
> PeerConnection?****
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Oct 2013 04:59:22 +0000

Hi Suhas,

Yes, there are a number of ways how it could be done. And, I'm not asking for a solution at this point, simply that we identify it as an issue that needs to be solved :)

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Suhas Nandakumar <[email-masked]> wrote:

Hi Christer,

One idea is to pass the Peer Connection Object to be forked as input to the Fork API when creating the new Peer Connection.

This way the implementation knows that the order of m=lines must   be matched to the ones in the passed in reference peer connection object ..

Any thoughts ??

Thanks
Suhas

On Mon, Sep 30, 2013 at 1:07 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

So far so I good.

Regards,

Christer

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Oct 2013 04:59:21 +0000

Hi Cullen,

My question is how it would be done when creating the new PC, so I don't think replacing UPDATE with REPLACE would solve the problem :)

Also, the usage of a new PC can also be used for serial forking. But, that is not the issue.

Regards,

Christer

"Cullen Jennings (fluffy)" <[email-masked]> wrote:

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Oct 2013 05:01:39 +0000

Replacing UPDATE with INVITE, that is...

Christer Holmberg <[email-masked]> wrote:

Hi Cullen,

Regards,

Christer

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 18 Oct 2013 15:48:13 +0000

By Invite with replaces, I mean an INVITE in new SIP dialog that uses the replaces header ( http://www.ietf.org/rfc/rfc3891.txt ) with the context of the old SIP dialog. That is supported and used for lots of cases by PBX that act as B2BUA because it becomes and effective way to do things like totally change the number m-lines. 

Well, when creating a new Offer to use with invite with replaces, the number of m lines don't have to match at all. You are not even required to have the same media types. So it seems like that would do it.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Oct 2013 18:03:31 +0000

Hi,

> By Invite with replaces, I mean an INVITE in new SIP dialog that uses the replaces header ( http://www.ietf.org/rfc/rfc3891.txt ) with the context of the old SIP dialog. 
> That is supported and used for lots of cases by PBX that act as B2BUA because it becomes and effective way to do things like totally change the number m-lines. 
>

True, but I don't think one should have to do that.

The initial Offer, sent by PC#1, has reached remote entities R_1 and R_2, and both have sent an Answer. For R_2 I now want to create a new PC, PC#2, and send a new Offer with the address properties of PC#2. 

Regards,

Christer

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 18 Oct 2013 18:14:51 +0000

> The initial Offer, sent by PC#1, has reached remote entities R_1 and R_2, and both have sent an Answer. For R_2 I now want to create a new PC, PC#2, and send a new Offer with the address properties…

Yah, I understand - that solution is basically the cloning proposal.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Oct 2013 18:28:35 +0000

Hi,

> Yah, I understand - that solution is basically the cloning proposal. 

No, because I would get NEW address properties.

But, the order of the m- lines (and the media sources etc they represent), and any property that 3264 does not allow to be changed, would have to be the same.

Regards,

Christer

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 18 Oct 2013 19:11:46 +0000

On Oct 17, 2013, at 10:59 PM, Christer Holmberg <[email-masked]> wrote:

> And, I'm not asking for a solution at this point, simply that we identify it as an issue that needs to be solved :)
> 
> 

So I sort of disagree on two points here. 

I disagree that it needs to be solved - I'm not against solving it if anyone has an easy way but every time we talk about this the conclusions comes up people don't want to bother to fully solve the parallel forking problem in the first version of the webrtc. Speaking purely for myself, SIP parallel forking has not turned out to be extremely useful and has turned out to seriously complicate the use and extensions to the protocol - basically the HERFP problem - so I don't really care if webrtc takes on that problem or not. 

Second, I suspect that Invite with replaces actually does solve this. 

I certainly don't mind marking it as an issue but it's not clear to me that the WG thinks it is an issue that needs to be solved or that it an issue that is not solved. I've sort of been waiting to see the other "easy" stuff in JSEP / Bundle / Unified plan get sorted out and then figured we could go back and see what was possible or not with parallel forking in SIP.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Oct 2013 19:34:45 +0000

Hi,

Again, it is not specific to parallel forking - it is also needed for SERIAL forking, in cases where you need to send updated Offers on early dialogs, and therefore cannot use PRANSWER.

As far as the solution is concerned: on a high level, whenever you create a new PC (or, when you add the media streams to it), you need to be able to indicate the order of the m- lines. Whether it is done explicitly, or implicitly e.g. by somehow referencing the old PC, I don't know, but I don't think it should be very difficult.

Regards,

Christer

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 18 Oct 2013 19:42:04 +0000

> Again, it is not specific to parallel forking - it is also needed for SERIAL forking, in cases where you need to send updated Offers on early dialogs, and therefore cannot use PRANSWER.

I don't think I agree on that but I really want to spend my time on making sure we get the setLocal / setRemote text working for the simple case before we sort all this out.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Oct 2013 20:38:14 +0000

Hi,

> I don't think I agree on that but I really want to spend my time on making sure we get the setLocal / setRemote text working for the simple case before we sort all this out. 

This is how I understand it would work when discussing with Vijaya .

Now, if you don't agree, please then explain how you would implement the forking case I provided :)

Regards,

Christer

---

From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <[email-masked]>
Date: Sun, 20 Oct 2013 07:22:25 +0000

Hi Cullen,

I fully agree with Christer for PRANSWER state usage in serial forking. Sec 5.2 of draft-partha-rtcweb-jsep-sip-00 explains the callflow wherein PRANSWER state is not possible to be used in serial forking.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Christer Holmberg
Sent: Saturday, October 19, 2013 2:08 AM
To: Cullen Jennings (fluffy)
Cc: [email-masked]
Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections

Hi,

Regards,

Christer

---

From: "Vijaya Mandava (vimandav)" <[email-masked]>
Date: Mon, 21 Oct 2013 19:31:42 +0000

Hi Christer,
I agree that parallel  and serial forking call flows can be solved with multiple PeerConnection model.

But going back to the original question you had -
>>> So, my question is: how can I ensure that the order of the m- lines in an Offer for a new PeerConnection is the same as in an Offer for an old PeerConnection?

The Jsep doc 4.1.4 setLocalDescription already implies that a new PeerConenction would use/support the old local description, and reading it, assumption is that the old description m-line ordering would not be changed.
It definitely didn't mention that we would send entirely new SDP on the new PeerConnection created…

We can call for clarification in the Jsep doc, but definitely not a issue as far as I see.

Thanks,
Vijaya

On 10/18/13 4:38 PM, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: Cullen Jennings (fluffy) [mailto:[email-masked]]
Lähetetty: 18. lokakuuta 2013 22:12
Vastaanottaja: Christer Holmberg
Kopio: Suhas Nandakumar; [email-masked]<mailto:[email-masked]>
Aihe: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections
On Oct 17, 2013, at 10:59 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Oct 2013 20:16:35 +0000

Hi Vijaya,

> The Jsep doc 4.1.4 setLocalDescription already implies that a new PeerConenction would use/support the old local description, and reading it, assumption is that the old description m-line ordering…

My understanding (please correct me if I'm wrong) is that you have to call createOffer before you call setLocalDescription, so it would be useful to get the right order already when calling createOffer.

> It definitely didn't mention that we would send entirely new SDP on the new PeerConnection created…

Well, it depends on what you mean with "entirely new". At least the address/candidate information would be new, as the new PeerConnections can't share the address/candidates with the old one.

Regards,

Christer

Hi,

Regards,

Christer