[asterisk-dev] how does a channel driver know the result of codec negotiation ?

[Olle E Johansson]

16 okt 2007 kl. 21.27 skrev Kevin P. Fleming:

> Luigi Rizzo wrote:
>
>> Anyways, what would be wrong with the obvious solution of notify
>> the caller's channel driver once the remote party reports supported
>> formats ?  I don't know exactly if we already have a suitable
>> callback in struct ast_channel_tech but given the abundance of
>> entries there i suppose one more wouldn't harm too much.
>
> There are multiple potential issues that get involved here.
>
> The first is that you say when 'THE remote party'... but there  
> could be
> many remote parties, since an outbound dial operation can call  
> multiple
> endpoints. If we ever decide to support SIP forking, then it gets  
> worse,
> because dialing a single SIP endpoint could result in more than one
> temporary dialog (until one of them answers).
Only one answers though. So that doesn't really matter. If a second one
answers, we just have to ignore it.
If you are thinking about a future advanced bridge turning this into
a conference call, then we might have other issues.

>
> The next issue is one of 'control', or handling preferences,  
> especially
> when there are multiple Asterisk servers in the chain of the call. If
> party A places a call through one server, then through another server,
> then to party B, how is this 'format list' going to get  
> communicated all
> the way back to party A, or should that even happen?
Interesting issue.

>
> These issues are hard to deal with well and provide an understandable
> solution to the end users, and they aren't even involving the  
> technical
> (implementation) aspects yet. It's just not an easy problem to solve.

I guess we need to test scenario two on videocaps to see what is  
happening.

If server A calls server B and server B calls C and D and D answers.  
The issue
is that the answer from D needs to be communicated all the way back  
to A.
I don't see the problem, but since you point at this issue, we need  
to test it.

This is the same issue that forced me to disable Mark's quick-and-dirty
fix for call setups without re-invites.
/O