Subject: [rtcweb] RTCweb signalling overview

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 8 Sep 2011 20:48:45 +0200

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 in http://www.ietf.org/proceedings/82/slides/

/O

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 09 Sep 2011 09:25:38 +0200

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 9 Sep 2011 15:08:46 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 09 September 2011 08:26
To: [email-masked]
Subject: Re: [rtcweb] RTCweb signalling overview

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

[email-masked]<mailto:[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 9 Sep 2011 15:24:21 +0200

9 sep 2011 kl. 15:08 skrev DRAGE, Keith (Keith):

> 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.
>  
How good it feels to not be alone and confused :-)

>  
> 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.
Exactly.
> No RTCWEB should not standardise it because it is out of scope of RTCWEB.
Yes, agree.

> Surely this is also the interface by which support of interworking with legacy systems has to be attained?
Well, if the app developer wants to interface legacy systems. The important thing for rtcweb is to understand whether access to legacy systems affects the rtcweb architecture if the signalling is removed from scope.

> 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 SI…
In addition, I see XMPP to be a solution for that specific interface too... 

/O
> I liked the presentation even though I don't agree with the conclusions (I prefer Cullen's set).

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 9 Sep 2011 18:55:19 +0530

|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: [email-masked] [mailto:[email-masked]] On Behalf
Of DRAGE, Keith (Keith)
Sent: Friday, September 09, 2011 6:39 PM
To: Harald Alvestrand; [email-masked]
Subject: Re: [rtcweb] RTCweb signalling overview

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.

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Harald Alvestrand
Sent: 09 September 2011 08:26
To: [email-masked]
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.

Seconded.

/O

---

From: Mary Barnes <[email-masked]>
Date: Fri, 9 Sep 2011 10:52:23 -0500

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) <
[email-masked]> 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:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *DRAGE, Keith (Keith)
> *Sent:* Friday, September 09, 2011 6:39 PM
> *To:* Harald Alvestrand; [email-masked]
>
> *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.*
> ***
>
> ** **
>
> 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:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Harald Alvestrand
> *Sent:* 09 September 2011 08:26
> *To:* [email-masked]
> *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.
> **
> ******
> ** **
> /O****
> ** **
> ** **
> ** **
> ** **
> _______________________________________________****
>
> rtcweb mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/rtcweb****
>
> ** **
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 11 Sep 2011 16:01:55 +0000

Was the meeting audio recorded?  It would be nice to listen to the discussion. :)

-hadriel