[Users] Transaction already in Process

[Iqbal]

jumping in alittle late on this one, but i read that routing the calls 
back via openser is a pain rather than terminating on asterisk.

I had the same dilemma sometime ago when doing virtual pbx setup, but i 
found it easier to send the call back to ser, and let it do all the 
registration/routing etc, and just use asterisk for features. would be 
interested on feedback on this....I may have designed it all wrong after 
reading this :-)

Iqbal

Douglas Garstang wrote:

>Klaus,
>
>That's it!
>
>Doug.
>
>-----Original Message-----
>From: Klaus Darilion [mailto:klaus.mailinglists at pernau.at]
>Sent: Friday, December 16, 2005 12:25 AM
>To: Douglas Garstang
>Cc: users at openser.org
>Subject: Re: [Users] Transaction already in Process
>
>
>So how does it look like when Client A calls Client B? Is the signaling 
>Like in the figure?
>
>          Asterisk
>          /      \
>         /        \
>      Openser      \
>       /            \
>      /              \
>Client A         Client B
>
>
>regards
>klaus
>
>
>
>Douglas Garstang wrote:
>  
>
>>Klaus,
>>
>>All calls are going through OpenSER from the phones. However, they don't go BACK to OpenSER. Asterisk terminates the call. Putting all calls BACK through OpenSER would be a nightmare. It would make a lot of Asterisk features such as ACD Queues, MeetMe Conferencing etc very hard to manage. I'm not even sure if they would work.
>>
>>Doug.
>>
>>-----Original Message-----
>>From: Klaus Darilion [mailto:klaus.mailinglists at pernau.at]
>>Sent: Thursday, December 15, 2005 8:23 AM
>>To: Douglas Garstang
>>Cc: users at openser.org
>>Subject: Re: [Users] Transaction already in Process
>>
>>
>>I can't explain it, but I do not like the idea replicating with failure 
>>routes ...
>>
>>IMO it would be better to modify t_replicate to allow to replicate to 
>>moultiple instances.
>>
>>Would i be possible to route all calls via openser? Then you do not need 
>>the location info in the Asterisks.
>>
>>
>>regards
>>klaus
>>
>>Douglas Garstang wrote:
>>
>>    
>>
>>>Klaus,
>>>
>>>Asterisk can't use a database for location/contact information. It also has no native means to transfer registrations between itself and another Asterisk system. It can't even perform a user defined action when a phone registers... doesn't leave us with many options. Right now, using OpenSER to replicate (forward,t_relay,t_replicate whatever) seems to be working ok. Do you have any reason to believe it wouldn't scale up well?
>>>
>>>Doug.
>>>
>>>-----Original Message-----
>>>From: Klaus Darilion [mailto:klaus.mailinglists at pernau.at]
>>>Sent: Thursday, December 15, 2005 3:23 AM
>>>To: Douglas Garstang
>>>Cc: users at openser.org
>>>Subject: Re: [Users] Transaction already in Process
>>>
>>>
>>>Hi Douglas!
>>>
>>>I still think it is a bad idea to replicate REGISTER to Asterisk 4 
>>>times. Where does Asterisk store the location table? In a database? Why 
>>>not replicate the location data on DB level?
>>>
>>>regards
>>>klaus
>>>
>>>Douglas Garstang wrote:
>>>
>>>
>>>      
>>>
>>>>Arrgh!
>>>>
>>>>Now I'm getting "t_newtran: transaction already in process" messages whenever I try to call t_relay() or t_replicate twice, even when the first attempt has FAILED. In the case of t_relay() I have new addresses in the destination set and I still get this error. Why? When you attempt to deliver, and it fails, how can to attempt again without getting those messages? What fundamental piece am I missing?
>>>>
>>>>How could I do this? Forget the fancy stuff. I don't care about checking for failure anymore.
>>>>
>>>>t_replicate("192.168.10.7","5060");
>>>>t_replicate("192.168.10.8","5060");
>>>>t_replicate("192.168.10.200","5060");
>>>>
>>>>Doug.
>>>>
>>>>_______________________________________________
>>>>Users mailing list
>>>>Users at openser.org
>>>>http://openser.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>>    
>>
>
>
>_______________________________________________
>Users mailing list
>Users at openser.org
>http://openser.org/cgi-bin/mailman/listinfo/users
>
>.
>
>  
>