[Telepathy] Media API redesign for SIP SOA and ICE

[mikhail.zabaluev at nokia.com]

Hi,

I've been thinking over the mapping of the StreamHandler and related APIs to semantics required for SDP Offer-Answer and ICE.
There are a few problems with the current interfaces:
- There is no good way to change the effective set of codecs and effective transport addresses all at once for a stream, which is required by SOA specification on session updates.
- Similarly, there is no good way to roll back the stream state if an update offer gets rejected by local or remote party.
- No clear way to implement forking with several provisional responses arriving from different endpoints, each potentially carrying an SDP answer. Until a 200 response arrives, the implementation cannot assume which session will finally be accepted, but it must at least respond to incoming ICE checks for every session. 
- There is no obvious way to change the NAT traversal behavior within one session, for example, if ICE derails in SIP signaling. Stretching the semantics of remote candidate data might help by saying empty user/password means no more ICE, but it's still a hack and the meaning of "nat-traversal" property gets a bit murky here.
- There is no clear way to initiate an ICE restart on the peer's demand.

To alleviate these problems, here's my sketchy proposal for the next major redesign of the Telepathy specification and, by necessity, the Farsight API.
Make another interface for a new kind of objects that will host on a StreamHandler and give them (quasi-)transactional semantics for stream state that needs to be negotiated with the remote peer. Here I will call this new entity a stream negotiation.
- The connection manager will signal creation of a new stream negotiation through the StreamHandler interface, meaning that a new negotiation of the media stream's properties is in progress, without changing the effective transports and the effective remote codec set of the media stream. Multiple negotiations can exist per stream at the same time, however, their remote addresses shall in theory be different -- this covers the case of forking.
- All methods and signals of StreamHandler related to the remote or otherwise negotiable stream state will be moved to negotiations. Pending direction changes would likely also be considered a part of the negotiation.
- Negotiations will have signals for the connection manager to accept or reject the negotiation. An accepted negotiation means taking the whole negotiated state into effect for the media stream. A rejected negotiation instructs to continue with the currently effective state. The negotiation object can be destroyed after emitting either of the two final signals.
- "Reject" method can also be provided for the stream engine to signal rejection of the negotiation process, e.g. if there is no codec intersection or ICE has failed for the supplied list of remote candidates.
- "nat-traversal" and related properties will migrate here from MediaSignaling.


While we are at it, there is a discrepancy between ICE signaling and Telepathy data structures for candidates, which will raise its head when Farsight implements RTCP.
A Telepathy "candidate ID" can be mapped to an ICE "foundation ID", and ICE candidates for different components of a media stream (i.e. RTP and RTCP ports) belonging to the same foundation would come as transports for one Telepathy candidate. The problem with this straightforward mapping is, ICE may come up with nominated candidate pairs for different components not belonging to the same combined foundation and hence having different ID pairs, and NewActiveCandidatePair method is unsuitable for this situation, unless we come up with some other mapping. ICE, for its part, uses component-address-port tuples to signal selected candidates to the peer.


Thoughts?

-- 
  Mikhail Zabaluev,  Nokia Multimedia