Return-Path: 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 4B69A11E8095 for ; Fri, 21 Oct 2011 11:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 9s-XufVlsJtZ for ; Fri, 21 Oct 2011 11:12:09 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B82C511E8082 for ; Fri, 21 Oct 2011 11:12:09 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4300461vcb.31 for ; Fri, 21 Oct 2011 11:12:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.117.81 with SMTP id p17mr1109243vcq.41.1319220729248; Fri, 21 Oct 2011 11:12:09 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 21 Oct 2011 11:12:09 -0700 (PDT) In-Reply-To: <5E920713-0B41-493D-9457-7FE48DB6A98D@skype.net> References: <5E920713-0B41-493D-9457-7FE48DB6A98D@skype.net> Date: Fri, 21 Oct 2011 20:12:09 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Matthew Kaufman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [rtcweb] Does ROAP mandate the on-the-wire format? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 18:12:10 -0000 2011/10/21 Matthew Kaufman : > If you can do this as easily as it sounds above, and it supports both ear= ly media and forking, then I think we've put far too much into the browser = logic. So this is actually a good test of the design. > > For a browser, there should be no such thing as early media... Just media= . As Hadriel has pointed out, in SIP early media is just a *normal* media session but without a confirmed INVITE transaction (not a final response yet, but just 180/183 with SDP). So there is no problem in implementing early media in the browser. > And for a browser, there should be no such thing as forking, Why not? my current implementation can receive different SIP 180/183 with different To-tags, which means "forking". Regards. --=20 I=C3=B1aki Baz Castillo