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

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. 

On Oct 17, 2013, at 10:59 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

> 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
> 
> Sent from my Sony Ericsson Xperia arc S
> 
> "Cullen Jennings (fluffy)" <fluffy@cisco.com> wrote:
> 
> 
> 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 <christer.holmberg@ericsson.com> 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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
>> Sent: 30. syyskuuta 2013 11:08
>> To: rtcweb@ietf.org
>> 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
>> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb