[asterisk-dev] astobj2 and chan_sip; first results... wanna test drive it?

[Johansson Olle E]

7 jan 2008 kl. 18.35 skrev Steve Murphy:

> On Sat, 2008-01-05 at 12:51 +0100, Johansson Olle E wrote:
>>>>
>>>
>>> Olle--
>>>
>>> I wish you absolute best of luck in your search for funding. I'm
>>> painfully aware of how stressful such efforts can be.
>> Thanks.
>>>
>>>
>>> I'd love to discuss some of the options with you, if you get a free
>>> moment. Until then, I have a few questions:
>>>
>>> 1. on dialog matching-- if headers and tags are to be used for
>>> matching
>>> multiple dialogs with the same callid, how often would this happen  
>>> in
>>> the course of "normal" activity, and how many such dialogs (with the
>>> same callid) would normally exist; how many **COULD** exist? I'm  
>>> going
>>> to try to read the sip spec so I can understand the whole dialog
>>> "thing". I'm not looking forward to it.
>>
>> Well, if you just have a few SIP phones connected on a lan directly
>> to Asterisk, it will never happen.
>>
>> If you have a stateful forking SIP proxy, it may happen in many
>> different ways. I'll try to write down a document of the scenarious
>> I've seen in testing. The most interesting way, and propably
>> something that happens now and then, is when a SIP proxy
>> forwards a call back to asterisk.
>>
>> To give you some food for thought:
>>
>> Let's say we have an outbound SIP call from Asterisk,
>> adressed to a SIP proxy. The SIP proxy forks back to
>> Asterisk for Voicemail after 30 secs so we have an
>> incoming call with the same call ID as an outbound
>> and it's not a loop. The other branch of the call goes
>> to a cell phone, so that branches back to Asterisk to
>> be forwarded over ZAP somewhere. Now we have
>> three SIP calls in Asterisk with the same call ID and
>> something that is very likely that it will happen.
>>
>> Other than that, there are some theoretical scenarious that
>> may happen with non-stateful SIP proxys that we do test at
>> SIPits, but I haven't seen in any bug reports. THe case above
>> has been covered in bug reports.
>>
>> When we redesign, we should try to fix it once and for all.
>> I'll start writing :-)
>
> So, these scenarious seem to suggest that in those cases where we'd be
> likely to see multiple dialogs with the same callid, the numbers of  
> such
> duplicates would usually be quite small. Say, 2 or 3 or 4 or  
> something?
>
> If so, then just using a singly-linked list of all duplicates off the
> first dialog wouldn't be a bad approach. But if the number can be  
> dozens
> or more, then perhaps another (small) hash table would be  
> appropriate...
> It sounds kinda extreme, I know, but...

I suggested a linked list earlier. This only happens in larger  
infrastructures
with SIP proxies, and then there's usually a limited number of  
simultaneous
requests with the same call-id, and as Klaus said, only for a limited  
amount
of time since you close most of them when one's answered.

/O