Re: [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

Bogdan-Andrei Iancu-2
Hi Binan,

Yes the patch is there, we need to review it. Also Inaki sugested some tunings in the PATH module (to fully support websocket).

Thanks and regards,
Bogdan


Sent from Samsung Mobile

Binan AL Halabi <[hidden email]> wrote:

Hi All,

If oversip uses Path extension OpenSIPS must support it.

1- Sending Path header values in 200 ok REGISTER response
2- Path header files syntax must confom to Route syntax
3- When look up the opensips must copies the stored path header fileds into Route header fileds - preloaded route.
Reference: RFC 3327  


Here i think adding one Route header pointing to OverSIP (second Path URI) is enough in simple case (UA ---- OverSIP--- OpenSIPS).
OverSIP removes the Route header and route the request based on RURI (first Path URI). 
 


OpenSIPs support this http://www.opensips.org/html/docs/modules/devel/registrar.html#id248705 
flag "px" (path support) of save function in Registrar module.

So still parsing VIA header is required to add WS and WSS. I think this patch is already posted.


Binan.


Från: Iñaki Baz Castillo <[hidden email]>
Till: Bogdan-Andrei Iancu <[hidden email]>
Kopia: OpenSIPS users mailling list <[hidden email]>
Skickat: torsdag, 1 november 2012 20:36
Ämne: Re: [OpenSIPS-Users] [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

2012/11/1 Bogdan-Andrei Iancu <[hidden email]>
>
> Hi Inaki,
>
> Please correct me if I'm wrong, but reading the draft and listing you guys all, I would say the right approach is to : (1) use OverSIP as gw (to extract SIP traffic from WebSocket) and (2) make OpenSIPS to support SIP traffic resulted from websocket extraction.
>
> If so, OpenSIPS has nothing to do with the WebSocket protocol itself, but only to support the extensions from the draft (like new protocols and eventually the SIP server location).

Right. As Saul pointed out, this scenario (which is a pure RFC 5626
"Outbound" scenario with a Edge Proxy in front of the
registrar/authentication-proxy) requires:

- Path support in OpenSIPS for storing the Path URI(s). Note: It's
important to increase the "path" column size in the location table.
The current value is to small and cannot store two URI's (OverSIP adds
double Path headers).

- OpenSIPS should improve the parser of the Via transport field since
currently it only accepts UDP, TCP, TLS and SCTP. It should also
accept WS and WSS, but better if it accepts any token (as the RFC 3261
BNF grammar states). Otherwise OpenSIPS will discard SIP requests
coming from OverSIP (since the non top Via header, that created by the
SIP WebSocket client, has "WS" as transport protocol).

And nothing else at all, but the above two points are important.

Regards.





--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

Iñaki Baz Castillo
2012/11/2 Bogdan-Andrei Iancu <[hidden email]>:
> Yes the patch is there, we need to review it. Also Inaki sugested some
> tunings in the PATH module (to fully support websocket).

Well, there is no special needs for the PATH module to support
WebSocket. In fact, nothing must be done if it already works ok (but
just increasing the path column size to be able to store two URIs).

Regards.

--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

Bogdan-Andrei Iancu-2

On 11/02/2012 02:17 PM, Iñaki Baz Castillo wrote:
> 2012/11/2 Bogdan-Andrei Iancu<[hidden email]>:
>> Yes the patch is there, we need to review it. Also Inaki sugested some
>> tunings in the PATH module (to fully support websocket).
> Well, there is no special needs for the PATH module to support
> WebSocket. In fact, nothing must be done if it already works ok (but
> just increasing the path column size to be able to store two URIs).
>
Yes, that's the kind of things I was referring at. Also looking in the
patch module code, there are several things that can be improved there
(how path is built, mem usag, etc). There are still some faulty things
also there  - there was recently a fix on TCP handling (proto changing)
in PATH hdr.

Regards,
Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

Rudy
Bogdan,

 Its great to hear all these ideas for 1.9 from the community. One thing that may also be useful, is some enhancements to the rabbit_mq module. It would be great if this module could also push/send events to a any rabbitmq queue or exchange (maybe based on an avp) . Another thing that may be worth exploring is being able to send ACC via a rabbitmq event. What do you think?

Regards,
--Rudy
Dynamic Packet
Toll-Free: 888.929.VOIP ( 8647 )


On Fri, Nov 2, 2012 at 9:55 AM, Bogdan-Andrei Iancu <[hidden email]> wrote:

On 11/02/2012 02:17 PM, Iñaki Baz Castillo wrote:
2012/11/2 Bogdan-Andrei Iancu<[hidden email]>:
Yes the patch is there, we need to review it. Also Inaki sugested some
tunings in the PATH module (to fully support websocket).
Well, there is no special needs for the PATH module to support
WebSocket. In fact, nothing must be done if it already works ok (but
just increasing the path column size to be able to store two URIs).

Yes, that's the kind of things I was referring at. Also looking in the patch module code, there are several things that can be improved there (how path is built, mem usag, etc). There are still some faulty things also there  - there was recently a fix on TCP handling (proto changing) in PATH hdr.

Regards,
Bogdan


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Dialplan with # or *

Jorge Medina
Hi, 
 
I need to inclue #  and * characters  begining dialing. Customers  will dial  #400   and  *20(+ digits).  Sipserver never routes these strings  to softswich.  I had included in dialplan intenting several ways without  results.  
 
 
 id      dpid   pr   match_op   match_exp           match_len   subst_exp   repl_exp   attrs 
14501 10 0 1  ^#400              0                               
 
 
 id      dpid   pr   match_op   match_exp        match_len   subst_exp   repl_exp   attrs 
14500 11 0 1  ^\*20[0-9]*     0                               
 
Thank you for your help!
 
Jorge Medina

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Dialplan with # or *

Binan83
Hi Jorge,

Use character code  point instead:

\x{0023} matches #
\x{002A} matches *

// Binan.


Från: Jorge Medina <[hidden email]>
Till: [hidden email]; [hidden email]
Skickat: lördag, 3 november 2012 0:16
Ämne: [OpenSIPS-Users] Dialplan with # or *

Hi, 
 
I need to inclue #  and * characters  begining dialing. Customers  will dial  #400   and  *20(+ digits).  Sipserver never routes these strings  to softswich.  I had included in dialplan intenting several ways without  results.  
 
 
 id      dpid   pr   match_op   match_exp           match_len   subst_exp   repl_exp   attrs 
14501 10 0 1  ^#400              0                               
 
 
 id      dpid   pr   match_op   match_exp        match_len   subst_exp   repl_exp   attrs 
14500 11 0 1  ^\*20[0-9]*     0                               
 
Thank you for your help!
 
Jorge Medina

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
voipmagazine.wordpress.com/
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

Bogdan-Andrei Iancu-2
In reply to this post by Rudy
Hi Rudy,

Events are send to the server/queue described when you subscribed for an event (via the MI command - http://www.opensips.org/Resources/DocsCoreMi18#toc15). or ?

Regarding ACC, the module itself does not generate events for acc records, but you can do that from the script (see the raise_event() core function - http://www.opensips.org/Resources/DocsCoreFcn18#toc129)

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 11/02/2012 10:49 PM, Rudy wrote:
Bogdan,

 Its great to hear all these ideas for 1.9 from the community. One thing that may also be useful, is some enhancements to the rabbit_mq module. It would be great if this module could also push/send events to a any rabbitmq queue or exchange (maybe based on an avp) . Another thing that may be worth exploring is being able to send ACC via a rabbitmq event. What do you think?

Regards,
--Rudy
Dynamic Packet
Toll-Free: 888.929.VOIP ( 8647 )


On Fri, Nov 2, 2012 at 9:55 AM, Bogdan-Andrei Iancu <[hidden email]> wrote:

On 11/02/2012 02:17 PM, Iñaki Baz Castillo wrote:
2012/11/2 Bogdan-Andrei Iancu<[hidden email]>:
Yes the patch is there, we need to review it. Also Inaki sugested some
tunings in the PATH module (to fully support websocket).
Well, there is no special needs for the PATH module to support
WebSocket. In fact, nothing must be done if it already works ok (but
just increasing the path column size to be able to store two URIs).

Yes, that's the kind of things I was referring at. Also looking in the patch module code, there are several things that can be improved there (how path is built, mem usag, etc). There are still some faulty things also there  - there was recently a fix on TCP handling (proto changing) in PATH hdr.

Regards,
Bogdan


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________ Users mailing list [hidden email] http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Dialplan with # or *

Binan83
In reply to this post by Binan83
Hi Jorge,

In your config use dp_translate() function which searches the dialplan table to find a pattern and
apply the translations needed. Also You can assign attribute to avp depending on the match.

There is a dialplan example in chapter 7 of the book (Building Telephony Systems with OpenSIPS 1.6) page 168.

Binan.

Från: Jorge Medina <[hidden email]>
Till: [hidden email]; [hidden email]
Skickat: torsdag, 8 november 2012 16:20
Ämne: RE: [OpenSIPS-Users] Dialplan with # or *

Hi,
 
Thanks for your answer,
 
 
I tested for # case:
 
1. Register in dialplan dialplan:
 
id      dpid   pr   match_op   match_exp           match_len 
14501 10 0 1  ^\x{0023}400             0

 
 
2. In configuration file, local call  line:
 
if(uri =~ "^sip:[0-9]+@")
 
was changed by:
 
if((uri =~ "^sip:[0-9]+@")  || (uri =~ "^sip:%23 [0-9]+@") )  
 
 
and them by:
 
if((uri =~ "^sip:[0-9]+@")  || (uri =~ "^sip:\# [0-9]+@") )
 
 
 
Result:  Sipserver never routes these strings  to softswich.
 
Thankyou for your help.
 
Best regads,
 
 
Jorge Medina
 

 
 
 
  
 

Date: Fri, 2 Nov 2012 19:50:19 -0700
From: [hidden email]
To: [hidden email]
Subject: Re: [OpenSIPS-Users] Dialplan with # or *

Hi Jorge,

Use character code  point instead:

\x{0023} matches #
\x{002A} matches *

// Binan.


Från: Jorge Medina <[hidden email]>
Till: [hidden email]; [hidden email]
Skickat: lördag, 3 november 2012 0:16
Ämne: [OpenSIPS-Users] Dialplan with # or *

Hi, 
 
I need to inclue #  and * characters  begining dialing. Customers  will dial  #400   and  *20(+ digits).  Sipserver never routes these strings  to softswich.  I had included in dialplan intenting several ways without  results.  
 
 
 id      dpid   pr   match_op   match_exp           match_len   subst_exp   repl_exp   attrs 
14501 10 0 1  ^#400              0                               
 
 
 id      dpid   pr   match_op   match_exp        match_len   subst_exp   repl_exp   attrs 
14500 11 0 1  ^\*20[0-9]*     0                               
 
Thank you for your help!
 
Jorge Medina

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________ Users mailing list [hidden email] http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
voipmagazine.wordpress.com/
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

Brett Nemeroff
In reply to this post by Rudy
On Fri, Nov 2, 2012 at 3:49 PM, Rudy <[hidden email]> wrote:
Bogdan,

 Its great to hear all these ideas for 1.9 from the community. One thing that may also be useful, is some enhancements to the rabbit_mq module. It would be great if this module could also push/send events to a any rabbitmq queue or exchange (maybe based on an avp) . Another thing that may be worth exploring is being able to send ACC via a rabbitmq event. What do you think?


I just wanted to throw in my $0.02 here.. And I apologize for pandering. Once I got on it, I realized there's a lot around this that I'd like to see..

I think this is a great idea. Both being able to dynamically control which rabbit queue to send and to have it native in acc.

** What about having native acc callbacks in the routing script? that'd make adopting new technologies for accounting really easy. Like this:

on_dialog_complete {
    new_tech_acc_write("$avp(extra_params)");
}

on_dialog_established {
    new_tech_notify_new_call("$avp(extra_params)")
}

(these new_tech_* funcs are just examples of new modules in the future, like couchbase or perhaps a REST query.

I'm not entirely sure how to go about doing it. But the idea is that the custom "acc callback" routes would be called on specific acc events that would cause acc records to be written. I recognize what I posted above is more of a dialog callback. For my cases specifically, I'd use the cdr flag, and I'd like to know when a call ends. Then I'd write the acc details to the "new technology" backend. So I'm not sure if this is an acc feature or a dialog feature (or perhaps some combination of both).

I'd probably want all the dialog data in a single object (like maybe a json object) or something else easily passable and parsable. A $dlg_json variable would be really awesome for this purpose. I image if cdr_flag was set, it'd have the duration and all in there as well (all the normal stuff it'd be writing to the db).

Bah, Sorry about that, I really went on.

tl/dr: 
1. new $dlg_json variable that stores all data that would normally be written by a acc write (and maybe some additional dialog specific data)
2. new special routes to act as acc module callbacks to be called at specific acc events, which should also work with the cdr_flag. 

Thanks! 
-Brett






 

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

Kevin Mathy
Hi list, 

Is there a possibility now to download 1.9 beta version ? I tried with svn links provided on opensips.org, but, I just can get 1.8.2, no more... 

Thanks a lot, 

Bien cordialement, 
Best Regards, 

Kevin MATHY
HEXANET
--
Phone : +33 (0) 3 26 79 30 05
Tech Support : +33 (0) 3 51 08 42 07




2012/11/28 Brett Nemeroff <[hidden email]>
On Fri, Nov 2, 2012 at 3:49 PM, Rudy <[hidden email]> wrote:
Bogdan,

 Its great to hear all these ideas for 1.9 from the community. One thing that may also be useful, is some enhancements to the rabbit_mq module. It would be great if this module could also push/send events to a any rabbitmq queue or exchange (maybe based on an avp) . Another thing that may be worth exploring is being able to send ACC via a rabbitmq event. What do you think?


I just wanted to throw in my $0.02 here.. And I apologize for pandering. Once I got on it, I realized there's a lot around this that I'd like to see..

I think this is a great idea. Both being able to dynamically control which rabbit queue to send and to have it native in acc.

** What about having native acc callbacks in the routing script? that'd make adopting new technologies for accounting really easy. Like this:

on_dialog_complete {
    new_tech_acc_write("$avp(extra_params)");
}

on_dialog_established {
    new_tech_notify_new_call("$avp(extra_params)")
}

(these new_tech_* funcs are just examples of new modules in the future, like couchbase or perhaps a REST query.

I'm not entirely sure how to go about doing it. But the idea is that the custom "acc callback" routes would be called on specific acc events that would cause acc records to be written. I recognize what I posted above is more of a dialog callback. For my cases specifically, I'd use the cdr flag, and I'd like to know when a call ends. Then I'd write the acc details to the "new technology" backend. So I'm not sure if this is an acc feature or a dialog feature (or perhaps some combination of both).

I'd probably want all the dialog data in a single object (like maybe a json object) or something else easily passable and parsable. A $dlg_json variable would be really awesome for this purpose. I image if cdr_flag was set, it'd have the duration and all in there as well (all the normal stuff it'd be writing to the db).

Bah, Sorry about that, I really went on.

tl/dr: 
1. new $dlg_json variable that stores all data that would normally be written by a acc write (and maybe some additional dialog specific data)
2. new special routes to act as acc module callbacks to be called at specific acc events, which should also work with the cdr_flag. 

Thanks! 
-Brett






 

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

Bogdan-Andrei Iancu-2
Hi Kevin,

The 1.9 (or trunk) is still under development and available only via SVN. You can download it with an SVN client (see http://www.opensips.org/Resources/Downloads#svn):
        svn co https://opensips.svn.sourceforge.net/svnroot/opensips/trunk opensips_head

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 11/29/2012 12:20 PM, Kevin Mathy wrote:
Hi list, 

Is there a possibility now to download 1.9 beta version ? I tried with svn links provided on opensips.org, but, I just can get 1.8.2, no more... 

Thanks a lot, 

Bien cordialement, 
Best Regards, 

Kevin MATHY
HEXANET
--
Phone : +33 (0) 3 26 79 30 05
Tech Support : +33 (0) 3 51 08 42 07




2012/11/28 Brett Nemeroff <[hidden email]>
On Fri, Nov 2, 2012 at 3:49 PM, Rudy <[hidden email]> wrote:
Bogdan,

 Its great to hear all these ideas for 1.9 from the community. One thing that may also be useful, is some enhancements to the rabbit_mq module. It would be great if this module could also push/send events to a any rabbitmq queue or exchange (maybe based on an avp) . Another thing that may be worth exploring is being able to send ACC via a rabbitmq event. What do you think?


I just wanted to throw in my $0.02 here.. And I apologize for pandering. Once I got on it, I realized there's a lot around this that I'd like to see..

I think this is a great idea. Both being able to dynamically control which rabbit queue to send and to have it native in acc.

** What about having native acc callbacks in the routing script? that'd make adopting new technologies for accounting really easy. Like this:

on_dialog_complete {
    new_tech_acc_write("$avp(extra_params)");
}

on_dialog_established {
    new_tech_notify_new_call("$avp(extra_params)")
}

(these new_tech_* funcs are just examples of new modules in the future, like couchbase or perhaps a REST query.

I'm not entirely sure how to go about doing it. But the idea is that the custom "acc callback" routes would be called on specific acc events that would cause acc records to be written. I recognize what I posted above is more of a dialog callback. For my cases specifically, I'd use the cdr flag, and I'd like to know when a call ends. Then I'd write the acc details to the "new technology" backend. So I'm not sure if this is an acc feature or a dialog feature (or perhaps some combination of both).

I'd probably want all the dialog data in a single object (like maybe a json object) or something else easily passable and parsable. A $dlg_json variable would be really awesome for this purpose. I image if cdr_flag was set, it'd have the duration and all in there as well (all the normal stuff it'd be writing to the db).

Bah, Sorry about that, I really went on.

tl/dr: 
1. new $dlg_json variable that stores all data that would normally be written by a acc write (and maybe some additional dialog specific data)
2. new special routes to act as acc module callbacks to be called at specific acc events, which should also work with the cdr_flag. 

Thanks! 
-Brett






 

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________ Users mailing list [hidden email] http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] [RELEASES] Planing OpenSIPS 1.9.0 major release

Bogdan-Andrei Iancu-2
In reply to this post by Brett Nemeroff
Hi Brett,

The events stuff works a bit the other way around - you do not decide where to send the event, but the consumer entities subscribe to you in order to receive events. So it is not push, but pull. The consumer decides (via subscription process) what event to receive, for how long and what backend to be used.

Regarding the ACC event, I will add it on the TODO list on 1.9 .

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 11/28/2012 04:37 PM, Brett Nemeroff wrote:
On Fri, Nov 2, 2012 at 3:49 PM, Rudy <[hidden email]> wrote:
Bogdan,

 Its great to hear all these ideas for 1.9 from the community. One thing that may also be useful, is some enhancements to the rabbit_mq module. It would be great if this module could also push/send events to a any rabbitmq queue or exchange (maybe based on an avp) . Another thing that may be worth exploring is being able to send ACC via a rabbitmq event. What do you think?


I just wanted to throw in my $0.02 here.. And I apologize for pandering. Once I got on it, I realized there's a lot around this that I'd like to see..

I think this is a great idea. Both being able to dynamically control which rabbit queue to send and to have it native in acc.

** What about having native acc callbacks in the routing script? that'd make adopting new technologies for accounting really easy. Like this:

on_dialog_complete {
    new_tech_acc_write("$avp(extra_params)");
}

on_dialog_established {
    new_tech_notify_new_call("$avp(extra_params)")
}

(these new_tech_* funcs are just examples of new modules in the future, like couchbase or perhaps a REST query.

I'm not entirely sure how to go about doing it. But the idea is that the custom "acc callback" routes would be called on specific acc events that would cause acc records to be written. I recognize what I posted above is more of a dialog callback. For my cases specifically, I'd use the cdr flag, and I'd like to know when a call ends. Then I'd write the acc details to the "new technology" backend. So I'm not sure if this is an acc feature or a dialog feature (or perhaps some combination of both).

I'd probably want all the dialog data in a single object (like maybe a json object) or something else easily passable and parsable. A $dlg_json variable would be really awesome for this purpose. I image if cdr_flag was set, it'd have the duration and all in there as well (all the normal stuff it'd be writing to the db).

Bah, Sorry about that, I really went on.

tl/dr: 
1. new $dlg_json variable that stores all data that would normally be written by a acc write (and maybe some additional dialog specific data)
2. new special routes to act as acc module callbacks to be called at specific acc events, which should also work with the cdr_flag. 

Thanks! 
-Brett






 
_______________________________________________ Users mailing list [hidden email] http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users