Subject: [rtcweb] Consensus call on JSEP/ROAP

From: Ted Hardie <[email-masked]>
Date: Tue, 7 Feb 2012 12:24:40 -0800

During the interim meeting, the attendees discussed the JSEP and ROAP
proposals.  The chairs also asked the working group to consider
whether they might be successfully merged.  Because of audio difficulties,
there is no recording available.  The jabber logs contain
a transcription of the discussion by Bernard Aboba and can be found
here: http://www.ietf.org/jabber/logs/rtcweb/2012-01-31.html.

At the end of the discussion, the chairs asked the attendees to
indicate their preferences by standing for one of four positions, which were
listed prior to the question being called.  The positions were:

1--Don't care whether ROAP or JSEP is the input document for further
work in this area

2---Prefer ROAP be the input document for further work

3--Prefer JSEP be the input document for further work

4--Prefer to merge the docs, limiting JSEP to RFC 3264 offer/answer semantics.

The results were: 1=9 in room, none in jabber
                             2=11 in room, 2 in jabber
                             3=25 in room, 3 in jabber
                             4=8 in room, none in jabber.

Because JSEP supports more than one model of negotiation, choosing 3
is a reversal  from previous working group consensus to limit work to
the offer/answer model.

The chairs are now calling for consensus of the working group on this
point.  Working group participants who were not present at the interim,
please review the input documents if you not have yet done so, and
forward your comments to the list.  All working group participants are
asked to make
their points on this topic by February 22nd, so that we have timely
input prior to the document deadline for Paris.

thanks,

Ted Hardie for the Chairs

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 21 Feb 2012 10:52:13 -0600

Hi All,
I would like to point out that if you rephrase the question to ask "who prefers to base subsequent work on RFC 3264 semantics?", then you would need to combine positions 2 and 4, and you would get a vote of 28 (the position 3 votes) for a new semantic model (requiring significant new work on SDP) against 21 (the sum of votes for positions 2 and 4) for RFC 3264 semantics.

So while I do not object to using JSEP as a basis for further work, it seems that the group is far less certain about the on-the-wire semantics to be associated with it.  My preference is to focus on RFC 3264 semantics (noting that the low level of the API would still allow considerable flexibility to support other signaling protocols).  My key concern is to have clear rules (based on common semantics) for interworking media/transport negotiation procedures between different on-the-wire protocols to avoid potential interop problems.  

In particular, at this point in the discussion, I do not see the value of allowing multiple open OFFERs within a dialog (which have acknowledged problems), multiple ANSWERs within a dialog, or PRANSWERs, none of which exist in RFC 3264.

I propose that the group first decide whether to use JSEP as a basis for further work and in subsequent step(s) decide whether and how to go beyond RFC 3264 semantics.  I see this proposal as simply a clarification of the meaning of position 3.

Richard Ejzak

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: Tuesday, February 07, 2012 2:25 PM
To: [email-masked]
Subject: [rtcweb] Consensus call on JSEP/ROAP

thanks,

Ted Hardie for the Chairs
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Cary W FitzGerald <[email-masked]>
Date: Tue, 21 Feb 2012 12:13:32 -0800

This is partially inevitable.  For WebRTC applications that interact with SIP gateways, the WebRTC application can't signal anything that 3264 won't allow, since the gateway's side won't be able to deal with it.  The original architecture document http://tools.ietf.org/html/draft-ietf-rtcweb-overview-02 proposes a RTC trapezoid and any well-behaved trapezoid needs to consider the SIP case and therefore 3264.

There is another important case, which is when the trapezoid degenerates into a triangle.  This is the case where the web server controls both sides of the conversation (e.g. connecting to an attendant at www.ftd.com without any intervening PBX/switch/traditional contact center).  Since there is no PSTN GW to contend with, it's not necessary to obey the gateway's rules.  In this case, the server presumably knows what it's doing, so it's probably a bug if it trips itself up.

There is potentially a third case, which is where the trapezoid is maintained, and the servers are communicating with some-protocol-not-SIP that doesn't need to abide by 3264 (which excludes H.323), but are not smart enough to coordinate media between themselves, but this doesn't seem very important.  I could be wrong about that, but I don't see the practical use case.

Cary.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 21 Feb 2012 17:32:15 -0500

Another issue is that real-life SIP deployments are often not RFC 3264
complaint. In particular it is not unusual to receive different SDP in
provisional and final INVITE response. This does not fit offer/answer model
since it implies multiple answers to one offer with subsequent answers
overwriting previous ones. So, offer/answer compliance is insufficient even
for the SIP interop.
_____________
Roman Shpount

On Tue, Feb 21, 2012 at 3:13 PM, Cary W FitzGerald
<[email-masked]>wrote:

> This is partially inevitable.  For WebRTC applications that interact with
> SIP gateways, the WebRTC application can't signal anything that 3264 won't
> allow, since the gateway's side won't be able to deal with it.  The
> original architecture document
> http://tools.ietf.org/html/draft-ietf-rtcweb-overview-02 proposes a RTC
> trapezoid and any well-behaved trapezoid needs to consider the SIP case and
> therefore 3264.
>
> There is another important case, which is when the trapezoid degenerates
> into a triangle.  This is the case where the web server controls both sides
> of the conversation (e.g. connecting to an attendant at www.ftd.comwithout any intervening PBX/switch/traditional contact center).  Since
> there is no PSTN GW to contend with, it's not necessary to obey the
> gateway's rules.  In this case, the server presumably knows what it's
> doing, so it's probably a bug if it trips itself up.
>
> There is potentially a third case, which is where the trapezoid is
> maintained, and the servers are communicating with some-protocol-not-SIP
> that doesn't need to abide by 3264 (which excludes H.323), but are not
> smart enough to coordinate media between themselves, but this doesn't seem
> very important.  I could be wrong about that, but I don't see the practical
> use case.
>
> Cary.
>
> I would like to point out that if you rephrase the question to ask "who
> prefers to base subsequent work on RFC 3264 semantics?", then you would
> need to combine positions 2 and 4, and you would get a vote of 28 (the
> position 3 votes) for a new semantic model (requiring significant new work
> on SDP) against 21 (the sum of votes for positions 2 and 4) for RFC 3264
> semantics.
>
> So while I do not object to using JSEP as a basis for further work, it
> seems that the group is far less certain about the on-the-wire semantics to
> be associated with it.  My preference is to focus on RFC 3264 semantics
> (noting that the low level of the API would still allow considerable
> flexibility to support other signaling protocols).  My key concern is to
> have clear rules (based on common semantics) for interworking
> media/transport negotiation procedures between different on-the-wire
> protocols to avoid potential interop problems.
>
> In particular, at this point in the discussion, I do not see the value of
> allowing multiple open OFFERs within a dialog (which have acknowledged
> problems), multiple ANSWERs within a dialog, or PRANSWERs, none of which
> exist in RFC 3264.
>
> I propose that the group first decide whether to use JSEP as a basis for
> further work and in subsequent step(s) decide whether and how to go beyond
> RFC 3264 semantics.  I see this proposal as simply a clarification of the
> meaning of position 3.
>
> Richard Ejzak
>

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 21 Feb 2012 17:02:56 -0600

Hi Roman,
If this issue has already been debated in the group, I must apologize.  But if standards had to accommodate every non-standard implementation in existence then we wouldn't be able to accomplish much...

I proposed in another thread that we model this kind of behavior with standard SIP serial forking, which JSEP must be able to support.  The SIP isn't exactly the same, but the offer/answer sequence is.  This allows implementations to realize this flow in practice if necessary without encoding it in our specs.  Could this be an acceptable compromise?

Richard

________________________________
From: Roman Shpount [mailto:[email-masked]]
Sent: Tuesday, February 21, 2012 4:32 PM
To: Cary W FitzGerald
Cc: Ejzak, Richard P (Richard); [email-masked]
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP

Another issue is that real-life SIP deployments are often not RFC 3264 complaint. In particular it is not unusual to receive different SDP in provisional and final INVITE response. This does not fit offer/answer model since it implies multiple answers to one offer with subsequent answers overwriting previous ones. So, offer/answer compliance is insufficient even for the SIP interop.
_____________
Roman Shpount

On Tue, Feb 21, 2012 at 3:13 PM, Cary W FitzGerald <[email-masked]<mailto:[email-masked]>> wrote:
This is partially inevitable.  For WebRTC applications that interact with SIP gateways, the WebRTC application can't signal anything that 3264 won't allow, since the gateway's side won't be able to deal with it.  The original architecture document http://tools.ietf.org/html/draft-ietf-rtcweb-overview-02 proposes a RTC trapezoid and any well-behaved trapezoid needs to consider the SIP case and therefore 3264.

There is another important case, which is when the trapezoid degenerates into a triangle.  This is the case where the web server controls both sides of the conversation (e.g. connecting to an attendant at www.ftd.com<http://www.ftd.com> without any intervening PBX/switch/traditional contact center).  Since there is no PSTN GW to contend with, it's not necessary to obey the gateway's rules.  In this case, the server presumably knows what it's doing, so it's probably a bug if it trips itself up.

Cary.

Hi All,

Richard Ejzak

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ted Hardie
Sent: Tuesday, February 07, 2012 2:25 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] Consensus call on JSEP/ROAP

thanks,

Ted Hardie for the Chairs
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Roman Shpount <[email-masked]>
Date: Tue, 21 Feb 2012 18:18:32 -0500

Hi Richard,

I must apologize as well, since I know that this issue was discussed before
on the list and decision was made to support multiple provisional
responses. I am not sure there was a consensus call on it, but it looked
like work group decided to implement this in both ROAP and JSEP. I see your
point about standards, but unfortunately real life is often different.

You proposal in another thread is only an acceptable compromise if parallel
forking is supported. If parallel forking is supported, each new
provisional SDP can be treated as a new parallel fork and the previous
media connection can be discarded.
_____________
Roman Shpount

On Tue, Feb 21, 2012 at 6:02 PM, Ejzak, Richard P (Richard) <
[email-masked]> wrote:

> ** **
>
> Hi Roman,****
>
> If this issue has already been debated in the group, I must apologize.
>  But if standards had to accommodate every non-standard implementation in
> existence then we wouldn’t be able to accomplish much…****
>
> ** **
>
> I proposed in another thread that we model this kind of behavior with
> standard SIP serial forking, which JSEP must be able to support.  The SIP
> isn’t exactly the same, but the offer/answer sequence is.  This allows
> implementations to realize this flow in practice if necessary without
> encoding it in our specs.  Could this be an acceptable compromise?****
>
> ** **
>
> Richard****
>
> ** **
>  ------------------------------
>
> *From:* Roman Shpount [mailto:[email-masked]]
> *Sent:* Tuesday, February 21, 2012 4:32 PM
> *To:* Cary W FitzGerald
> *Cc:* Ejzak, Richard P (Richard); [email-masked]
> *Subject:* Re: [rtcweb] Consensus call on JSEP/ROAP****
>
> ** **
>
> ****
> On Tue, Feb 21, 2012 at 3:13 PM, Cary W FitzGerald <[email-masked]>
> wrote:****
>
> therefore 3264.****
> ** **
> doing, so it's probably a bug if it trips itself up.****
>
> ** **
>
> use case.****
> ** **
> ****Cary****.****
> ** **
> On Feb 21, 2012, at 8:52 AM, Ejzak, Richard P (Richard) wrote:****
>
>
>
> ****
>
> Hi All,
> input prior to the document deadline for ****Paris****.
>
> thanks,
>
> https://www.ietf.org/mailman/listinfo/rtcweb****
>
> ** **
>
>
> https://www.ietf.org/mailman/listinfo/rtcweb****
>
> ** **
>

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 21 Feb 2012 17:40:32 -0600

Hi Roman,
You are correct that parallel forking is needed to model this case.  I meant to distinguish between cases where the previous dialog is cleared immediately upon receipt of a new dialog, compared to the case where multiple dialogs are maintained in parallel, and I messed up.  Thanks.

Richard

________________________________
From: Roman Shpount [mailto:[email-masked]]
Sent: Tuesday, February 21, 2012 5:19 PM
To: Ejzak, Richard P (Richard)
Cc: Cary W FitzGerald; [email-masked]
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP

Hi Richard,

I must apologize as well, since I know that this issue was discussed before on the list and decision was made to support multiple provisional responses. I am not sure there was a consensus call on it, but it looked like work group decided to implement this in both ROAP and JSEP. I see your point about standards, but unfortunately real life is often different.

You proposal in another thread is only an acceptable compromise if parallel forking is supported. If parallel forking is supported, each new provisional SDP can be treated as a new parallel fork and the previous media connection can be discarded.
_____________
Roman Shpount

On Tue, Feb 21, 2012 at 6:02 PM, Ejzak, Richard P (Richard) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Roman,
If this issue has already been debated in the group, I must apologize.  But if standards had to accommodate every non-standard implementation in existence then we wouldn't be able to accomplish much...

Richard

________________________________
From: Roman Shpount [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, February 21, 2012 4:32 PM
To: Cary W FitzGerald
Cc: Ejzak, Richard P (Richard); [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP

Cary.

Hi All,

Richard Ejzak

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ted Hardie
Sent: Tuesday, February 07, 2012 2:25 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] Consensus call on JSEP/ROAP

thanks,

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 27 Feb 2012 02:21:23 +0000

Hi Richard,

For your first mail on standard signaling, I would say that "Welcome to WebRTC signaling". In fact, I had same expectation of standard signaling as yours 6 months back, Please see WebRTC archive for more details. But, WebRTC (wire) signaling protocol will be proprietary per website. The reason for this approach is that there is no need to interop between two different WebRTC sites and same  JS (signaling protocol) is executed in all the client within the single website. For example, www.partha.com<http://www.partha.com> will have partha protocol and www.richard.com<http://www.richard.com> will have Richard protocol wherein partha site and Richard site will never interop with each other. Even if they decide to interop, it is upto Partha & Richard to decide what is the choice of signaling protocol and no need of standard at this moment. We may wish to have later  :). Hope this clarifies your doubt on signaling wire protocol.

The aim of WebRTC signaling discussion is to verify whether JSEP (WebRTC signaling protocol in API) defines the basic set of signaling protocol primitives like offer/answer which helps to develop any kind of proprietary/standard protocol in the wire. So, it is perfectly valid to discuss proprietary SIP callflow which are prevalent in the deployment in WebRTC mailing list and it will be considered as one WebRTC application.   AFAIK, media protocol (SRTP, ICE) standard are followed in the normal standard fashion as different browsers (like Chrome, IE, Mozilla) and other WebRTC clients (gateways) has to interop.

As lot of standard SIP implementation exists, let us review JSEP in a way that JSEP protocol develop JS application which helps to interop with standard SIP but it is not the main motive of this group.

Thanks
Partha

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ejzak, Richard P (Richard)
Sent: Wednesday, February 22, 2012 5:11 AM
To: Roman Shpount
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP

Hi Roman,

Richard

Cc: Cary W FitzGerald; [email-masked]<mailto:[email-masked]>

Hi Richard,

Richard

Cary.

Hi All,

Richard Ejzak

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ted Hardie
Sent: Tuesday, February 07, 2012 2:25 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] Consensus call on JSEP/ROAP

thanks,

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Wed, 29 Feb 2012 22:20:07 +0800

Hi Partha

I agree with you that websites need not interop with each other and they can have their own proprietary signaling. But the webservers may need to interop and need to support standard signaling protocols to work with other servers like SIP or media servers.

so then we need to have some protocol as the default one (E.g. SIP) and if there is no signaling protocol mentioned, then assume the protocol to be SIP.

I think this is where the draft on SIP over Websockets becomes important when Websockets is used as a transport for carrying signaling messages between web browsers and web servers.

Regards
Ranjit

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ravindran, Parthasarathi [[email-masked]]
Sent: Monday, February 27, 2012 7:51 AM
To: Ejzak, Richard P (Richard); Roman Shpount
Cc: [email-masked]
Subject: Re: [rtcweb] Consensus call on JSEP/ROAP

Hi Richard,

For your first mail on standard signaling, I would say that “Welcome to WebRTC signaling”. In fact, I had same expectation of standard signaling as yours 6 months back, Please see WebRTC archive for more details. But, WebRTC (wire) signaling protocol will be proprietary per website. The reason for this approach is that there is no need to interop between two different WebRTC sites and same  JS (signaling protocol) is executed in all the client within the single website. For example, www.partha.com<http://www.partha.com> will have partha protocol and www.richard.com<http://www.richard.com> will have Richard protocol wherein partha site and Richard site will never interop with each other. Even if they decide to interop, it is upto Partha & Richard to decide what is the choice of signaling protocol and no need of standard at this moment. We may wish to have later  :). Hope this clarifies your doubt on signaling wire protocol.

Thanks
Partha

Hi Roman,

Richard

Hi Richard,

You proposal in another thread is only an acceptable compromise if parallel forking is supported. If parallel forking is supported, each new provisional SDP can be treated as a new parallel fork and the previous media connection can be discarded.
_____________
Roman Shpount
On Tue, Feb 21, 2012 at 6:02 PM, Ejzak, Richard P (Richard) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Roman,
If this issue has already been debated in the group, I must apologize.  But if standards had to accommodate every non-standard implementation in existence then we wouldn’t be able to accomplish much…

I proposed in another thread that we model this kind of behavior with standard SIP serial forking, which JSEP must be able to support.  The SIP isn’t exactly the same, but the offer/answer sequence is.  This allows implementations to realize this flow in practice if necessary without encoding it in our specs.  Could this be an acceptable compromise?

Richard

Cary.

Hi All,

Richard Ejzak

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ted Hardie
Sent: Tuesday, February 07, 2012 2:25 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] Consensus call on JSEP/ROAP

thanks,

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 29 Feb 2012 16:05:03 +0000

Hi Ranjit,

It depends upon the web servers federation protocol choice. The choices of federation protocol may be standard protocol like SIP, Jingle  or the proprietary protocol of site choice.    I agree with you that existing VoIP/UC/Telecom deployments will prefer SIP as a federation protocol but we may not able to generalize it in RTCWeb.

SIP over Websocket is not really required in case JSEP is the choice of browser API protocol.  IMO, SIP over Websocket is a overkill as there is no need of SIP routing header like via, max-forward, route are not required between webserver and browser. The simple protocol mapping between Standard SIP and JSEP will serve the purpose.

Thanks
Partha

From: Avasarala, Ranjit [mailto:[email-masked]]
Sent: Wednesday, February 29, 2012 7:50 PM
To: Ravindran, Parthasarathi; Ejzak, Richard P (Richard); Roman Shpount
Cc: [email-masked]
Subject: RE: [rtcweb] Consensus call on JSEP/ROAP

Hi Partha

Regards
Ranjit

From: [email-masked]<mailto:[email-masked]> [[email-masked]] On Behalf Of Ravindran, Parthasarathi [[email-masked]]

Thanks
Partha

Hi Roman,

Richard

Hi Richard,

Richard

Cary.

Hi All,

Richard Ejzak

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ted Hardie
Sent: Tuesday, February 07, 2012 2:25 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] Consensus call on JSEP/ROAP

thanks,

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 29 Feb 2012 17:14:37 +0100

2012/2/29 Ravindran, Parthasarathi <[email-masked]>:
>  IMO, SIP over Websocket is a overkill as there is no need of SIP routing
> header like via, max-forward, route are not required between webserver and
> browser.

Via header is required to match the transaction.
Route headers (or Record-Route) are required to reverse them in
responses and play the "loose-routing" game as RFC 3261 states. If the
client (the web application running in the web browser) does not
handle it, then you need the "web server" to behave as a strange B2BUA
doing "protocol conversion" from SIP to YourCustomProtocol and vice
versa.

You don't like SIP over WebSocket. I like it. It works and it's not an
overkill (I do know it, have you tested it?).

> The simple protocol mapping between Standard SIP and JSEP will
> serve the purpose.

Not all the people like protocol gateways. They can just deteriorate
the communication, they never improve it.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Thu, 1 Mar 2012 01:35:37 +0800

Hi Partha

I do not agree with you when you say SIP over websockets is not required. When websockets is the transport protocol between web browsers and web servers, then it would be signaling protocols like SIP or XMPP that would be used for carrying session description information (SDP) - be it ROAP or JSEP data.

So be it JSEP/ROAP over SIP or XMPP - these would be over Websockets.  So then you need protocol gateways to talk to webservers.  This will trigger the need for interop between webservers and signaling / media gateways

Regards
Ranjit

From: Ravindran, Parthasarathi [mailto:[email-masked]]
Sent: Wednesday, February 29, 2012 9:35 PM
To: Avasarala, Ranjit; Ejzak, Richard P (Richard); Roman Shpount
Cc: [email-masked]
Subject: RE: [rtcweb] Consensus call on JSEP/ROAP

Hi Ranjit,

Thanks
Partha

From: Avasarala, Ranjit [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

Hi Partha

Regards
Ranjit

Thanks
Partha

Hi Roman,

Richard

Hi Richard,

Richard

Cary.

Hi All,

Richard Ejzak

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ted Hardie
Sent: Tuesday, February 07, 2012 2:25 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [rtcweb] Consensus call on JSEP/ROAP

thanks,

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 1 Mar 2012 06:53:40 +0000

Inaki,

I agree that we have two different architecture in mind.

Ranjit/Inaki,

After IETF-83, I can write the informational mapping document to show how to implement simple standard SIP using JSEP. Let implementers choose whether JSEP-SIP gateway or SIP over WebSocket is the way to go. 

Thanks
Partha

>From: Iñaki Baz Castillo [mailto:[email-masked]]
>Sent: Wednesday, February 29, 2012 9:45 PM
>To: Ravindran, Parthasarathi
>Cc: Avasarala, Ranjit; Ejzak, Richard P (Richard); Roman Shpount;
>[email-masked]
>>  IMO, SIP over Websocket is a overkill as there is no need of SIP
>> routing header like via, max-forward, route are not required between
>> webserver and browser.
>
>client (the web application running in the web browser) does not handle
>it, then you need the "web server" to behave as a strange B2BUA doing
>"protocol conversion" from SIP to YourCustomProtocol and vice versa.
>
>> The simple protocol mapping between Standard SIP and JSEP will serve
>> the purpose.
>
>Not all the people like protocol gateways. They can just deteriorate the
>communication, they never improve it.
>
>
>Regards.
>
>
>--
>Iñaki Baz Castillo
><[email-masked]>