asterisk users - Jul 2004 - New Asterisk bounty: SIP simultaneous

>When I call a SIP user, the phone should ring in more
than one
>extentions. Also more than one phone should be able to
register with
>asterisk. Right now it is not the case.
There is no issue here. You seem to be confused, that's
all.

A SIP account is a SIP account and an extension is an
extension. You can assign an extension to an account (or
to multiple accounts) and the tool for that is the dial
command.

However, there is no implicit assignment between an
extension and an account and that is good so. This should
not be changed because it would harm Asterisk's
flexibility and manageability.

>This type of situations might be needed in call centres.
>
>Called 12345
>            |-----------(12345) Ringing
>            |-----------(12345) Ringing
>            |-----------(12345) Ringing
As I said, you are confusing extensions with accounts. The
first "12345" is an extension, the three "(12345)"s are
accounts. Those are different layers, don't mix them up.

You should always be able to distinguish between devices,
even if they are assigned the same phone number. In fact,
in a call centre you'd be using a call queue. It would be
rather nonsensical for a call queue management to have to
distinguish between multiple identical agents.

Therefore, setting up multiple devices with the same
account credentials is not a good idea, especially not in
a call centre. Each device and each agent should have
their own unique account credentials and assigning
extensions to them should always be done through the
dialplan and only the dialplan.

Asterisk has been designed this way. It is a good design.
It should NOT be changed nor undermined.

You may want to do something like this ...

[GLOBALS]

A-GROUP => SIP/2001 & SIP2002 & SIP/2003

B-BROUP => SIP/jdoe & SIP/dflint & SIP/bsmith

...


[Support]

exten => 12345,1,Dial(${A-GROUP},30,r)
...

exten => 54321,1,Dial(${B-GROUP},30,r)
...


There is of course an issue when you want to let different
phones start ringing at different times, for example, the
first phone is supposed to start ringing immediately and
the other two are only to join in if the first phone
hasn't been picked up in 10 seconds, like so

exten => 12345,1,Dial(${JDOE},10,r)
exten => 12345,2,Dial(${JDOE}&{DFLINT}&${BSMITH},20,r)

This works but if JDOE was to pick up right between those
two dial commands, then it will have been too late for the
first and JDOE will be "on the phone" for the second dial
command, so there is some room for improvement. A bounty
might better be spent on solving this little problem.

Also, Asterisk supports call groups and pickup groups.
Indeed, there have been some bugs with those features and
I am not sure if they have have been fixed, but if they
haven't, then it would again make more sense to put the
bounty on fixing those rather than creating an ugly
workaround.

>I feel this is a great feature
I don't and if you spent some more time with Asterisk and
immerse its philosophy, then you'll very likely change
your mind.
>in other SIP proxy server this can be done easily
Asterisk is not a SIP proxy. It's a telephone exchange.
>i mean its default 1 or more phone could be registered
>at 1 number (12345) and resulting same effect
A phone does not register at a number. It registers at an
account to which Asterisk can assign one or more numbers.
This makes perfect sense and it is a far more flexible and
better design.

SIP proxies' auto assignment of extensions to SIP
usernames is a serious limitation, not an advantage.


The only situation where one might want to consider
supporting multiple concurrent logins on the same account
is for public VoIP service providers where end users might
have a SIP phone on their desk and use a softphone on
their notebook when they are traveling.

But here again, it is more likely to be a disadvantage.
Consider the following situation ...

1) Incoming call to 12345

2) both deskphone 12345 and road warrior's notebook 12345
ring

3) Secretary of Mr. 12345 picks up before he himself is
able to do so

4) Caller asks for Mr.12345 but secretary has no way of
trying to transfer the call

OTOH, Asterisk handles this situation much better ...

1) Incoming call to extension 12345

2) Dial command determines to ring both deskphone and road
warrior's notebook which are on different extensions

3) Secretary of Mr. Road Warrior picks up before he
himself is able to do so

4) Caller asks for Mr. Road Warrior, secretary transfers
to internal extension of road warrior notebook's softphone


I am sorry but your bounty doesn't seem to make sense. It
looks more like one of those "Wanted: problem for given
solution" cases.

rgds
benjk

__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/

I accept your views.

I have a specific requirements, can you help to attain the same.
In our business we have 25 employees handling customer service.

I want to add or remove employees in the customer service so does the
devices connected to it.
I don't want to make any changes in the asterisk, and all I need is to plug
in the VoIP Phone and start handling the customer service. I would like to
do for as many employees as I want without any problems.

Can you think of a better solution?

-Kannaiyan.

----- Original Message -----
From: "Sunrise Ltd" <stsltdtyo@yahoo.co.jp>
To: <asterisk-users@lists.digium.com>
Sent: Sunday, July 11, 2004 9:15 AM
Subject: Re: [Asterisk-Users] New Asterisk bounty: SIP simultaneous

> >When I call a SIP user, the phone should ring in more
> than one
> >extentions. Also more than one phone should be able to
> register with
> >asterisk. Right now it is not the case.
>
> There is no issue here. You seem to be confused, that's
> all.
>
> A SIP account is a SIP account and an extension is an
> extension. You can assign an extension to an account (or
> to multiple accounts) and the tool for that is the dial
> command.
>
> However, there is no implicit assignment between an
> extension and an account and that is good so. This should
> not be changed because it would harm Asterisk's
> flexibility and manageability.
>
>
> >This type of situations might be needed in call centres.
> >
> >Called 12345
> >            |-----------(12345) Ringing
> >            |-----------(12345) Ringing
> >            |-----------(12345) Ringing
>
> As I said, you are confusing extensions with accounts. The
> first "12345" is an extension, the three "(12345)"s are
> accounts. Those are different layers, don't mix them up.
>
> You should always be able to distinguish between devices,
> even if they are assigned the same phone number. In fact,
> in a call centre you'd be using a call queue. It would be
> rather nonsensical for a call queue management to have to
> distinguish between multiple identical agents.
>
> Therefore, setting up multiple devices with the same
> account credentials is not a good idea, especially not in
> a call centre. Each device and each agent should have
> their own unique account credentials and assigning
> extensions to them should always be done through the
> dialplan and only the dialplan.
>
> Asterisk has been designed this way. It is a good design.
> It should NOT be changed nor undermined.
>
> You may want to do something like this ...
>
> [GLOBALS]
>
> A-GROUP => SIP/2001 & SIP2002 & SIP/2003
>
> B-BROUP => SIP/jdoe & SIP/dflint & SIP/bsmith
>
> ...
>
>
> [Support]
>
> exten => 12345,1,Dial(${A-GROUP},30,r)
> ...
>
> exten => 54321,1,Dial(${B-GROUP},30,r)
> ...
>
>
> There is of course an issue when you want to let different
> phones start ringing at different times, for example, the
> first phone is supposed to start ringing immediately and
> the other two are only to join in if the first phone
> hasn't been picked up in 10 seconds, like so
>
> exten => 12345,1,Dial(${JDOE},10,r)
> exten => 12345,2,Dial(${JDOE}&{DFLINT}&${BSMITH},20,r)
>
> This works but if JDOE was to pick up right between those
> two dial commands, then it will have been too late for the
> first and JDOE will be "on the phone" for the second dial
> command, so there is some room for improvement. A bounty
> might better be spent on solving this little problem.
>
> Also, Asterisk supports call groups and pickup groups.
> Indeed, there have been some bugs with those features and
> I am not sure if they have have been fixed, but if they
> haven't, then it would again make more sense to put the
> bounty on fixing those rather than creating an ugly
> workaround.
>
>
> >I feel this is a great feature
>
> I don't and if you spent some more time with Asterisk and
> immerse its philosophy, then you'll very likely change
> your mind.
>
> >in other SIP proxy server this can be done easily
>
> Asterisk is not a SIP proxy. It's a telephone exchange.
>
> >i mean its default 1 or more phone could be registered
> >at 1 number (12345) and resulting same effect
>
> A phone does not register at a number. It registers at an
> account to which Asterisk can assign one or more numbers.
> This makes perfect sense and it is a far more flexible and
> better design.
>
> SIP proxies' auto assignment of extensions to SIP
> usernames is a serious limitation, not an advantage.
>
>
> The only situation where one might want to consider
> supporting multiple concurrent logins on the same account
> is for public VoIP service providers where end users might
> have a SIP phone on their desk and use a softphone on
> their notebook when they are traveling.
>
> But here again, it is more likely to be a disadvantage.
> Consider the following situation ...
>
> 1) Incoming call to 12345
>
> 2) both deskphone 12345 and road warrior's notebook 12345
> ring
>
> 3) Secretary of Mr. 12345 picks up before he himself is
> able to do so
>
> 4) Caller asks for Mr.12345 but secretary has no way of
> trying to transfer the call
>
> OTOH, Asterisk handles this situation much better ...
>
> 1) Incoming call to extension 12345
>
> 2) Dial command determines to ring both deskphone and road
> warrior's notebook which are on different extensions
>
> 3) Secretary of Mr. Road Warrior picks up before he
> himself is able to do so
>
> 4) Caller asks for Mr. Road Warrior, secretary transfers
> to internal extension of road warrior notebook's softphone
>
>
> I am sorry but your bounty doesn't seem to make sense. It
> looks more like one of those "Wanted: problem for given
> solution" cases.
>
> rgds
> benjk
>
> __________________________________________________
> Do You Yahoo!?
> http://bb.yahoo.co.jp/
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
>

On 11/07/2004 at 08:42 Paul Mahler wrote:
>You are confused about what a SIP session is and what a SIP session does.
> 
>
>SIP, session initiation protocol, controls an RTP, real time protocol,
>session between two IP endpionts. The end points have to have unique IP
>addresses for the session to run. The unique SIP registration is how *
>finds a UNIQUE endpoint. 
Sorry, but this is irrelavant... SIP allows multiple endpoints to register with
the
same account details and will all ring when called. The fact that the rtp stream
goes to the
first endpoint to pick up (and respond) is what's important ie, if multiple
devices are registered
with the same account they will *all* be 'spoken' to...  

Asterisk currently does not support this behaviour.

>You don't want SIP to solve your problem, you want * to solve your
problem.
>You are asking for this SIP "feature" because you are confused as
to how
>SIP and * work, and how they work together. 
No, the idea is to get asterisk to act like a real sip proxy. The dialplan
solution is
a poor hack.

>You can easily fix your business problem with *, but not with mechanism you
>are asking for. You should spend your money on getting a copy of each of
>the
>two books that are now available and learn *. Then it will be clear to you
>that you don't really want what you are asking for. 
again, irrelavant - the whole beauty of the way SIP works is that I can add to
the list of phones that get called by simply registering more phones with the
same details. I don't need my users to mess with or make a support call to 
add to the dial plan. They can add and remove themselves.

I'd also suggest adding something like

registrationlimit=1 

for those that do not want to support multiple client registrations, I'd
also like to
see the implementation of the q parameter...

I'm all for this modification to SIP, although I'd probably want to see
DTMF callerid
implemented first :D

Andy

On 11/07/2004 at 12:31 Paul Mahler wrote:
>The whole point of a SIP registration is to identify a UNIQUE device. You
>CAN'T HAVE multiple devices registered as the same SIP device.
That's WHY
>the last device that registers gets the traffic. 
WRONG!
>
>This doesn't have ANYTHING TO DO WITH ASTERISK. This is a SIP issue, not
an
>Asterisk issue. You should just be happy that Asterisk will do what you
>want, even if SIP won't.  
WRONG!
>If you really, really want to do this, up the bounty to about $50,000 and
>get the SIP specification changed. 
>
>
This is TOTAL rubbish .. you clearly have no idea how SIP works

I think I'll skip your book


Andy

Excellent Post! Very Informative. Thanks a lot Sir!

Regards, Girish
>From: "Olle E. Johansson" <oej@edvina.net>
>Subject: Re: [Asterisk-Users] New Asterisk bounty: SIP simultaneous
>Date: Mon, 12 Jul 2004 10:52:33 +0200
>
>Paul Mahler wrote:
>
>>Well, this is certainly getting exciting.
>Yes, it is. Sorry for coming in late to this debate...
>
>>Andy, I took your advice and re-read the RFP.
>It's actually RFC, not RFP. (teasing :-)
>
>  > So, gentlemen, help me out here. The spec says:
>>
>>"The Address of record is the "SIP address that the registry
knows the
>>registrand. .  .""
>
>The Address of record is the public SIP uri you want people to call you at,
>regardless of the address of the phone you are answering on. It's the
>SIP phone address you place on your business card.
>
>>"A client uses the REGISTER method to register the address listed
in the
>>TO
>>header field with a SIP Server."
>
>A client registers a temporary address, the address to a SIP UA, to the
>SIP registrar that is responsible for the domain in the AOR. This tells
>the SIP registrar (or "location server") where to find you if
someone
>calls your URI.
>
>When sending mail, I am not addressing the mail to the IP address you
>are reading the mail on, I am using your public e-mail address that is 
>mapped
>to an e-mail server that is responsible for all e-mail to your domain.
>Later on, you fetch the e-mail from an e-mail client somewhere, with an
>IP address that propably changes as you travel around signing books  ;-)
>
>SIP works the same way. You have a public address and a SIP proxy being
>responsible for keeping track of where you want to answer your calls.
>You can surely register several phones that you want to answer on.
>The proxy takes care of hiding this to the callee, so that the caller
>only get one set of responses. That's what the "forking" stuff
is all
>about.
>If one phone is busy and the other one is answering, we should only signal
>"200 OK" in SIP lingo to the caller.
>
>>I don't see how two different clients can register with a server as
the
>>same
>>address of record. Doesn't the second registration from a new client
>>change
>>the address of record for the registered client?
>
>You have one address-of-record that maps into several SIP URIs, one for 
>each
>device. These are not as long-term as your a-o-r SIP URI.
>From the RFC:
>
>"Location Service: A location service is used by a SIP redirect or
proxy
>server
>to obtain information about a callee’s possible location(s). It contains a
>list of bindings of address-of-record keys to zero or more
>contact addresses. The bindings can be created and removed in many ways;
>this specification defines a REGISTER method that updates the
bindings."
>
>>If the second client is trying the same registration as the first
client,
>>and it's the responsibility of the client to provide the complete
list of
>>bindings, how does the second client know the list of bindings for the 
>>first
>>client that bound the registration?
>
>It's *not* the responsibility of the *client* to provide a list,
it's the
>server that responds with a list, telling the client "by the way, these
>devices are also registred for the same a-o-r."
>
>>So isn't this the problem * has? The first client registers as the
address
>>of record, then the second client comes in with the same registration
and
>>becomes the address of record?
>
>The address of record does not change because of a registration. The stored
>address (the contact: header) of where we can reach you (location) changes.
>And yes,  if you have multiple devices registering for the same Asterisk 
>sip [peer]
>account, it will be changing for each registration. This is not the 
>behaviour
>of most SIP Proxys.
>
>Asterisk is *not* a SIP proxy. It's a SIP registrar and location server.
>It's a very clever SIP UA. It wants to be in the middle of the call
>and wants to be in control of each device. This device-slave view
doesn't
>match the SIP architecture. Due to Asterisk's multi-protocol
architecture
>we have to make some compromises in the SIP channel to be able to have
>some kind of generic view of calls and phones in the core.
>
>A SIP proxy is never the end point of a call, it should never handle
>the media stream. The power is in the edge, in the phones. This is why
>transfers and other PBX functions is a bit messy with SIP and Asterisk,
>we are trying to find a way to do it centralized as Asterisk but de-
>centralized as SIP...
>
>I've spent a considerable amount of time investigating support for
multiple
>registrations on one Asterisk sip [peer] account and after learning about
>Asterisk's architecture come to the conclusion that it is not an easy or
>even a
>desirable feature to implement. The architecture of Asterisk is a PBX, and 
>the dial
>plan and a lot of apps wants to be in control of the device.
>
>It may be possible, but will probably lead to a lot of changes to Asterisk,
>both core and applications, that no other channel will benefit from. A 
>quick
>hack to support it may lead to a lot of confusion on how to handle other 
>apps.
>And it's a lot more work than the bounty will cover. I suggest that you
use
>a
>forking SIP proxy in conjunction with Asterisk to get this functionality.
>
>If you are looking for a SIP PBX, check Pingtel's Open Source software.
>If you are looking for a SIP proxy, test SIP Express Router from iptel.org.
>If you are looking for a brilliant multi-protocol open source PBX with SIP 
>support,
>stay with Asterisk :-)
>
>Executive summary of a long posting:
>* Yes, SIP supports multiple registrations on one SIP account
>* No, I do not think Asterisk should support this with the current
>   architecture and
>* No, there's no quick fix for a 100 USD bounty
>
>Asterisk is a very large telephony platform, covering many areas and 
>protocols. Very
>few people can know all the details of all the protocols and interfaces we 
>support.
>I don't know much either on H.323 or PRI signalling...
>
>I don't think we should let these misunderstandings judge the quality of
>Paul's
>Asterisk book. Even authors need to learn now and then :-)
>
>/O
_________________________________________________________________
Planning to travel? Team up with the best. http://www.msn.co.in/travel For 
the best vacation ever!

On 11/07/2004 at 18:11 Paul Mahler wrote:
>Well, this is certainly getting exciting. 
>
>Andy, I took your advice and re-read the RFP. Andy--I don't think you
are a
Sorry, I was sleeping when these new emails came in .... 

I've read the other responses which seem to make it pretty clear.. and
address
all the points and give most of the info you need...(do I need to add to it?)

I couldn't for the life of me remember the name (it was late) and Andres
reminded us
all that it's called "Parallel Forking" - it's by far the best
feature of SIP and nearly, but
not quite, negates the NAT problems.

The reason i've been so adamant about this, is that I use it every day... my
* box
and 2 of my phones register with a local sip proxy for the same sip address... I
use this
just incase my * box dies, since it's my development box too and I'm
always mesing with
it. 
>good candidate for a beginner's book on *, but if you send my your
address,
>I'll send you a copy on me. :-)
Or some Ninja assasin... ;)

Perhaps you could also sign it :D (not the Ninja assasin ;) )
>
>Andy, I'm in your hands.
>
I was too late... I took the liberty of getting some sleep... appologies.



Andy

in response to Olle's excellent post, ...

in particular ...
>Asterisk is *not* a SIP proxy. It's a SIP registrar and
location server.
>It's a very clever SIP UA. It wants to be in the middle
of the call
>and wants to be in control of each device. This
device-slave view >doesn't match the SIP architecture.

and ...
>I've spent a considerable amount of time investigating
support for
>multiple registrations on one Asterisk sip [peer] account
and after
>learning about Asterisk's architecture come to the
conclusion that
>it is not an easy or even a desirable feature to
implement.

and ...
>It may be possible, but will probably lead to a lot of
changes to
>Asterisk, both core and applications, that no other
channel will
>benefit from. A quick hack to support it may lead to a
lot of
>confusion on how to handle other apps. And it's a lot
more work
>than the bounty will cover. I suggest that you use a
forking SIP
>proxy in conjunction with Asterisk to get this
functionality.

Precisely! A fairly simple and elegant solution.

For those rare occasions where one would really need
multiple concurrent SIP registrations I'd say one should
consider running Asterisk in combination with a SIP proxy.
Since SER is a free download, this wouldn't seem to be
such a big deal IF IT WASNT for the fact that one will
then need to run two boxes.

It would make a lot of sense to provide support for an
easy-to-configure set up where Asterisk can live together
with another SIP speaking piece of software on the same
box.

Something along the lines of ...

(ip1:5060)---[*]---[portswapper]---(ip1:5061)---[SER]---(ip2:5060)

Something like this should allow you to run Asterisk on
one address (ie LAN side) and SER on another (ie WAN
side), so you get the best of both Asterisk and a SIP
proxy all in one box.

This would also make it possible to run a SIP softphone
alongside Asterisk on a notebook, so it would solve two
birds with one stone.

I'd like to emphasise however, that most of the problems
described in this thread are NOT good reasons for multiple
concurrent SIP registrations. Those problems have other
solutions. Let's take a look at them.

1) Call centre scenario

Problem: multiple agents should receive calls on the same
phone number

Solution: assign a number to a call queue and let the call
queue distribute incoming calls to the agents on different
SIP phones, each of which should have unique logins for
reasons of accounting and quality assurance.

multiple concurrent registrations on the same SIP account
in call centres is a BAD IDEA.

2) Overworked admin scenario

Problem: asterisk admin doesn't want to deal with support
calls for adding additional SIP phones

Solution: a simple self provisioning system, either web
based or even IVR based.

3) Dual line desk phone scenario

Problem: dual line desk phone requires multiple
registrations, one per line

Solution: let the phone register on two different SIP
accounts, which is how any conventional PBX handles dual
line phones: one extension per line.

4) Call group scenario

Problem: multiple phones to ring on the same extension

Solution: use the call group feature or use the dial
command with multiple SIP peers


For the avoidance of doubt, I am not saying there is no
situation for which multiple concurrent SIP registrations
may be the right solution, but the problems described so
far are *not*.

But if anybody has a problem that truly warrants parallel
forking, then I propose you look into sponsoring somebody
to work on the little port swapping trick to run SER
concurrently on your Asterisk box.

rgds
benjk


__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/

Hi all,

after a good time trying i made the optipoint work with asterisk...

this is very strange but.. maybe someone can do it and tell me what happens:

I have two peers in sip.conf :

[19]
accountcode=19
amaflags=billing
type=friend
username=19
secrethost=dynamic
nat=yes
qualify=1000
context=sip

[optipoint]
type=friend
secretusername=optipoint
host=dynamic
defaultip=192.168.0.36
dtmfmode=inband
canreinvite=yes
nat=yes
qualify=1000
mailbox=331
context=internal
callerid="optipoint" <optipoint>

In extensions.conf:

exten => 37,1,DIAL(SIP/optipoint,20,tr)


The optipoint is configured in that way:


Terminal number:   19
Terminal name:   19
Register by terminal name:   x


SIP details:
SIP routing: Gateway
Registrar IP address or DNS name:   192.168.0.34 (my *)
Server IP address or DNS name:  192.168.0.34
Gateway IP address or DNS name:   192.168.0.34
Outbound proxy:
Default OBP domain:
SIP transport:  UDP
SIP session timer enabled:   x
SIP session timer value (1800-3600):  3600seconds
Registration timer value:  3600seconds
SIP realm:   asterisk
SIP user ID:   19
New SIP password:   -
Confirm SIP password:   -
Beep on SIP server error:   x


cli shows:

asterisk-eth0*CLI> sip show peers
Name/username    Host                 Mask             Port     Status
optipoint/optip  192.168.0.36    (D)  255.255.255.255  1028     OK (118 ms)
19/19            192.168.0.36    (D)  255.255.255.255  1028     OK (131 ms)


Now i can make calls to optipoint using "37" and make calls from
optipoint
using "19"
in diferent contexts with includes.

Note that * is registered like gateway in the optipoint conf pages

regards

Miklos

Kannaiyan Natesan wrote:
>I hope you clearly understand that everyone here
**KNOWS**
>to use alternative software such as SER, what is needed
here is
>the same facility in asterisk.
You have not shown us ANY example yet for which this
facility is *NEEDED*.

You have only shown us examples for which the facility MAY
be used, all of which have been shown to have OTHER,
better solutions.

For call centres you use call queues, for taking workload
off admins you use self provisioning, for call groups you
use callgroup=1 or a dial string with multiple
destinations, for multi line SIP phones you use multiple
extensions.

None of those problems warrant the use of parallel
forking.

Your problem seems to be that you want a facility for its
own sake, not because you really need it. That, however is
not good enough a reason to add something to Asterisk.

rgds
benjk

__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/

Duane wrote:
>We're running SER and Asterisk on the same system with
>Like2Fone.com and we just stuck Asterisk on a different
>port then redirect calls as needed, although I doubt it
would
>be as difficult as your making out, if you stick SER on
an
>alternative port and then just use that to connect your
>clients to problem solved, in effect the opposite to what
>we wanted to achieve...
Interesting. I assume by "redirect calls as needed" you
mean passing calls between Asterisk and SER.

It is unclear to me how you achieve that.

If Asterisk is directed to speak SIP on port 5061 and SER
remains on port 5060, then how do you get Asterisk to talk
to SER and vice versa?

Would you care to share this with us?

rgds
benjk

__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/

> Kannaiyan Natesan wrote:
>
> >I hope you clearly understand that everyone here
> **KNOWS**
> >to use alternative software such as SER, what is needed
> here is
> >the same facility in asterisk.
>
> You have not shown us ANY example yet for which this
> facility is *NEEDED*.
>
Have you used 55555 welcome service in fwd?
If not try that. You are invited to join as a volunteer to provide support
and talk to new people on fwd.

As I explained to you before we use it for our customer service in call
center and implemented in many call centres which really makes $.

Can you help me to know how that be achieved with * alone.

-Kannaiyan.

Based upon the analysis I think we need to modify two things,

1. chan_sip.c (Registrar)
2. app_dial.c  (Dial Command for simultaneous dialling, as of now it
supports simultaneous dialling too)

The registrar of SIP need to collect the array of registrants and the Dial
command need to take care of dialling to all possible registrants which I
think should be easier to implement. Anybody thinks will there be any other
problems in handling the same?

-Kannaiyan.

Ok I'll kick in $25 (just based on your email alone).

Is there a formal system for bounty registration?

Cheers,
Dean


-----Original Message-----
From: asterisk-users-admin@lists.digium.com
[mailto:asterisk-users-admin@lists.digium.com] On Behalf Of Olle E.
Johansson
Sent: Tuesday, 13 July 2004 5:54 PM
To: asterisk-users@lists.digium.com
Subject: Re: [Asterisk-Users] New Asterisk bounty: SIP simultaneous

> 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.

Asterisk doesn't really bother with *users*, it has a device-centric
view
of life, universe and propably everything. With Asterisk, the user has
to
call me each time he wants a new device connected and I have to
reconfigure
his setup.

If I had support for multiple registrations on one [peer] account, the
[peer] would become a user account instead of a device. And the user
could add as many devices as he wanted (up to a defined limit) without
bothering the administrator. I guess that's why a lot of people ask for
this function.

However, since Asterisk doesn't really bother with a user concept,
we really have to teach Asterisk about users. And user groups.
Life is much more than hardware, little Asterisk :-)

I've been discussing this many times, and so has many other people.
I think we need an elegant way of defining users to asterisk so we
connect peers, users, agents and mailboxes to a *user* with one
set of credentials. If you look into your Asterisk configuration,
you will find that there are users and credentials for logging in
everywhere. It's not easy to maintain at all.

After a lot of discussions on the IRC, I'm convinced that we at
some point in time have to add ast_auth - a common infrastructure
for handling users and authentication.

This is a good topic for the Asterisk Developer's Day at Astricon.
Let's bring it up on the agenda - A new user and authentication
structure for Asterisk.

YALMIATASQ - Yet Another Long Mail in answer to a short question.

Hint: I have a new idea for a solution on multiple reg's.
Raise the bounty and I might give it a try. ;-)

/Olle

_______________________________________________
Asterisk-Users mailing list
Asterisk-Users@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Hello,
>From: Sunrise Ltd <stsltdtyo@yahoo.co.jp>
>Subject: Re: [Asterisk-Users] New Asterisk bounty: SIP simultaneous
>Date: Tue, 13 Jul 2004 16:31:58 +0900 (JST)
<snip>
>If Asterisk is directed to speak SIP on port 5061 and SER
>remains on port 5060, then how do you get Asterisk to talk
>to SER and vice versa?
>
>Would you care to share this with us?
It is something like this:
Asterisk extensions.conf:

[globals]
SERADDRESS=XXX.XXX.XXX.XXX:5060

[context]
exten => <yourexten>,1,Dial(SIP/${EXTEN}@${SERADDRESS},20,r)

In ser.cfg:

if (method == "INVITE") {
    if (uri =~ "sip:1[0-9]{10}@*"){
        log(1, "Forwarding to Asterisk\n");
        rewritehostportt("XXX.XXX.XXX.XXX:5061");
        t_relay();
        break;
    }
}
>rgds
>benjk
Regards, Girish

_________________________________________________________________
Earn without investing. http://go.msnserver.com/IN/52048.asp Sell anything 
under the sun.

Kannaiyan Natesan wrote:
>Have you used 55555 welcome service in fwd?
>If not try that. You are invited to join as a volunteer
to provide >support and talk to new people on fwd.

Asterisk can do that much better than SER because it has
got a queue management system built-in.
>As I explained to you before we use it for our customer
service in call
>center and implemented in many call centres which really
makes $.

No matter how many times you claim that parallel forking
is the right solution to implement a call centre, it
doesn't change the fact that you are still wrong. Call
centres use queue management systems.
>Can you help me to know how that be achieved with *
alone.

Sure. Read /etc/asterisk/queues.conf and
/etc/asterisk/agents.conf. Everything you need is there.

rgds
benjk

__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/

Girish Gopinath wrote:
>[globals]
>SERADDRESS=XXX.XXX.XXX.XXX:5060
>
>[context]
>exten =>
<yourexten>,1,Dial(SIP/${EXTEN}@${SERADDRESS},20,r)
>
>In ser.cfg:
>
>if (method == "INVITE") {
>    if (uri =~ "sip:1[0-9]{10}@*"){
>        log(1, "Forwarding to Asterisk?n");
>        rewritehostportt("XXX.XXX.XXX.XXX:5061");
>        t_relay();
>        break;
>    }
>}
OK, that looks kind of promising.

In other words you're saying to do away with
authentication for calls between Asterisk and SER since
both run on the same box?

I haven't looked at it this way, but I guess it makes
sense.


Unfortunately though, this doesn't seem to also be a
solution for what I would like to do, which is run X-Lite
and Asterisk on the same box, my Powerbook G4, so I can
use it as an IAX phone when travelling.

thanks anyway for the interesting insight.

rgds
benjk

__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/

Olle E. Johansson wrote:
>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.

Two words: self provisioning.
>Asterisk doesn't really bother with *users*, it has a
>device-centric view of life, universe and propably
everything.

That's only partly correct. The queue management system
has a user view, called agents, and agents can
authenticate themselves independently from the device they
are using and then attach themselves to call queues
managed by Asterisk.

However, for anything unrelated to queue management, you
are correct in that Asterisk doesn't apply this concept
there.

I may even agree with you that it would be worthwhile to
apply this user concept to other areas outside of queue
management.

Still I disagree that parallel forking is the way to do
this. I even disagree that it would introduce a user view.
Instead it would water down the device view. So you go
from an system with a very clean device view but without a
universally applied user view to a system with a messy
device view and still no user view.
>With Asterisk, the user has to call me each time he wants
a new
>device connected and I have to reconfigure his setup.
Not if you give them a means to provision it themselves.
This can be as easy as an extension that asks for a PIN
number and then executes a shell script.

If I had support for multiple registrations on one [peer]
account, the
[peer] would become a user account instead of a device

Well, that's an opinion.

I'd rather prefer to have a user layer on top and in
addition to a device layer instead of trading one for the
other.

This is how GSM works BTW, you have the IMEI which
identifies the device and the IMSI which identifies the
subscriber. A subscriber may be using the same IMSI on
different devices, but the IMEI for each device is unique.
The IMEI lives in the device. The IMSI lives on the SIM
card.

The customer care and billing system is mostly concerned
about the IMSI when dealing with a subscriber, but some
low level network elements need the IMEI to do their job.
The conclusion here is that there is a use for both,
device and user views.

I think it would be wise to take a lesson from GSM in
respect of having both a device and a user view, and not
just trade one for the other.
>And the user could add as many devices as he wanted
>(up to a defined limit) without bothering the
administrator.

Early mobile phone systems made the same mistake you are
proposing here. They too said "device = user" and it
opened the door to plenty of problems, from inconvenience
when changing a device to fraud.

The introduction of GSM introduced a user layer on top of
the device layer and you got both convenience (ie move the
SIM card to another phone and secondary SIM for a family
member etc etc) and better security (no device cloning,
stolen equipment can be blocked through EIR network
elements etc etc).

>I guess that's why a lot of people ask for this function.
No, people asking for this because "If all you have is a
hammer, everything looks like a nail."
>However, since Asterisk doesn't really bother with a user
concept,
>we really have to teach Asterisk about users. And user
groups.

I agree with that in priniciple, but parallel forking
doesn't do that.
>I've been discussing this many times, and so has many
other
>people. I think we need an elegant way of defining users
to
>asterisk so we connect peers, users, agents and mailboxes
>to a *user* with one set of credentials. If you look into
your
>Asterisk configuration, you will find that there are
users and
>credentials for logging in everywhere. It's not easy to
>maintain at all.
Agreed again, but still fail to see how parallel forking
would contribute anything to what you ask for here.
>Hint: I have a new idea for a solution on multiple reg's.
>Raise the bounty and I might give it a try. ;-)
If you absolutely have to mess with it, just make sure it
can be disabled by the rest of us who don't want to deal
with any potential problems it may introduce.

rgds
benjk

__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/

> As I explained to you before we use it for our customer service in call
> center and implemented in many call centres which really makes $.
>
All this stuff to do a simple call queue system??? Man, You need to read
wiki. Read agents.conf and queue.conf before to begin a war here...
All you need to do can be achieved with app_queue.

Regards,

Gus

Jay Milk wrote:
>[general]
>Port=5060
>
>register => ...@sphone.vopr.vonage.net:5061
>
>[sip-vonage]
>...
>host=sphone.vopr.vonage.net
>port=5061
very interesting, thanks.

Still need to get my head around this and see how it may
be used for running X-Lite along Asterisk on the same
notebook in order to dial out from X-Lite through Asterisk
going from SIP to IAX in the process.

thanks again
benjk

__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/

Kannaiyan Natesan wrote:

Subject: Re: [Asterisk-Users] New Asterisk bounty: SIP
simultaneous
>I will close it from my side.
>
>Thanks for your info.
>Let us do something better.
Did you check out /etc/asterisk/queues.conf and
/etc/asterisk/agents.conf ???

Or do you mean to say you won't be satisfied with anything
other than your pet feature, no matter how unsuited it may
be and regardless of better suited solutions Asterisk has
to offer?

As for "doing something better", I would hope to see two
things happening ...

1) you begin to use queue_app for your call centre
requirements and if you need any assistance, you ask about
it here

2) having experienced Asterisk's superior queue management
system, you tell us that you were wrong and consider
withdrawing your bounty

thx
rgds
benjk

__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/

Olle E. Johansson wrote:
>Agreed. I wasn't clear enough. Asterisk have users in
many
>places, but no centralized view of a "user".
Agreed.
>I haven't said that parallel forking is my recommended
>way of doing this.
Fair enough.
>I've stated several times that it doesn't
>really comply with the architecture of Asterisk, unless
>done in an Asterisk-architecture friendly way :-)
>And adding it will not solve the user dilemma, as you
>say.
The trouble is that some folks, the ones who only got a
hammer, ignored that part of your comments, possibly even
on purpose.

I am concerned about the danger of introducing features
into Asterisk which water down its philosophy. If features
are to be added it should be for the right reasons, not
for the wrong ones.

>> Not if you give them a means to provision it
themselves.
>> This can be as easy as an extension that asks for a PIN
>> number and then executes a shell script.
>
>Right. Please send samples of this so we can add it to
the Wiki!

The account provisioning scripts I have done so far are
called either from some GUI interface or they are executed
on the command line. I haven't used them for self
provisioning yet but I know that it would be fairly easy
to "misappropriate" them for that purpose.

When I get the time, I will add a bit of "end user glue"
and post an example.
>Thats where we should go. [peer]s and [user]s being
devices
>(IMEI) and a new user architecture representing the IMSI.
>We have accountcode now. It's not enough.
It may well be worth while implementing (parts of) the GSM
IMSI specification into Asterisk. Combined with support
for SIM card readers this would make it possible to use
standard SIM cards to sign on to an Asterisk driven
network.

Without the SIM card the devices could still log on to
Asterisk, but they would be placed in a restricted
context. Then, when a SIM card is inserted and
authenticated, the account will be attached to the device
and it will then be placed in the context associated with
that user.

Of course there could be alternative methods for user
authentication in addition to SIM cards. Still I think it
would make sense to use the GSM specification *where
applicable* instead of creating yet another format.

The authentication algorithm would have to be replaced
with RSA or something though, because the GSM A5 algorithm
is secret and available only to licensed GSM operators who
joined the GSM Association. Rather silly that those folks
still seem to believe in secret authentication algorithms,
eh?!

But apart from that pesky A5 thing, the way GSM
authenticates users is pretty well designed. You have got
the handset which can access the network even without a
SIM but then only emergency services are authorised. If a
SIM card is present, a request to authenticate will be
sent to the user's network's HLR (Home Location Registry)
from where the SIM card will then be authenticated. Once
this was successful, a temporary entry is created in the
VLR (Visited Location Registry) that serves the spot in
which the user happens to be. This entry then determines
which services the user is authorised to use, voice,
messaging, data, value added etc.

If you are interested to look into this a bit further and
if only for inspiration, but haven't got access to the
documentation, I have the entire ETSI GSM standard
documentation on CD. So, if you want to take a peek,
contact me by email at benjamin (at) sunrise (dash) tel
(dot) com.

rgds
benjk

__________________________________________________
Do You Yahoo!?
http://bb.yahoo.co.jp/