Subject: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling

From: Cullen Jennings <[email-masked]>
Date: Fri, 14 Oct 2011 21:09:16 -0600

Jonathan and I submitted a new draft on setting up media based on the SDP Offer/Answer model. The ASCII flows are a bit hard to read so until I update them, I recommend reading the PDF version at 

http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf

Clearly the draft is an early stage but we plan to revise it before the deadline for the IETF 82. Love to get input - particularly on if this looks like generally the right direction to go.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 15 Oct 2011 11:20:41 +0200

> Clearly the draft is an early stage but we plan to revise it before the deadline for the IETF 82. Love to get input - particularly on if this looks like generally the right direction to go.

Hi, thanks for this work. IMHO this is clearly the way to go, and the
proposal that could make everyone happy. Let me just a comment:

-----------------------------
5.3.3.  OK
The OK message is used by the receiver of an ANSWER message to
indicate that it has received the ANSWER message. It has no contents
itself and is merely used to stop the retransmissions of the ANSWER
-----------------------------

I wonder how much needed is the OK message taking into account that
the transport will always be reliable. So, instead of retransmiting
the ANSWER until an OK arrives, why not retransmit the OFFER until an
ANSWER arrives and drop the OK message from the spec?

Probably I miss something here as in the case the offered wants to
signal ringing (a 180 in SIP) it conveys no media so there would be no
ANSWER message for long time until the offered human user decides to
accept or reject the incoming call. If so, please forget this comment
:)

2)

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 15 Oct 2011 11:46:26 +0200

Hi, some other possible issues with the above ROAP OK message:

ROAP OK message fits well with the ACK for 2XX in SIP. Let's assume
that alice (pure SIP UA) and bob (RTCweb client) can intercommunicate
via a RTCweb server implementing SIP over WebSocket (so JS in both
browser is speaking real SIP rather than a custom protocol).

NOTE: When alice sends a SIP INVITE to bob it arrives unchanged to
bob. bob extracts the SDP and converts it into a ROAP OFFER. So I
write it as "INVITE + ROAP OFFER" but it just means a common SIP
INVITE with an SDP.

case 1)  SDP OFFER in the INVITE

  alice (SIP client)          bob (RTCweb client)

  --------> INVITE + ROAP OFFER (F1)

      200 OK + ROAP ANSWER (F2) <---------

      (200 is lost in the network or server)

      200 OK + ROAP ANSWER (F2) <---------
      200 OK + ROAP ANSWER (F2) <---------

  ---------> ACK (F3)

ISSUE: How would bob receive a ROAP OK message?

Possible response: bob should generate it by itself upon receipt of
the SIP ACK and signal it to the RTCweb stack in his browser. Am I
right?

case 2)  SDP OFFER in the 200 OK

  alice (SIP client)          bob (RTCweb client)

  --------> INVITE (no SDP)

         200 OK + ROAP OFFER (F2) <---------

      (200 is lost in the network or server)

         200 OK + ROAP OFFER (F2) <---------
         200 OK + ROAP OFFER (F2) <---------

  ---------> ACK + ROAP ANSWER (F3)

ISSUE: In this case there is no SIP message to confirm the receipt of
the ACK (which carries the SDP answer) so bob has no chance to send
the ROAP OK message over the wire. Would it break the signaling?

Possible response: there is no need at all in sending the ROAP OK
message (if alice is a pure SIP client it does not need it, and if
alice is a RTCweb client it should autogenerate it).

ISSUE: Now imagine that alice is also a WEBrtc client. In this case
(Case 2) when alice sends the ACK + ROAP ANSWER she will not receive a
new SIP message (which could be mapped to ROAP OK) so, should alice
signal the ROAP OK message to his RTCweb stack once the ACK + ROAP
ANSWER is sent?

Possible response: yes.

Thanks a lot.

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

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 18 Oct 2011 03:58:03 +0530

Cullen/Joanthan,

I like your proposed idea as it is going in the direction of having
"standard" signaling protocol for RTCWeb. I'm seeing your proposal as
SDP offer/answer over websocket and the proposal helps to easy gateway
development between RTCWeb server and legacy signaling protocols.

I have fundamental question in the proposal as it proposes RTCWeb server
as SIP proxy equivalent and in reality, unfortunately most of the SIP
deployment work is based on B2BUA. The question is whether RTCWeb server
shall be dialog-state or MUST be transaction-stateful only. 

Also, session-id in the draft is used to uniquely understand the offerer
and answerer in the transaction or session. In case it is session, how
to indicate the termination of the session.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Cullen Jennings
>Sent: Saturday, October 15, 2011 8:39 AM
>To: [email-masked]; [email-masked]
>Cc: Jonathan Rosenberg
>Subject: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling
>
>
>Jonathan and I submitted a new draft on setting up media based on the
>SDP Offer/Answer model. The ASCII flows are a bit hard to read so until
>I update them, I recommend reading the PDF version at
>
>Clearly the draft is an early stage but we plan to revise it before the
>deadline for the IETF 82. Love to get input - particularly on if this
>looks like generally the right direction to go.
>
>
>_______________________________________________
>rtcweb mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Oct 2011 00:41:01 +0200

2011/10/18 Ravindran Parthasarathi <[email-masked]>:
> "standard" signaling protocol for RTCWeb.

Please Ravindran, don't manipulate mails, text and draft given by
other persons in this WG. The draft *clearly* says:

--------------------
The protocol specified here defines the state machines, semantic
behaviors, and messages that are exchanged between instances of the
state machines. ***However, it does not specify the actual on-the-wire
transport of these messages.*** Rather, it assumes that the
implementation of this protocol would occur within the browser itself,
and then browser APIs would allow the application's JavaScript to
request creation of messages and insert messages into the state
machine. ***The actual transfer of these messages would be the
responsibility of the web application, and would utilize protocols
such as HTTP and WebSockets.*** To facilitate implementation within a
browser, JSON notation is used to describe the message
--------------------

No, this is not a draft about a "default signaling protocol" for
RTCweb. Wrong. This is just a protocol for communication between the
JavaScript code and the RTCweb stack in the browser. It does NOT
mandate how the signaling messages are sent on-the-wire.

So this has nothing to do with your insistent proposal of having a
"default signaling protocol" that all the RTCweb clients "should
implement". Sorry.

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

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Tue, 18 Oct 2011 04:29:52 +0530

Inaki,

Heaven sake, Please reply with original text. You always cut the text in reply so badly that I have to repeat what I have said in the original mail again in the reply. Your cutting practice leads to circular discussion and let us try to avoid it.

Original mail statement is as follows:
<snip>
I'm seeing your proposal as SDP offer/answer over websocket
</snip>

Hope this clarify what I meant. Also, Please see bullet 2 in sec 6 of draft-partha-rtcweb-signaling-00 to get the whole picture.

Thanks,
Partha

>From: Iñaki Baz Castillo [mailto:[email-masked]]
>Sent: Tuesday, October 18, 2011 4:11 AM
>To: Ravindran Parthasarathi
>Cc: Cullen Jennings; [email-masked]; [email-masked]; Jonathan
>Rosenberg
>Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Oct 2011 01:45:52 +0200

> Heaven sake, Please reply with original text. You always cut the text in reply so badly that I have to repeat what I have said in the original mail again in the reply. Your cutting practice leads t…

Mail threads exist to avoid reading again an entire previous mail. I
cut the exact text for which I'm replying my mail, this is the correct
behavior.

In the same way you could use a nice mail client so you would get the
previous text beggining with ">" (and you don't need to add your
strange <snip> </snip> symbols). Just as a suggestion.

> Hope this clarify what I meant.

No. SDP ofer/answer over WebSocket is NOT enough. How do you tell the
server/proxy *who* you want to call or where your SDP invitation must
be sent? For that you need something else, something more than just a
SDP exchange, right?

So you also need a *signaling protocol*, and that can be SIP (SIP over
WebSocket is signaling + SDP exchange), or XMPP+Jingle, or any custom
JSON based signaling protocol. I don't want to mandate a specific
signaling protocol, but you do.

What you propose in *every* your mails is that such signaling protocol
(which defines the format of messages sent on-the-wire) MUST be a
RTCweb standard built-in every webv browser. And that has nothing to
do with the ROAP draft which just defines a message exchange between
the JavaScript client (the "overkill" as you said in other mail) and
the RTCweb stack within the browser for handling *media* sessions.

> Also, Please see bullet 2 in sec 6 of draft-partha-rtcweb-signaling-00 to get the whole picture.

----------------------------
6.  Possible RTCWeb signaling protocols

   The following Signaling protocols will qualify for becoming standard
   RTCWeb signaling protocol

   2.  Websocket with SDP offer/answer
-----------------------------

Do I need to explain again that WebSocket is not a signaling protocol
by itself so you need to define a WebSocket subprotocol on top of it?
Do you understand that sending a SDP to the remote peer is not enough?
Probably you want to tell the remote peer "who you are".

In the other side, I don't care whether your proposed "default
signaling protocol for RTCweb" is based on WebSocket or whatever. That
does not make me happy. Nobody else seems to be in favour of defining
and *mandating* a default signaling protocol. Just you.

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 17 Oct 2011 17:56:44 -0700

> other persons in this WG. The draft *clearly* says:
Iñaki,

Ravindran's email clearly says "is going in the direction of", not "is a
standard signalling protocol".

In general, critiquing others' statement of support on vocabulary choices is
not really helpful.  Focus on your contributions, please, rather than
assuming that others are "manipulations".  This is not useful nor collegial
behavior.

regards,

Ted Hardie

---

From: Roman Shpount <[email-masked]>
Date: Mon, 17 Oct 2011 20:58:40 -0400

Cullen,

Did we decide to explicitly not support forking which generates multiple
final answers? If this is not the case, how is this supposed to be
implemented using your model?
_____________
Roman Shpount

On Fri, Oct 14, 2011 at 11:09 PM, Cullen Jennings <[email-masked]> wrote:

>
> Jonathan and I submitted a new draft on setting up media based on the SDP
> Offer/Answer model. The ASCII flows are a bit hard to read so until I update
> them, I recommend reading the PDF version at
>
> deadline for the IETF 82. Love to get input - particularly on if this looks
> like generally the right direction to go.
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 18 Oct 2011 11:16:02 +0200

On 10/18/2011 02:58 AM, Roman Shpount wrote:
> Cullen,
>
> Did we decide to explicitly not support forking which generates 
> multiple final answers? If this is not the case, how is this supposed 
> to be implemented using your model?

I and some people from Ericsson had a discussion about forking the other 
day (the ability to send out one request and have it generate multiple 
PeerConnections on the response).

Options include:

- Sending a request with no content for which state must be kept, 
creating new PeerConnection objects on answer that can handle an answer 
without generating an offer first, and then renegotiating stuff that 
needs state subsequently
- Creating a new "PeerConnectionFactoryWithOffer" object that holds the 
state of the request, but has the ability to mint several 
PeerConnections on responses
- Throwing away the initial PeerConnection, munge the incoming Answer to 
look like an Offer, create a PeerConnection from it, and throw away the 
resulting Answer
- Create the ability to create a PeerConnection from an Offer + an 
Answer, together with the ability to create an Offer without creating a 
PeerConnection (this is a variant of the Factory method)
- Do something different.....

Of course there's always the option of not supporting forking, leading 
it to be a problem that only concerns those who write gateways into 
systems where it is required; SIP systems that don't support forking are 
in the same boat.

It's not impossible, but it does have an overhead cost.

> _____________
> Roman Shpount
>
>
> On Fri, Oct 14, 2011 at 11:09 PM, Cullen Jennings <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     Jonathan and I submitted a new draft on setting up media based on
>     the SDP Offer/Answer model. The ASCII flows are a bit hard to read
>     so until I update them, I recommend reading the PDF version at
>
>     Clearly the draft is an early stage but we plan to revise it
>     before the deadline for the IETF 82. Love to get input -
>     particularly on if this looks like generally the right direction
>     to go.
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Oct 2011 12:18:13 +0200

Hi, 

>No, this is not a draft about a "default signaling protocol" 
>for RTCweb. Wrong. This is just a protocol for communication 
>between the JavaScript code and the RTCweb stack in the 
>browser. It does NOT mandate how the signaling messages are 
>sent on-the-wire.

Eventhough the draft does not suggest a default signaling protocol, I don't think that is completely true that it is only between the JS app and broswer. At least it's not very clear.

- Section 5.1 says: "ROAP messages are typically carried over a **reliable transport** (likely HTTP via XMLHttpRequest or WebSockets),..."

- Section 5.3.3 defines an "OK" message, which is used to cease **re-transmissions** of the ANSWER.

- In addition, there is text talking about **ROAP signaling messages** (and gateways translating between those and SIP messages).

So, while I support and offer/answer based approach, I think we need to get a clearer understanding of the scope.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Oct 2011 12:24:41 +0200

2011/10/18 Harald Alvestrand <[email-masked]>:
> I and some people from Ericsson had a discussion about forking the other day
> (the ability to send out one request and have it generate multiple
> - Sending a request with no content for which state must be kept, creating
> new PeerConnection objects on answer that can handle an answer without
> generating an offer first, and then renegotiating stuff that needs state
> subsequently

> state of the request, but has the ability to mint several PeerConnections on
> responses

> - Create the ability to create a PeerConnection from an Offer + an Answer,
> together with the ability to create an Offer without creating a

> - Do something different.....

Hi Harald, if I'm right the problem arises when the RTCweb client
generates a SDP/ROAP offer, sends it to the proxy/server and receives
more than one SDP/ROAP answer. The problem is that, currently, the
PeerConnection object just expects a single answer, am I right?

The above options 1 and 3 require the RTCweb client to generate an
"INVITE" (let me name it INVITE) with no SDP/ROAP, which IMHO limits
too much some possible scenarios. In SIP world, sending an empty
INVITE means that the receiver could offer in the 200 OK response a
SDP offer with codecs not supported by the caller, so the caller must
send ACK and later a BYE. That's commonly ugly so I discourage its
usage for RTCweb.

Said that, I strongly like your option 2 "Creating a new
PeerConnectionFactoryWithOffer". If I understand it properly, when a
RTCweb environment allows media forking, the RTCweb client should
create a PeerConnectionFactoryWithOffer object rather than a
PeerConnection. Then it sends the offer over the wire. Upon receipt of
each response with different ROAP/SDP answer, the object would
internally generate different PeerConnection objects (but the state of
all of them are governed by the PeerConnectionFactoryWithOffer
object). Am I right?

Regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Oct 2011 12:36:17 +0200

> - Section 5.1 says: "ROAP messages are typically carried over a **reliable transport** (likely HTTP via XMLHttpRequest or WebSockets),..."

Yes, that is because JavaScript code running in a browser can only
communicate via HTTP or WebSocket.

> - Section 5.3.3 defines an "OK" message, which is used to cease **re-transmissions** of the ANSWER.

I expect that is a "guideline" for the signaling protocol implementor.
There is no need for such "OK" message to be received from the peer or
server. The own JS code could generate it when appropriate and pass it
to its RTCweb stack.

> - In addition, there is text talking about **ROAP signaling messages** (and gateways translating between those and SIP messages).

That just means that, of course, ROAP must be carried within some
signaling protocol (obvious) so, in case of interoperating with a SIP
network a gateway is required (unless you use SIP over WebSocket).

> So, while I support and offer/answer based approach, I think we need to get a clearer understanding of the scope.

IMHO "ROAP" draft just suggests a generic signaling guidelines for
future RTCweb protocol developers. It does define the communication
between the JS code and its own RTCweb stack, but not the signaling
on-the-wire (for that guidelines are provided).

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Oct 2011 12:47:40 +0200

Hi, 

>>>for RTCweb. Wrong. This is just a protocol for 
>>>communication between the JavaScript code and the RTCweb stack in the browser. It 
>>>does NOT mandate how the signaling messages are sent on-the-wire.
>>
>> Eventhough the draft does not suggest a default signaling 
>> protocol, I don't think that is completely true that it is 
>> only between the JS app and broswer. At least it's not very clear.
>>
>> - Section 5.1 says: "ROAP messages are typically carried 
>> over a **reliable transport** (likely HTTP via XMLHttpRequest 
>> or WebSockets),..."
> 
> Yes, that is because JavaScript code running in a browser can 
> only communicate via HTTP or WebSocket.

Yes, but the JS app and browser don't communicate with each other using HTTP or WebSockets.

> There is no need for such "OK" message to be received from 
> the peer or server. The own JS code could generate it when 
> appropriate and pass it to its RTCweb stack.

Why? The browser is not going to re-transmit anything, is it?

>> - In addition, there is text talking about **ROAP signaling 
>> messages** (and gateways translating between those and SIP messages).
> 
> That just means that, of course, ROAP must be carried within 
> some signaling protocol (obvious) so, in case of 
> interoperating with a SIP network a gateway is required 
> (unless you use SIP over WebSocket).

Yes, so that means ROAP messages will be carried over some signaling protocol - meaning ROAP is not only a protocol between the JS app and browser.

I just want to make sure everybody has the same understanding of the scope, because at least to me it is a little unclear.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Oct 2011 12:53:07 +0200

> Yes, but the JS app and browser don't communicate with each other using HTTP or WebSockets.

Of course, the signaling must go over a server.

> Why? The browser is not going to re-transmit anything, is it?

That depends on the chosen signaling protocol. ROAP gives guidelines
to make a like-VoIP protocol and in VoIP networks retransmissions are
sometimes needed. So it's resposability of the JavaScript code to send
a retransmission when required.

> Yes, so that means ROAP messages will be carried over some signaling protocol - meaning ROAP is not only a protocol between the JS app and browser.

Right, but ROAP does not define the protocol and the message exchange
on the wire. Just gives some requirements for it (requirements that
are common to any VoIP protocol).

> I just want to make sure everybody has the same understanding of the scope, because at least to me it is a little unclear.

IMHO it's clear by reading "Introduction" section:

------------------
The protocol specified here defines the state machines, semantic
behaviors, and messages that are exchanged between instances of the
state machines. However, it does not specify the actual on-the-wire
transport of these messages. Rather, it assumes that the
implementation of this protocol would occur within the browser itself,
and then browser APIs would allow the application's JavaScript to
request creation of messages and insert messages into the state
machine. The actual transfer of these messages would be the
responsibility of the web application, and would utilize protocols
such as HTTP and WebSockets.
------------------

But maybe it could be improved so there are no doubts about what ROAP
involves/specifies.

Regards.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 18 Oct 2011 13:10:18 +0200

On 10/18/11 12:24, Iñaki Baz Castillo wrote:
> 2011/10/18 Harald Alvestrand<[email-masked]>:
Yes. My note was intended to point out that there's a number of API 
solutions here, but they all cost in terms of complexity.
> all of them are governed by the PeerConnectionFactoryWithOffer
Yes, that's right.

One advantage of this approach is that the new class comes in addition 
to the normal PeerConnection class, so the interface for this 
functionality does not clutter up the interface for applications that 
don't want to deal with forking; they just never create such objects, 
and will reply to subsequent answers with "ERROR" (as they're always 
free to do).

There are a number of additional details that need specification before 
this can be implemented, of course; we might want to delay that 
functionality beyond the first wave of releases.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Oct 2011 13:18:59 +0200

2011/10/18 Harald Alvestrand <[email-masked]>:
> One advantage of this approach is that the new class comes in addition to
> the normal PeerConnection class, so the interface for this functionality
> does not clutter up the interface for applications that don't want to deal
> with forking; they just never create such objects, and will reply to
> subsequent answers with "ERROR" (as they're always free to do).

I like the idea.

> There are a number of additional details that need specification before this
> can be implemented, of course; we might want to delay that functionality
> beyond the first wave of releases.

As you noted, the point is that this advanced feature can be added
later over the existing stack. So I support this proposal.

Regards.

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

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 18 Oct 2011 14:24:57 +0200

Our idea is basically that whenever you create a new PeerConnection in
the same context as you have already created one or more
PeerConnection's, the same local candidates should be re-used. Of course 
the 5-tuple must remain unique so that different connections don't 
collapse into one, but this is quite simple to resolve.

For clarity, the above would be requirements on the implementation (in 
browsers).

This means that support of forking would be simple as the IP+port's to
send media to (for the remote end) remains also for the new PeerConnection.

Another advantage is that creating new PeerConnections will be faster as 
new candidates does not need to be gathered.

I think this is quite a clean solution since there is no need for API
changes, or any additional factory layer.

Stefan

---

From: "Roy, Radhika R USA CIV (US)" <[email-masked]>
Date: Tue, 18 Oct 2011 12:49:06 +0000

Partha:

I believe it may be B2BUA along with proxy-capability that a Web server might have. However, Cullen and Jonathan might clearify this.

BR/Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravindran Parthasarathi
Sent: Monday, October 17, 2011 6:28 PM
To: Cullen Jennings; [email-masked]; [email-masked]
Cc: Jonathan Rosenberg
Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling

Cullen/Joanthan,

I like your proposed idea as it is going in the direction of having "standard" signaling protocol for RTCWeb. I'm seeing your proposal as SDP offer/answer over websocket and the proposal helps to easy gateway development between RTCWeb server and legacy signaling protocols.

I have fundamental question in the proposal as it proposes RTCWeb server as SIP proxy equivalent and in reality, unfortunately most of the SIP deployment work is based on B2BUA. The question is whether RTCWeb server shall be dialog-state or MUST be transaction-stateful only. 

Also, session-id in the draft is used to uniquely understand the offerer and answerer in the transaction or session. In case it is session, how to indicate the termination of the session.

Thanks
Partha

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Oct 2011 15:30:06 +0200

2011/10/18 Stefan Håkansson LK <[email-masked]>:
> PeerConnection's, the same local candidates should be re-used. Of course the
> 5-tuple must remain unique so that different connections don't collapse into
> one, but this is quite simple to resolve.
>
> Another advantage is that creating new PeerConnections will be faster as new
> candidates does not need to be gathered.
>

Hi Stefan, that looks nice, but could you explain what does it mean
"in the same context as you have already created one or more
PeerConnection's"?

Could you please translate it into a theorical JS API?

Regards.

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

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 18 Oct 2011 15:57:31 +0200

On 10/18/2011 03:30 PM, Iñaki Baz Castillo wrote:
> 2011/10/18 Stefan Håkansson LK<[email-masked]>:

What I mean is: if this web app has already created a PeerConncection, 
and is about to open another one (e.g. for a new fork), the new 
PeerConnection should use the same local candidates as the one already 
created collected.

> Could you please translate it into a theorical JS API?

Even better, I can point to the current API proposal: 
<http://dev.w3.org/2011/webrtc/editor/webrtc-20111017.html>. I think no 
changes would be required to the API per se, but some text on how the 
user agent should act need to be added.

(I'm sure I've overlooked some aspect, but hopefully it would be 
possible to fix)

Br,
Stefan

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Oct 2011 16:30:26 +0200

Cullen,

I would like to bring back my proposal for glare handling and propose
that it be included in ROAP. The reason is that I don't think the SIP
time based solution interact well with RTCWEB requirements at all.

The biggest issue is that one is likely to end up in glare condition
again due to that the transport of the ROAP messages between
end-points/Gateways can have properties that erases the randomization of
the timer.

For example an JS application that uses short polling for retrieving any
incomming ROAP messages, as that is timer based and done lets say every
5 seconds, then the polling is clearly done on a longer time scales,
many times longer than what the random glare resolution happens at. Thus
timer based solutions for resolving glare is use-less in RTCWEB context
where we don't know how timely the transport is.

Thus I would propose that the following mechanism is include in ROAP.
When generating an offer a 32-bit unsigned random integer value is
generated (GlareResolution) and attached to the ROAP message. The random
value may not be 0 and MAX_uint32.

What ever mechanism that inspects the message and is on the path of the
ROAP message and sees a second offer in the opposite direction when one
offer is outstanding in either direction can detect a glare. If the
glare condition is detected the two offer's GlareResolution values are
compared. The offer with the greater value wins. The other is discarded.
As long as the winning offer is forwarded all the way to the offerer we
can be certain that one signaling message wins.

In the case the two values are equal, both are discarded, but a error
message must be returned for both messages to cause the end-points to
generate new resolution values.

When interacting with a SIP gateway, the SIP gateway that create a ROAP
message can chose how to generate the tie-breaker. Either it can pick
MAX_uint32 to ensure that the message from the SIP side always wins, or
it can select to always loose using 0 or have a random value be sent.
Which is the right depends on where the glare occurs. But unless a glare
condition already have been detected, a random value is used.

This mechanism could also be retrofitted into SIP by adding either a SIP
header or a attribute in the SDP. That is what is referred as Cullen's
proposal below.

Secondly the glare condition will be detected in various cases depending
on in what state of signaling the glare occurs.

1) If A sends an offer that left A, but not arrived at the GW, while B's
are on its way between the GW and A.

2) IF A sends an offer that has passed the GW, while B's are on its way
between B and the GW.

3) Both A and Bs Offers are at the GW while neither has been forwarded.

4) Like 2) but B supports Cullen's behavior.

1) If A sends an offer that left A, but not arrived at the GW, while B's
are on its way between the GW and A.

Assuming the GW sent a random value:

In case 1, entity A (a RTCWEB browser) will receive the Offer from B
when itself has an outstanding offer. It perform the local tie-breaking
of the SDP and determine that either A or Bs Offer is the winning. If A
wins it just discards B, alternatively send an error (but that doesn't
appear necessary). If B wins it abandons its Offer and process B's.

In case 1, the GW when A's Offer arrive at the GW, it has already sent
B's offer with its tie-breaking value. It immediately determine who won
the tie-breaking and then continue acting according to it. If A's won
then it sends a SIP 491 with a significant large delay value. Then it
sends A's offer with some small delay just as it got lucky with a low
value. If B won, then it just discards A's Offer and waits for A's
answer to B's offer.

2) IF A sends an offer that has passed the GW, while B's are on its way
between B and the GW.

In case 2) the GW could look for a tie-breaker value according to
Cullen's proposal and if present then determine the winner. Considering
that the quickest way to resolve the tie-breaking towards the RTCWEB
client if the value isn't present is to fold for the RTCWEB client's
behalf. Thus set B's tie-breker value to max. Then respond with a 491
with delay 0 to B. When B come back with an new offer it assigns this
the highest tie-breaker value and send it to A. A will then abort its
offer and accept B's.

In case 2) in B, it will be completely in the SIP domain and it will
respond with a 491 with a random delay value back to the GW. The GW will
consume this message when it arrives.

3) Both A and Bs Offers are at the GW while neither has been forwarded.

In case 3) the GW can avoid having the SIP UA (B) know there was any
glare at all. This by setting the tie-breaking value for B's offer to
MAX assuring it wins over A, and then send it to A to replace the offer.

In case 4) the GW will have sent a tie-breaker value with A's offer to B
in the SDP. B's offer with a tie-breaker value arrives at the GW. The GW
determine who wins. If B wins it forwards B's offer to A. If A wins it
will do something to make B's offer being canceled. Maybe a 491 answer
is the simplest. Except that it will not be retired.

4) Like 2) but B supports Cullen's behavior.

In case 4) the UA (B) will have sent an invite with a tie-breaker value.
When A's Invite with a tie-breaking value arrive it can perform the
tie-breaking. If A wins then it immediately process it as if no
outstanding Invite exist. (Question: how will the proxies react on that
B responds immediately?). If B wins it sends a 491 for A's Invite. Then
it continues waiting for the response.

So independent of the optimization this can work as long as a GW is
allowed to override a random selection mechanism in cases where the
other protocol will resolve quicker if it does.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Oct 2011 17:40:47 +0200

2011/10/18 Magnus Westerlund <[email-masked]>:
> 5 seconds

Hi. This is RTC, so *realtime* is required for media sessions. I
expect that people should assume WebSocket usage rather than HTTP
polling.

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Oct 2011 08:44:27 -0700

I'm not sure I agree with this. 2-5 seconds isn't really that long to
wait for the
interval between the caller starting the call and the callee being alerted. I'm
not saying it's optimal, but I don't think it's unacceptable either. Moreover,
even if we agree that we're using something other than short poll, I
suspect there will be many applications that use long poll rather than
WS.

-Ekr

---

From: <[email-masked]>
Date: Tue, 18 Oct 2011 17:56:06 +0200

Ekr wrote:
> wait for the interval between the caller starting the call and the callee being alerted.

I consider 2-5 s a quite horrible call setup time, and I can tell that customers really care about it. Of course it's acceptable if such a long setup delay only occurs occasionally.

Wolfgang Beck

Deutsche Telekom Netzproduktion GmbH
Fixed Mobile Engineering Deutschland
Wolfgang Beck
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 628 2832 (Tel.)
http://www.telekom.de

Erleben, was verbindet.

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft Bonn
USt-IdNr. DE 814645262

Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 18 Oct 2011 12:07:12 -0400

On Tue, Oct 18, 2011 at 9:57 AM, Stefan Håkansson LK <
[email-masked]> wrote:

> What I mean is: if this web app has already created a PeerConncection, and
> is about to open another one (e.g. for a new fork), the new PeerConnection
> should use the same local candidates as the one already created collected.
>
>
What would happen if new PeerConnection has a different set of codecs/media
streams? Do we just add/remove local candidates based on how many different
streams are needed?

Overall I do like this idea since it not only addresses the forking issue,
but suggest a good resource usage policy.
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 18 Oct 2011 09:23:48 -0700

> I consider 2-5 s a quite horrible call setup time, and I can tell that customers really care about it. Of course it's acceptable if such a long setup delay only occurs occasionally.

Maybe I'm being unclear: it's not great, but there are plenty of settings
(e.g., online game setup) where it's not really that big a deal. My point isn't
that I wish to design a system with a lot of delay but merely that
(as I think Magnus's message implies) one shouldn't design a system
that only works if the signaling does not have even modest amounts
of delay.

-Ekr

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 Oct 2011 11:40:47 -0700

I'm going to slowly reply to a bunch of these comments in backwards order … 

But main thing on how to handle glare … I would love to see something better but I don't want to describe it in this draft so we just pointed at what we had.  If we can come up with a better way I'd like to have ROAP point at the draft that describes how to do with for things that use SDP offer / answer. 

End summary is however we decide to handle glare, I think we can fit that into ROAP but as we did not really have have a scheme written down yet, we just reused the existing stuff for now. Glad to update as we sort out what we need to do. 

> value may not be 0 and MAX_uint32.

So I like this types of scheme, but it seems if we put the random number in the SDP would allow this work for things beyond just RTCWeb.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 Oct 2011 11:41:15 -0700

Hi - glad to hear you see this going the right direction. On the topic of why we have an OK, let me provide a bit of the motivation. 

When one side sends and answer that says it wants to receive VP8 instead of H.264, it's probably useful to know when the other side got that information. This might impact the timing of when o send things or user interface that provides feedback about the status of the other side. We are also dealing with a web transaction model where transaction are not guarantee to happen even if they are sent over TCP. So you need to get back a response to request. It also helps with mapping to SIP but even if you were not mapping to another protocol, I suspect you would still need to be able to have an confirmation than and answer was received.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 Oct 2011 11:41:52 -0700

So I might have messed up the draft a bit. I'm fine with things can be implemented as dialog statefull, what I want is that it is possible to make a signaling gateway that is only transaction statefull. I'm fine if some signaling gateways are built as dialog statefull.

 (As a side note, some B2BUA are effectively transaction statefull but that is pretty rare )

> to indicate the termination of the session.

My personal opinion is that to be able to clean up all the state in a clean an easy way, we should add some message to indicate the SDP offer / answer state and related media streams can be discarded.  I'd like to add that to the next version.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 Oct 2011 11:42:02 -0700

On Oct 17, 2011, at 17:58 , Roman Shpount wrote:

> Cullen,
> 
> Did we decide to explicitly not support forking which generates multiple final answers? If this is not the case, how is this supposed to be implemented using your model?

I think that it is critical that we support what is needed to make a call that goes to 1-800-go-fedex work. So 
consider the following use case: A browser calls through a signaling GW to a sip that forks the call to an SIP to PSTN gateway and also to a voicemail server. The PSTN gateway generates an 180 with ringback tone but the SIP call is eventually answered by the voicemail server that sends a 200. 
 
So 3264 supports forking by an single offer may result in say two answers. In the case above, an single offer resulted in two different answers. Roap would support this type of transaction by allowing two answers to be received. There are two ways this can happen - one is with different answererSessionId in the the answers. Another is the use of the More-coming flag. We think with these, one can support the range of what 3264 allows for offer/ answer.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 Oct 2011 11:42:08 -0700

People mean different things by realtime but when talking about it, I think it is important to keep in mind it is mostly the media that needs to be realtime and perhaps the signaling to set up such media is not as does not have the same level of constraints.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Oct 2011 20:47:45 +0200

> People mean different things by realtime but when talking about it, I think it is important to keep in mind it is mostly the media that needs to be realtime and perhaps the signaling to set up such…

Yes, but it's not just about signaling realtime. HTTP polling means
unnecesary traffic from client to server. In the other side, WebSocket
(bidirectional communication without polling) allow the server
communicating to the client when it has something to say.

Also I expect that WebSocket will be very common and extended the day
RTCweb becomes a reality.

Regards.

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

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 19 Oct 2011 00:30:29 +0530

Cullen,

Thanks for the clarification about ROAP dialog stateful in signaling
gateway & Session-id usage.  Please update this information in the next
revision. 

Thanks
Partha

>From: Cullen Jennings [mailto:[email-masked]]
>Sent: Wednesday, October 19, 2011 12:12 AM
>Cc: [email-masked]; [email-masked]; Jonathan Rosenberg
>So I might have messed up the draft a bit. I'm fine with things can be
>implemented as dialog statefull, what I want is that it is possible to
>make a signaling gateway that is only transaction statefull. I'm fine
if
>some signaling gateways are built as dialog statefull.
>
>My personal opinion is that to be able to clean up all the state in a
>clean an easy way, we should add some message to indicate the SDP offer
>/ answer state and related media streams can be discarded.  I'd like to
>add that to the next version.
>
>
>> Thanks
>> Partha
>>
the

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 Oct 2011 12:02:21 -0700

> So, while I support and offer/answer based approach, I think we need to get a clearer understanding of the scope.

My view is this is draft is a set of semantics and syntax that operates over an abstract transport protocol. In most cases the transport with be web sockets or HTTP based. If this looks like a reasonable protocol, it would be likely to influence the W3C API. I'm not really sure how to clear up the scope. I'm just not sure what the scope is I need to clear up.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 18 Oct 2011 12:25:06 -0700

> communicating to the client when it has something to say.

All I'm trying to say is that I think there will be applications that use websockets and there will be applications that don't - they will have different impact on servers and performance. There are plenty of web based IM systems operating today that get pretty good performance without websockets. Clearly websockets will have a bunch of desirable features for this sort of signaling.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 18 Oct 2011 21:33:21 +0200

> People mean different things by realtime but when talking about it, I think it is important to keep in mind it is mostly the media that needs to be realtime and perhaps the signaling to set up such…
The "overview" draft has the following definition:

    Real-time media:  Media where generation of content and display of
       content are intended to occur closely together in time (on the
       order of no more than hundreds of milliseconds).

The omission of a definition for "real-time" without "media" is not an 
accident; I don't think a consensus definition exists, and I don't think 
we need that term in our work.
>> 2011/10/18 Magnus Westerlund<[email-masked]>:

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Oct 2011 21:44:06 +0200

> When one side sends and answer that says it wants to receive VP8 instead of H.264, it's probably useful to know when the other side got that information. This might impact the timing of when o send…

Hi Cullen. Let me put an example:

- alice: JS client implementing pure SIP over WebSocket.
- A proxy implementing SIP over UDP and WebSocket.
- bob: SIP UDP client.

The flows:

- alice sends INVITE to bob with an empty body (no SDP).
- bob replies a 200 with the SDP offer.
- alice receives the 200. Its JS code internally generates a ROAP Offer.
- alice generates a ROAP Answer and inserts its SDP into an ACK to be
sent to bob.
- In SIP we have ended. So how is supposed alice will receive the ROAP
OK message?

I don't understand yet if such ROAP OK message is mandatory to be sent
to the RTCweb stack. If so, the JS code in alice could auto-generate
it after sending the ACK, so the RTCweb stack becomes happy. But
obviously the advantage of such auto-generated ROAP OK is null.

Regards.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Oct 2011 07:00:20 +0200

[Admin note: Please keep discussion of ROAP details on the rtcweb list, 
not on both lists.]

On 10/18/2011 09:44 PM, Iñaki Baz Castillo wrote:
> 2011/10/18 Cullen Jennings<[email-masked]>:
The entity that knows about the mismatch between ROAP and SIP message 
sequences will have to generate it. In your hypothetical scenario - alice.

---

From: Stefan Håkansson <[email-masked]>
Date: Wed, 19 Oct 2011 09:41:24 +0200

Speaking strictly as an individual (I'm in the same organization as 
Magnus, so if that means that this input has less weight so be it):

I think this discussion got a bit off track.

In the ROAP draft glaring is resolved by backing off and waiting in the 
order of seconds.

Magnus proposes another solution that resolves glaring immediately (no 
need to wait). I think this is a really good idea, especially in the 
light of that the current API proposal allows each endpoint to 
asynchronously add streams (for transmission to the other endpoint) at 
any time. This means that glaring conditions could be quite common.

Why should we design something that delays the start of those streams 
quite some time when it easily can be avoided?

Then there could (or not) be situations where the back-off resolution 
does not work at all, but I think a more efficient glaring resolution 
mechanism makes sense regardless.

(NB: If there are other ways to resolve glaring without delay I'm all 
for it, I just want to avoid that glaring would delay steam set up 
unnecessarily)

Stefan

---

From: Stefan Håkansson <[email-masked]>
Date: Wed, 19 Oct 2011 09:52:19 +0200

On 10/18/2011 06:07 PM, Roman Shpount wrote:
> On Tue, Oct 18, 2011 at 9:57 AM, Stefan Håkansson LK
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     What I mean is: if this web app has already created a
>     PeerConncection, and is about to open another one (e.g. for a new
>     fork), the new PeerConnection should use the same local candidates
>     as the one already created collected.
>
>
> What would happen if new PeerConnection has a different set of
> codecs/media streams? Do we just add/remove local candidates based on
> how many different streams are needed?

Now we're getting into the stuff that is not my home turf :). But as I 
understand it, the current assumption is that the browser would in fact 
only open one port which all RTP streams use. In most cases all streams 
would be multiplexed over the same 5-tuple, but the other end (if it is 
not a browser) could open separate ports for each RTP stream, if it 
(read legacy) would like to avoid multiplexing.

This means that when the first PeerConnection is set up it would gather 
candidates (host, srflx, ...) for one port only; my idea is that these 
candidates would be re-used if a second PeerConnection is created.

Codecs and media streams would be negotiated per PeerConnection.

I hope this is roughly right, not my home turf as said.

>
> Overall I do like this idea since it not only addresses the forking
> issue, but suggest a good resource usage policy.
> _____________
> Roman Shpount
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Oct 2011 10:20:42 +0200

On 10/19/11 09:52, Stefan Håkansson wrote:
> understand it, the current assumption is that the browser would in 
> fact only open one port which all RTP streams use. In most cases all 
> streams would be multiplexed over the same 5-tuple, but the other end 
> (if it is not a browser) could open separate ports for each RTP 
> stream, if it (read legacy) would like to avoid multiplexing.
Actually my current understanding is that in all cases, all video 
components of all MediaStreams would use the same RTP session, and all 
audio components of all MediaStreams would use the same RTP session.

If the TOGETHER extension (draft-alvestrand-one-rtp) or BONDING 
extension (next version of 
draft-holmberg-mmusic-sdp-multiplex-negotiation; the name changed) is 
supported, both media types would be sent across one RTP session.

The word "multiplexing" is awfully confusing; at least Holmberg and I 
have concluded that it's better for communication if we don't use it.
>
> This means that when the first PeerConnection is set up it would 
> gather candidates (host, srflx, ...) for one port only; my idea is 
> that these candidates would be re-used if a second PeerConnection is 
> created.
With a caveat  ....

note that the parameters passed to the constructor of PeerConnection 
(STUN/TURN server) will affect the candidate sets, so if those change, 
the cached candidates cannot be used.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2011 11:35:32 +0200

Hi,
 
>> Now we're getting into the stuff that is not my home turf :). 
>> But as I understand it, the current assumption is that the browser would in 
>> fact only open one port which all RTP streams use. In most 
>> cases all streams would be multiplexed over the same 5-tuple, but the 
>> other end (if it is not a browser) could open separate ports for each RTP 
>> Actually my current understanding is that in all cases, all 
>> video components of all MediaStreams would use the same RTP 
>> session, and all audio components of all MediaStreams would 
>> use the same RTP session.
> 
> If the TOGETHER extension (draft-alvestrand-one-rtp) or 
> BONDING extension (next version of draft-holmberg-mmusic-sdp-multiplex-negotiation; 
> the name changed) is supported, both media types would be sent across 
> one RTP session.

Actually, BUNDLE is the name of the new extension :)

Due to the name change of the extension, the name of the draft has also changed.

The name is now: draft-holmberg-mmusic-sdp-bundle-negotiation-00.

http://www.ietf.org/id/draft-holmberg-mmusic-sdp-bundle-negotiation-00.txt

Note that Harald is now co-author of the draft.

Regards,

Christer

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 19 Oct 2011 12:05:02 +0200

> the cached candidates cannot be used.

That's right.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2011 14:21:27 +0200

Hi Cullen, 

>> So, while I support and offer/answer based approach, I 
>> think we need to get a clearer understanding of the scope.
> 
> My view is this is draft is a set of semantics and syntax 
> that operates over an abstract transport protocol. In most 
> cases the transport with be web sockets or HTTP based. If 
> this looks like a reasonable protocol, it would be likely to 
> influence the W3C API.

As the ROAP state machine is located in the browser, doesn't that already mean that ROAP must to be supported by the API?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2011 14:30:01 +0200

Hi,

Section 5.3.1.2 lists cases where an answerer can receive an OFFER.

I guess the following case is also valid, and shall not be rejected.

- A retransmit of a request to change media parameters (known offererSessoinId, known answererSessionId, known seq value).

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2011 14:49:44 +0200

Hi,

What is the relation between the seq/sessionId values and the SDP sess-version/sess-id values (part of the SDP o= line), and why do we need seq/sessionId in the first place?

AFAIK, the only reason for having the seq/sessionId values is when sending an OK message, since there will be no SDP (and therefor no SDP sess-version/sessionId). Or, are there any other reasons?

I think the draft should say something about the correlation.

And, IF we need seq/sessionId, should we say that the SDP sess-version/sess-id values must be identical - or, at least saying that they must be set and incremented according to the SDP rules? I think that would help in SIP/SDP interworking cases. Otherwise the interworking gateway will have to check, keep track of, and possibly modify, the sess-version/sess-id values.

Regards,

Christer

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: 15. lokakuuta 2011 6:09
> Jonathan and I submitted a new draft on setting up media 
> based on the SDP Offer/Answer model. The ASCII flows are a 
> bit hard to read so until I update them, I recommend reading 
> the PDF version at 
> 
> particularly on if this looks like generally the right 
> direction to go. 
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2011 15:06:20 +0200

Hi,

A couple of questions regarding the usage of the more-coming flag:

Q1. If one sends an ANSWER with the more-coming flag set to 'true', is it allowed to later send *additional* ANSWER(s) with the flag set to 'true' (before sending the final ANSWER)?

Q2. Are there restrictions when it comes to changing information in a non-final answer and a final answer? Or, can the final answer be completely different from previously sent non-final ANSWERS? In "legacy" O/A there are restrictions.

Q3. Must the answerer wait for OK for a non-final ANSWER before sending a new ANSWER (non-final or final)?

Q4. If the answer to Q3 is "no", how does the answerer know to which ANSWER an OK message applies? AFAIK, the seq/sessionId values are identical for all ANSWERs associated with a specific OFFER.

Q5. The text says, that while the OFFER is "open", ie a final ANSWER has not been sent, the answerer is not allowed to send an OFFER. I assume that also applies to the offerer, ie it is not allowed to send a new OFFER until it has received a final ANSWER - even if it has received one or more non-final ANSWERs. Maybe it's obvious, but I think it would be good to explictily add some text about that (if my assumption is correct, that is :).

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Oct 2011 16:04:55 +0200

Hi, 

>> Did we decide to explicitly not support forking which 
>> generates multiple final answers? If this is not the case, 
>> how is this supposed to be implemented using your model?
> 
> I think that it is critical that we support what is needed to 
> make a call that goes to 1-800-go-fedex work. So consider the 
> following use case: A browser calls through a signaling GW to 
> a sip that forks the call to an SIP to PSTN gateway and also 
> to a voicemail server. The PSTN gateway generates an 180 with 
> ringback tone but the SIP call is eventually answered by the 
> voicemail server that sends a 200. 
>  
> So 3264 supports forking by an single offer may result in say 
> two answers. In the case above, an single offer resulted in 
> two different answers. Roap would support this type of 
> transaction by allowing two answers to be received. There are 
> two ways this can happen - one is with different 
> answererSessionId in the the answers. Another is the use of 
> the More-coming flag. We think with these, one can support 
> the range of what 3264 allows for offer/ answer. 

- Assume my browser is communicating with a SIP gatway, and I use some non-SIP signalling protocol to transport ROAP messages between the browser and the gateway.

- The gateway maps ROAP into SIP, and a proxy forks the INVITE to multiple SIP UAs.

- When the gateway receives reliable 18x provisional responses, on different early SIP dialogs, it forwards them as final ANSWERs towards the browser.

- When the gateway receives the 200 OK, all other early dialogs are terminated. Now, from a pure ROAP perspective, the only way to inform the browser about that would be for the gateway to send new OFFERs for every terminated early SIP dialog, and e.g. indicate port=0.

Correct?

Now, instead of mapping the 18x provisional responses to final ANSWERs, the gateway could of course map them to non-final ANSWERs, and then later send final ANSWERs with an error code. But, the problem then is that the browser is not able to (or, at least that's my assumption - see separate e-mail) send a new OFFER until it has received a final ANSWER.

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Oct 2011 15:22:57 -0600

> - A retransmit of a request to change media parameters (known offererSessoinId, known answererSessionId, known seq value).

yes - we should make it clearer but this is case 2 where we have known offererSessoinId, known answererSessionId and since we have seen the seq before, it is a retransmission

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Oct 2011 18:40:24 -0600

inline but yes, your understanding is what I was thinking 

> - When the gateway receives the 200 OK, all other early dialogs are terminated. Now, from a pure ROAP perspective, the only way to inform the browser about that would be for the gateway to send new…

yes - I think that port=0 is the wrong way to indicate these have ended as it is confusing with hold and ending a particular media stream vs ending an offer/answer session. So this makes the argument for a better way to clean up state on the ROAP side. 

> Now, instead of mapping the 18x provisional responses to final ANSWERs, the gateway could of course map them to non-final ANSWERs, and then later send final ANSWERs with an error code. But, the pro…

Yes - we have the same understanding of how with would work.  I imagine this would be the path most things takes. I don't see uses case where needing to send a new OFFER before receiving the final ANSWER would be a problem.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Oct 2011 18:41:30 -0600

all good questions and I should clarify in the draft … inline

> Q1. If one sends an ANSWER with the more-coming flag set to 'true', is it allowed to later send *additional* ANSWER(s) with the flag set to 'true' (before sending the final ANSWER)?

Yes 
> Q2. Are there restrictions when it comes to changing information in a non-final answer and a final answer? Or, can the final answer be completely different from previously sent non-final ANSWERS? I…

Any answer has to be a valid answer for the offer but other than that, no restrictions, so the final answer can change everything from an earlier one. 

> Q3. Must the answerer wait for OK for a non-final ANSWER before sending a new ANSWER (non-final or final)?

hmm - not sure :-)  I think the answer to needs to be yes but we should think about this and work through the design choices. 

> Q5. The text says, that while the OFFER is "open", ie a final ANSWER has not been sent, the answerer is not allowed to send an OFFER. I assume that also applies to the offerer, ie it is not allowed…

yes - agree.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Oct 2011 18:43:39 -0600

> As the ROAP state machine is located in the browser, doesn't that already mean that ROAP must to be supported by the API?

This whole "is this an API or Protocol discussion" leaves me sort of saying "Yes" but I'm not sure it matters much. Any API can be turned into a protocol using a RPC approach. Most protocol lead to a fairly obvious API to describe that protocol. From a category theory point of view, I consider an API the dual of a protocol. I know opinions differ but in general, I view API's and protocols as surprisingly similar. 

ROAP is a protocol that could be used to things like a gateway that converted from ROAP to SIP.  However, it is also a protocol that is designed to work well with an API like one that might be used by W3C for WebRTC. If we go down this ROAP path, I would expect that the the JSON object that gets represented by the string in ROAP would be used to pass in the WebRTC API. The two are closely related - and that is intentional. 

I'm trying to make a protocol that closely fits with what the web browsers want to implement.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Oct 2011 18:43:52 -0600

I guess the question I am thinking about is how important is this use case. I'm a bit of the fence on the topic.  The primary use of INVITE with no offer is when doing a gateway to some forms of  H.323. It seem the odds of a gateway from RTCWeb to SIP to H323 is pretty low so I have not been thinking about how to deal with INVITE with no offer much.  I should think about it more but too few hours in the day :-)

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 19 Oct 2011 17:55:30 -0700

On 10/19/2011 05:43 PM, Cullen Jennings wrote:
>>>> So, while I support and offer/answer based approach, I think we need to
>>>> get a clearer understanding of the scope.
>>> 
>>> My view is this is draft is a set of semantics and syntax that operates
>>> over an abstract transport protocol. In most cases the transport with be
>>> web sockets or HTTP based. If this looks like a reasonable protocol, it
>>> would be likely to influence the W3C API.
>> 
>> As the ROAP state machine is located in the browser, doesn't that already
>> mean that ROAP must to be supported by the API?
> 
> 
> This whole "is this an API or Protocol discussion" leaves me sort of saying
> "Yes" but I'm not sure it matters much. Any API can be turned into a protocol
> using a RPC approach. 

I disagree here.

http://labs.oracle.com/techrep/1994/abstract-29.html

> Most protocol lead to a fairly obvious API to describe
> that protocol. From a category theory point of view, I consider an API the
> dual of a protocol. I know opinions differ but in general, I view API's and
> protocols as surprisingly similar.
> 
> ROAP is a protocol that could be used to things like a gateway that converted
> from ROAP to SIP.  However, it is also a protocol that is designed to work
> well with an API like one that might be used by W3C for WebRTC. If we go down
> this ROAP path, I would expect that the the JSON object that gets represented
> by the string in ROAP would be used to pass in the WebRTC API. The two are
> closely related - and that is intentional.
> 

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 19 Oct 2011 20:07:24 -0600

> http://labs.oracle.com/techrep/1994/abstract-29.html

Good point and nice paper. Perhaps I should have said an API can be turned into a really bad protocol using an RPC approach :-)

---

From: Randell Jesup <[email-masked]>
Date: Wed, 19 Oct 2011 23:07:55 -0400

On 10/19/2011 8:43 PM, Cullen Jennings wrote:
>
> I guess the question I am thinking about is how important is this use case. I'm a bit of
 > the fence on the topic.  The primary use of INVITE with no offer is 
when doing a gateway
 > to some forms of  H.323. It seem the odds of a gateway from RTCWeb to 
SIP to H323 is
 > pretty low so I have not been thinking about how to deal with
 > INVITE with no
 > offer much.  I should think about it more but too few hours in the 
day :-)

The primary use of bare INVITE in SIP I've seen is for an SBC to force a 
renegotiation by the two sides:

A                        SBC                        B
| <-------------------- media --------------------> |
| <--- INVITE w/o SDP --- |                         |
| ----- 200 OK w/OFFER -> |                         |
|                         | ------ INVITE w/OFFER-> |
|                         | <--- 200 OK w/ANSWER -- |
| <---- ACK w/ANSWER ---- |                         |
|                         | -------- ACK ---------> |
| <--------------------- media -------------------> |

This can let the SBC modify things in the process (like move media
relaying to a new IP/port, change hold state), and other 3PCC things.

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 20 Oct 2011 03:30:49 +0000

> I guess the question I am thinking about is how important is this use case. I'm a bit of the fence on the topic.  The primary use of INVITE with no offer is when doing a gateway to some forms of  H…

Ummm... you do realize the number one generator of offerless INVITEs by a fairly wide margin is a popular product made by a company on Tasman Drive in San Jose, with a domain name like the one in your email address, right?  
:)

Or at least it was the last time I checked the Billboard charts for Top-10 offerless INVITE generators.

-hadriel

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Oct 2011 12:25:05 +0200

Hi, 

>> - A retransmit of a request to change media parameters 
>> (known offererSessoinId, known answererSessionId, known seq value).
> 
> yes - we should make it clearer but this is case 2 where we 
> have known offererSessoinId, known answererSessionId and 
> since we have seen the seq before, it is a retransmission 

Agree.

Regards,

Christer