[Telepathy] Media API redesign for SIP SOA and ICE

[mikhail.zabaluev at nokia.com]

Hi Olivier,

It's my understanding, too, that the proposed changes are not for short-term modification of Farsight.

See my answers below.

>-----Original Message-----
>From: telepathy-bounces at lists.freedesktop.org 
>[mailto:telepathy-bounces at lists.freedesktop.org] On Behalf Of 
>ext Olivier Crête
>Sent: Tuesday, June 12, 2007 11:10 PM
>To: telepathy at lists.freedesktop.org
>Subject: Re: [Telepathy] Media API redesign for SIP SOA and ICE
>
>> - 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.
>
>Do you know if there is any requirement for the stream to keep its RTP
>properties when the candidates is changes? (ie, can't we just create a
>completely new stream?).

There is no strict prohibition against that, however:
1) It's better for call stability when only one side changes ports at a time. 
2) We'd have to open new sockets, create a new set of codec pipelines duplicating the old one in most cases, deal with shared access to the media sinks, all things consuming resources and failure-prone.
3) Multiplication of streams complicates things for the client, unless we somehow hide new streams under negotiation from the media channel API clients.

>> - 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. 
>
>My reading of the SDP Offer-Answer stuff was that there could be a
>single negotiation going on at one time.

A SOA session is a per-dialog thing, and an outgoing call leg constitutes a dialog for the caller.
Same goes, IIRC, for ICE process which is always tied to one SOA session.

>As for the SIP provisional
>responses, can't you just create multiple streams with remote 
>candidates
>but no remote codecs and set_sending to false (so the streams don't try
>to send anything). And maybe something to prevent them from actually
>receiving any data.

That's possible, but see the points 2) and 3) above.

-- 
  Mikhail