[Asterisk-Users] New Asterisk bounty: SIP simultaneous

[Andy Powell]

On 13/07/2004 at 11:48 Martin List-Petersen wrote:

>I can see the point of the discussion somewhere, but let's take it the
>other way around (comments though mail):
>
>On Tue, 2004-07-13 at 08:53, Olle E. Johansson wrote:
>> > You have not shown us ANY example yet for which this
>> > facility is *NEEDED*.
>> > 
>> Well, I have users that get an account on my PBX.
>> 
>> I really don't care how many phones they want to use, hardware phones on
>> their desktop or soft phones on their laptop while travelling. It's
>still a user
>> with one account. When the PBX dials them, all their phones should ring.
>
>Now .. the problem is, that every hardware phone, every softphone etc.
>actually might need a different configuration, some IAX, some SIP, some
>one codec, some other codecs (now that we are talk asterisk). It will
>get quite problematic to get all solutions under one account without
>breaking one or the other.

Yes, this is a problem I''d forsee...


but ignoring that for one moment :P....


Imagine that asterisk accepts multiple registrations for a single entry in sip.conf ([myphone]) simply
adding each to an internal variable:

The first phone registers:

WHO_I_DIAL = "sip:andy at 192.168.1.70"

then joe comes along and also registers a line on his phone

WHO_I_DIAL = "sip/andy at 192.168.1.70&sip/joe at 192.168.1.71"

now when I execute a dial, asterisk internally replaces the occurrence of myphone with the
WHO_I_DIAL variable:

eg:

Dial(SIP/myphone,120)

becomes (internally)

Dial(WHO_I_DIAL,120)

In essence DIAL sees nothing different at all and doesn;t need to be changed because the internal reference
SIP/myphone actually = the content of WHO_I_DIAL

So what we affectively achieve is:

Dial(sip/andy at 192.168.1.70&sip/joe at 192.168.1.71,120)

Which is what people have been saying everyone should do... but this process becomes automatic, which
is a feature that people want.

I'm pretty sure you'd do this with an array rather than a string, but I think it explains the theory
behind it all.

Of course I've ignored the issue with different configs required for different SIP devices (eg DTMFMODE=),
but that artistic license ;)


I may have explained it badly, so let me know


Andy