ROAP/API question: Generation of (and purpose of) answererSessionID?

I think this is an API question, so I'm using public-webrtc for it....

in the ROAP draft, the current text says (section 5.3.1.2):

    o  Reply to the OFFER message with a final ANSWER message; or
       Section 5.3.2
    o  Send back a non final ANSWER message and then later respond with
       an final ANSWER.

    In either of the latter two cases, the answerer performs the

    1.  Generate a "answererSessionId" value;
    2.  Create some local call state (i.e., a PeerConnection object) and
        bind it to the "offererSessionId"/"answererSessionId" pair.  All
        future messages on this session MUST then be delivered to that
        PeerConnection object;

It's not clear to us how this maps to the JS API.
two possibilities:

1) the JS creates some answererSessionID value, puts that into the ROAP 
message, and passes it to the PeerConnection object

2) the JS passes the ROAP message to the PeerConnection object, and the 
PeerConnection object populates the answererSessionID.

Which was the intended reading?
In the second case, the JS may have to extract the answererSessionID 
from the PeerConnection object through some API. (It could inspect the 
answer message, but that's not-so-nice).

This actually brings up a related question:

Why do we need answererSessionID?

It seems that in the normal case, the answerer might as well index its 
table of PeerConnections off offererSessionID; there is no case where an 
answerer needs to keep track of two PeerConnection objects with the same 
offererSessionId value. Similarly, the offerer presumably sends all 
responses with the same offererSessionId to the same PeerConnection object.

It would be good if we could get examples into the draft where each 
field is clearly needed.

(BTW, it's not clear from section 5.4 what an answerer puts into 
offererSessionId and answererSessionId fields when it generates an offer 
in order to change session values.)

Received on Monday, 7 November 2011 11:12:08 UTC