[asterisk-dev] astobj2 and chan_sip; first results... wanna test drive it?
murf at digium.com
Mon Jan 7 11:35:08 CST 2008
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.
> > 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...
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20080107/6f800121/attachment.bin
More information about the asterisk-dev