[asterisk-dev] Notify with Caller ID

[Johansson Olle E]

5 nov 2008 kl. 00.58 skrev Sean Bright:

> Johansson Olle E wrote:
>> Sean,
>>
>> Implementing a channel walk for each notify was exactly the reason  
>> why
>> we have
>> not accepted all the patches for SNOM pickup... I don't really agree
>> with this,
>> unless there has been huge changes to channel walks.
>
> Agreed, that is why I made it optional (and it defaults to being  
> off).  Also, I
> just introduced another patch that should improve the channel search  
> a bit to
> make it more efficient (based on your feedback, as well as Russell  
> and Kevin's).
Even with optional, I don't like to commit it since we know it will  
kill the server
as the server grows. Reasoning that "it might work in small volume  
servers"
is a new concept in Asterisk. People will use it and their high-volume  
systems will break
and they will blame us. But hey, it's there. Not worth arguing about  
any more.
As I said, there are bigger issues to solve in the SIP channel.

>
>
>> We have to get the information from the source, the sending channel,
>> instead of retrieving it in the actual notify. There's a couple of  
>> items
>> we want to add as attachments in that case, so we might want to
>> discuss this.
>
> Yeah, one of the original patches (I don't remember which one)  
> modified the
> extension state callbacks to pass along the CID name and number of  
> the channel
> that caused the subscribed extension to change states.  It seemed a  
> little
> short-sighted to me in that there might be many data points we would  
> want access
> to on the subscribed side of things and I just saw that spiraling  
> out of
> control.  Not to mention the case where there are multiple callers  
> causing an
> extension to ring.  As Russell pointed out, this will require some  
> architectural
> changes to how extension states are currently handled.  Do you have  
> any thoughts
> to get us moving in the right direction?
Well, since SIP is the most detailed consumer, it's quite easy to look  
into the standards
and find out. My work, which is the one I think you refer to, is  
hidden deep down in
my forest of branches, was for sending the AST call ID or the SIP call- 
ID to enable pickup.
Later, we figured out it was better to search for that at a later stage.
You need Caller IDs. I guess we just have to check the schema and see  
what more there is.

The issue you point to is the problem with two calls. Well, the SIP  
standard handles
that as long as we get the data. Not many phones would handle it  
properly (I guess),
so we should propably only send data for the call that we would pick up.

>
>
>> If this code was in the bug tracker, I would not accept it for the
>> same reasons
>> we did not accept the SNOM pickup code.
>
> It was there for abouot a day before I committed it.
>
>    http://bugs.digium.com/view.php?id=13827
>
> I'm sorry you didn't get a chance to review it.

Well, that's the problem when I can't be working with the bug tracker  
every day. I can't
blame you for going ahead, just say that if I caught it I would have  
not accepted it (like I said).

Thanks for the kind feedback!

/O