Re: [rtcweb] RTCweb signalling overview

Yes, federated SIP certainly has the problems that VIPR is intended to
solve.  And, of course, without VIPR or without SPs supporting Federations
and/or ENUM, the only choice is to interwork via the PSTN.  However, given
that there are multiple solutions for SIP based federation, it makes sense
to not reinvent the wheel and trying to suggest that you only need a subset
of SIP for this interface is a slipperly slope as has already been
suggested. And, of course, using SIP as is on this interface facilitates
interworking in cases where the Web Server is interfacing to a "legacy" SIP
Server.  As an aside, I think it's silly to refer to the SIP protocol
developed by the IETF as "legacy".   I don't think the intent of RTCWEB is
to marginalize SIP.   As Keith suggests, it may be that some additional
information needs to be passed over that interface to support RTCWEB, but I
would hope that would not require core SIP changes.

Mary.

On Fri, Sep 9, 2011 at 8:25 AM, Muthu Arul Mozhi Perumal (mperumal) <
mperumal@cisco.com> wrote:

>  |Perhaps the easiest way out is to identify that full ****
>
> |blow SIP is a solution for this specific interface, ****
>
> |and RTCWEB identifies to SIPCORE as to whether there ****
>
> |are any additional requirements that SIP cannot meet.****
>
> ** **
>
> Doesn't this federated SIP suffer from the same problems VIPR is trying to
> solve? Of course, the alternative is to choose SIP trunk providers and go
> through SBCs and PSTN -:)****
>
> ** **
>
> Muthu****
>
> ** **
>
> *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On
> Behalf Of *DRAGE, Keith (Keith)
> *Sent:* Friday, September 09, 2011 6:39 PM
> *To:* Harald Alvestrand; rtcweb@ietf.org
>
> *Subject:* Re: [rtcweb] RTCweb signalling overview****
>
>  ** **
>
> With respect to question 3 in this set.****
>
> ** **
>
> As I said on the call, the requirements for what needs to be standardised
> between the two web servers depends on whether web server A needs to know
> anything about user B, and whether web server B needs to know anything about
> user A. I believe this goes beyond SDP, because it may need to be
> information beyond the media contents, e.g. it may need to include
> information about each user’s capabilities and preferences.****
>
> ** **
>
> I actually have two slightly inconsistent views about this interface.****
>
> ** **
>
> Yes it does need to be standardised. I don’t like the idea of fragmentation
> being forced on the market because an appropriate standardised solution has
> not been identified. ****
>
> ** **
>
> No RTCWEB should not standardise it because it is out of scope of RTCWEB.*
> ***
>
> ** **
>
> Surely this is also the interface by which support of interworking with
> legacy systems has to be attained?****
>
> ** **
>
> Perhaps the easiest way out is to identify that full blow SIP is a solution
> for this specific interface, and RTCWEB identifies to SIPCORE as to whether
> there are any additional requirements that SIP cannot meet.****
>
> ** **
>
> Regards****
>
> ** **
>
> Keith****
>
> ** **
>
> ** **
>
> ** **
>   ------------------------------
>
> *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On
> Behalf Of *Harald Alvestrand
> *Sent:* 09 September 2011 08:26
> *To:* rtcweb@ietf.org
> *Subject:* Re: [rtcweb] RTCweb signalling overview****
>
> ** **
>
> On 09/08/11 20:48, Olle E. Johansson wrote: ****
>
> For those of you that did not participate in today's meeting, there was an
> excellent overview presented by Martin Kaufman. ****
>
> ** **
>
> It gives you an overview over the issues with signalling - to sip or not to
> sip - and other issues. Do read it.****
>
> ** **
>
> Use the file rtcweb-3.pptx<http://www.ietf.org/proceedings/82/slides/rtcweb-3.pptx>
>  in http://www.ietf.org/proceedings/82/slides/****
>
>
> Seconded.
> I liked the presentation even though I don't agree with the conclusions (I
> prefer Cullen's set).
> **
> ******
>
> ** **
>
> /O****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> _______________________________________________****
>
> rtcweb mailing list****
>
> rtcweb@ietf.org****
>
> https://www.ietf.org/mailman/listinfo/rtcweb****
>
> ** **
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>