Re: [rtcweb] Reg retransmissions using JSEP approach.

kiran kumar <g.kiranreddy4u@gmail.com> Mon, 11 June 2012 04:29 UTC

Return-Path: <g.kiranreddy4u@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE39621F84A6 for <rtcweb@ietfa.amsl.com>; Sun, 10 Jun 2012 21:29:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baVPE7TVx-o3 for <rtcweb@ietfa.amsl.com>; Sun, 10 Jun 2012 21:29:57 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 330CA21F8494 for <rtcweb@ietf.org>; Sun, 10 Jun 2012 21:29:57 -0700 (PDT)
Received: by obbeh20 with SMTP id eh20so8679442obb.31 for <rtcweb@ietf.org>; Sun, 10 Jun 2012 21:29:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=F+ItfZ9b9tqKgwrl9ucokToom5VAgCE5TmzxT2HLrQQ=; b=UlLMnXD7Aj8xj6PI2Y084Fmxo+hI6CT3kMuEFmoh80HvDLdvYO8HbvorrCQbbFhJCG OVOyCFZ/ewAheoBPdNmBOKkwPFkWBx14c13mxGQhpppP2JRAYyY52kHgIX5G9KS9RbUk 7ZaAp0GZJILI4uKoiv0fk6LxZ7FUy2AaFdEqRRhygkWd3CPzkPHuKKQoMFMQeZaKglzc jwXiogv7mG28MNvXT8qwfksLs38lFA5lr0h79htKDkmCmUTS5+RxwbCwwYOU0r15X6No UILQKVnE6EBjuPq+6ElKhVGnlrgnPB3UT1JwySxwGu0jsg1x6BqGqi2rRsrPLb3GVv5a qEPA==
Received: by 10.50.209.73 with SMTP id mk9mr5530063igc.66.1339388996662; Sun, 10 Jun 2012 21:29:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.135.5 with HTTP; Sun, 10 Jun 2012 21:29:36 -0700 (PDT)
In-Reply-To: <13D57612-5ADF-4B23-B7A4-81B212D49C66@iii.ca>
References: <CAGW1TF5mSM=OFaFJE9JQBrYCYRV7Ur=RrZhV5XDbxf3F_Tdd_Q@mail.gmail.com> <13D57612-5ADF-4B23-B7A4-81B212D49C66@iii.ca>
From: kiran kumar <g.kiranreddy4u@gmail.com>
Date: Mon, 11 Jun 2012 09:59:36 +0530
Message-ID: <CAGW1TF5RZSEuF_KW6SecU7eVm7FDTOzfDxgUVB8vuZXDo307gg@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Content-Type: multipart/alternative; boundary="14dae93407d75cb7c804c22acd1a"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Reg retransmissions using JSEP approach.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jun 2012 04:29:58 -0000

Thanks for your quick respnse,

Thanks,
Kiran.

On Sun, Jun 10, 2012 at 7:51 PM, Cullen Jennings <fluffy@iii.ca> wrote:

>
> On Jun 9, 2012, at 7:26 , kiran kumar wrote:
>
> > Hi all,
> >
> > I am new to this list, so please don't mind if I am repeating the same
> question, if it has already discussed in this list.
> >
> > My doubt is regarding how JSEP style of implementation will
> differentiate the retransmission of messges with out ROAP.
> >
> > According to few mails and discussion lists, It is specified that ROAP
> is going to be replaced by JSEP.
> > But in updated JSEP draft an example with ROAP is also provided.
> >
> > If ROAP is going to be replaced by JSEP, which part of JSEP will
> differentiate the retransmitted offers.
> > ROAP is having "seq" field to differentiate it.
> > Is that part going to be completely left to the application protocol ?
> >
>
> Yes, I think the idea i the application would have to deal with that. It
> probably needs to keep track of the keeping between the offer / answers to
> the seq number too so that if an offer is rejected and it rolls back to reg
> previous offer, it has that offer so it can roll back. At the same time
> browser implementation  also need to keep track of the various offers so
> they can roll back. More text is needed in the drafts on all this.
>
>