Re: [OpenSIPS-Users] Permissions module database

[Brett Nemeroff]

You should be able to..

Check out:
http://www.opensips.org/html/docs/modules/1.6.x/permissions.html#id271903


On Thu, Apr 15, 2010 at 1:41 PM, Antonio Anderson Souza
 wrote:
> Hi,
>
> I'd like to know if it's possible to have the allow and deny rules in a
> database table instead of in files, Can I use the address table to make the
> permissions based on the FROM and RURI rules?
>
> Best regards,
>
> Antonio Anderson Souza
> Voice Technology
> http://www.antonioams.com
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Opensips Control Panel - User

[Erick Chinchilla Berrocal]

Alex 

I explain the situation with more detail. But don’t is working the opensips
control-panel

With the opensips

I can register phones (X-Lite), make calls, add, remove with the application
“opensipsctl”

opensipsctl monitor

[cycle #: 4; if constant make sure server lives]

Server:: OpenSIPS (1.6.2-notls (i386/linux))

Now:: Thu Apr 15 09:35:01 2010

Up since:: Thu Apr 15 09:21:31 2010

Up time:: 810 [sec]

Transaction Statistics: 

tm:UAS_transactions = 3

tm:UAC_transactions = 0

tm:inuse_transactions = 0

 

Stateless Server Statistics: 

sl:sent_replies = 524

sl:sent_err_replies = 0

sl:received_ACKs = 0

 

UsrLoc Stats: 

usrloc:registered_users = 2

usrloc:location-users = 2

usrloc:location-contacts = 2

usrloc:location-expires = 0

 

 

 

With the Opensips Control Panel

Module USER

-  I can register phones (X-Lite), add, remove

-  “USER Management

o   Can see all user, with the options “All User”

o   When search the “Online USER” and put the boton ‘Search” , don't look
any register

-  System 

o   CDRViewer

§  don't look any register

o   Dialog

§  don't look any calls in progress

-  MySql

o   The user opensips work well with the default password

o   We can see the user in ./subscriber/username

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Permissions module database

[Antonio Anderson Souza]

Hi,

I'd like to know if it's possible to have the allow and deny rules in a
database table instead of in files, Can I use the address table to make the
permissions based on the FROM and RURI rules?

Best regards,

Antonio Anderson Souza
Voice Technology
http://www.antonioams.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] B2B No TO TAG found

[Antonio Anderson Souza]

Dear Anca,

I just tested it, and it's working perfectly!

Thank you very much for your support,

Antonio Anderson Souza
Voice Technology
http://www.antonioams.com


On Thu, Apr 15, 2010 at 12:17 PM, Anca Vamanu  wrote:

> Antonio Anderson Souza wrote:
> > Hi,
> >
> > I have on doubt, my scenario I have a SIP-Phone A that calls a
> > SIP-Phone B establish the calls, after some time the SIP-Phone B send
> > a Refer with Refer-To header pointing to a SIP-Phone C, the call
> > scenario is working properly, except that the Invite generated by the
> > B2B scenario to transfer the call to the SIP-Phone C is generated with
> > the SIP-Phone B as From, so to the SIP-Phone C seams that the
> > SIP-Phone B are calling him, but who is calling is SIP-Phone A.
> >
> > There are some way to change this behavior in the B2B call scenario,
> > or Can i use the UAC module in the script to replace the From header?
> >
> > Regards,
> >
> > Antonio Anderson Souza
> > Voice Technology
> > http://www.antonioams.com
> >
> Hi Antonio,
>
> I have just committed a fix. Can you please update and test?
>
> Regards,
>
> --
> Anca Vamanu
> www.voice-system.ro
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] One dispatcher mystery solved; Doesn't seem to be "remembering" a gateway is failed however

[Jock McKechnie]

On Thu, Apr 15, 2010 at 8:41 AM, Bogdan-Andrei Iancu  wrote:

> Jock McKechnie wrote:
> >
> >
> > On Tue, Apr 13, 2010 at 5:04 AM, Bogdan-Andrei Iancu
> > mailto:bog...@voice-system.ro>> wrote:
> >
> > Hi Jock,
> >
> > Jock McKechnie wrote:
> > >
> > > On Mon, Apr 12, 2010 at 10:48 AM, Bogdan-Andrei Iancu
> > > mailto:bog...@voice-system.ro>
> > >>
> > wrote:
> > >
> > > Hi Jock,
> > > > I'm wondering if the above error is some kind of AVP
> > storage thing I
> > > > haven't set up that is causing it not to properly "mark" the
> > > gateway,
> > > > or more likely, not remember the mark. But I can't spot
> > anything in
> > > > the dispatcher documentation that says as such.
> > > your guess is right - dispatcher module uses AVPs to keep
> > the state
> > > (between sequential tries on the same dialog).
> > >
> > > I guess the ds_mark_dst() fails - can you check this?
> > (this function
> > > search for the dst and grp avps to identify the last tried
> > > destination.).
> > >
> > > Greetings Bogdan, and thanks as always;
> > >
> > > I tried this:
> > > if( t_check_status("408") ){
> > > xlog( "L_NOTICE", "[$Tf] FR: $ci -- TIMEOUT for
> > > Gateway $rd (marking as bad)\n" );
> > > if (!ds_mark_dst("p")) {
> > > xlog("L_NOTICE", "[$Tf] Panic! Not
> > marked\n");
> > > }
> > > }
> > >
> > > No 'Panic' in the logs.
> > >
> > > The dst and grp AVPs are set up, as you saw on my original post,
> > > but... that doesn't mean I'm not missing anything.
> > >
> > So, ds_mark does not fail .
> >
> > Are you 100% sure your script does define the "cnt" "grp" "dst" avp
> > params for the dispatcher module 
> >
> > Unless somehow I'm doing it wrong, pretty sure:
> >
> > # Set up the dispatcher
> > modparam("dispatcher", "db_url",
> > "mysql://openser:passw...@192.168.0.20/company
> > ")
> > modparam("dispatcher", "table_name", "dispatcher")
> > modparam("dispatcher", "flags", 2 )
> >
> > modparam("dispatcher", "dst_avp", "$avp(i:271)")
> > modparam("dispatcher", "grp_avp", "$avp(i:272)")
> > modparam("dispatcher", "cnt_avp", "$avp(i:273)")
> >
> > modparam("dispatcher", "ds_ping_method", "OPTIONS")
> > modparam("dispatcher", "ds_ping_interval", 5)
> > modparam("dispatcher", "ds_ping_from", 
> > "sip:+1410...@192.168.0.2
> >  >")
> > modparam("dispatcher", "ds_probing_threshhold", 3)
> >
> > As far as I can tell from the documentation and other people's
> > examples, this should be all that is required to make this function...
> >
> Could you check and be sure the error:
>
>ERROR:core:search_first_avp: 0 ID or NULL NAME AVP!
>
> comes from the ds_mark_dst() ? - put some logs before and after it. Also
> eabling full debug (level 4) may also help.
>
>
My apologies, Bogdan, I should have done this better myself. I have traced
the error to the ds_next_domain():

Config section from inside failure_route[]:

xlog("L_NOTICE", "[$Tf] HEREA\n");
if (ds_next_domain()) {
xlog("L_NOTICE", "[$Tf] HEREB\n");
.
.

The logs contain:
[Thu Apr 15 11:23:06 2010] HEREA
ERROR:core:search_first_avp: 0 ID or NULL NAME AVP!
DBG:dispatcher:ds_next_dst: using [sip:192.168.0.20:5060]
[Thu Apr 15 11:23:06 2010] HEREB


So clearly the ds_next_domain() is producing it. However the function -is-
returning the correct next entry in the dispatcher list, which is bizarre.
I'm not sure, now, how this related to ds_select_domain() incorrectly
choosing "marked" entries, alas.

Cheers;

  - Jock
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transport follow up

[Daniel Goepp]

Okay, thanks for the info, I will try serial forking.  As per one of the
previous threads regarding this, one of the ways recommended to force a
transport was to tag the RURI, for example:

if($rd="proxy.othercompany.com"){
$rd = "proxy.othercompany.com;transport=TCP";
}

Although this does seem to force the transport, I'm having some troubles
with media getting setup when I do this.  Is this the method you would
recommend, or do you have a better way to force a specific transport?

Thanks

-dg


On Thu, Apr 15, 2010 at 9:02 AM, Bogdan-Andrei Iancu  wrote:

> exactly, and you can configure in opensips cfg whatever sequence of
> protocols to be tried (by doing serial forking).
>
> Regards,
> Bogdan
>
> Daniel Goepp wrote:
> > If NAPTR was the method being used, but in this case is not setup.  So
> > the problem I'm trying to solve is what to do when the endpoints and
> > the other gateways are not being explicit via either URI or DNS.  The
> > endpoint is not specifying transport in the RURI, and DNS SRV is setup
> > and exists with entries for both TCP and UDP, but no NAPTR.  In this
> > case, it's really leaving it up to the proxy to decide what transport
> > to prefer.
> >
> > -dg
> >
> >
> > On Thu, Apr 15, 2010 at 8:44 AM, Bogdan-Andrei Iancu
> > mailto:bog...@voice-system.ro>> wrote:
> >
> > Daniel,
> >
> > So, the transport to be used is chosen as follows:
> >A)  if "transport" in URI -> use it
> >B)  if no port in URI, try to use NAPTR
> >B1) if NAPTR -> use the advertised protocols as per weight and
> > priority in NAPTR records (in the given order)
> >B2) if no NAPTR -> it is up to the proxy to choose the protocol
> > (obeying the URI scheme, like sips).
> >
> > I guess you are referring to B2 case, which you can do in script,
> > using
> > a serial forking scenario (forcing different protos via $du ).
> >
> > Regards,
> > Bogdan
> >
> > Daniel Goepp wrote:
> > > I did, but I don't see anything that says it would be a violation
> of
> > > SIP to try a number of transports in sequence, and to determine
> that
> > > sequence by the proxy.  And I do understand that this is not a
> > problem
> > > with OpenSIPS, just trying to find a way to accomplish something
> new
> > > perhaps.  We are working with some other networks which use a
> > > different method of selecting transport.  And we are trying to
> > > implement a similar method to select transport using OpenSIPS.
>  Very
> > > similar to how route advancing works, but at the transport level.
>  I
> > > am working now to do it at the scripting level, but just thought
> > this
> > > might be something to consider actually implementing as
> > functionality
> > > at the application level.  Perhaps it is just too unique of a
> > problem
> > > and not worth it.  The problem I believe is UDP is clearly the most
> > > commonly used transport, but as devices get more capable (for
> > example
> > > in our situation with large SDPs for video, and traversing multiple
> > > proxies adding record routes), packet sizes get larger, and TCP
> > > becomes a more reliable transport.  Additionally many folks we work
> > > with would prefer that is a secure connection is available, then it
> > > should be used.  So the defaults on their network proxies will
> > attempt
> > > in the order of TLS, TCP then UDP to place a call.
> > >
> > > I will continue my work to try to get this going, but thought I
> > would
> > > post for comments here to get thoughts on the matter, or
> > > recommendations on how this would be best implemented using
> > OpenSIPS.
> > >
> > > Thanks.
> > >
> > > -dg
> > >
> > >
> > > On Thu, Apr 15, 2010 at 1:59 AM, Bogdan-Andrei Iancu
> > > mailto:bog...@voice-system.ro>
> > >>
> > wrote:
> > >
> > > Hi Daniel,
> > >
> > >
> > > Have you read RFC3263 about Locating SIP Servers  (with proto
> > > selection)  ?
> > >
> > >http://www.ietf.org/rfc/rfc3263.txt
> > >
> > > Regards,
> > > Bogdan
> > >
> > > Daniel Goepp wrote:
> > > > I had a previous question regarding default transport, and
> the
> > > > response I got was that the RFC says the order should be UDP,
> > > TCP then
> > > > TLS.  However after reading into this further (and some
> recent
> > > > experiences with other platforms) I'm wondering if I have
> > a new
> > > > feature request for OpenSIPS.  >From the RFC 3263 -
> > Section 4.1
> > > > Selecting a Transport Protocol, I read it as saying:
> > > >
> > > > 1.  If specified in the RURI it SHOULD use this (but doesn't
> > > have to)
> > 

Re: [OpenSIPS-Users] Transport follow up

[Bogdan-Andrei Iancu]

exactly, and you can configure in opensips cfg whatever sequence of 
protocols to be tried (by doing serial forking).

Regards,
Bogdan

Daniel Goepp wrote:
> If NAPTR was the method being used, but in this case is not setup.  So 
> the problem I'm trying to solve is what to do when the endpoints and 
> the other gateways are not being explicit via either URI or DNS.  The 
> endpoint is not specifying transport in the RURI, and DNS SRV is setup 
> and exists with entries for both TCP and UDP, but no NAPTR.  In this 
> case, it's really leaving it up to the proxy to decide what transport 
> to prefer.
>
> -dg
>
>
> On Thu, Apr 15, 2010 at 8:44 AM, Bogdan-Andrei Iancu 
> mailto:bog...@voice-system.ro>> wrote:
>
> Daniel,
>
> So, the transport to be used is chosen as follows:
>A)  if "transport" in URI -> use it
>B)  if no port in URI, try to use NAPTR
>B1) if NAPTR -> use the advertised protocols as per weight and
> priority in NAPTR records (in the given order)
>B2) if no NAPTR -> it is up to the proxy to choose the protocol
> (obeying the URI scheme, like sips).
>
> I guess you are referring to B2 case, which you can do in script,
> using
> a serial forking scenario (forcing different protos via $du ).
>
> Regards,
> Bogdan
>
> Daniel Goepp wrote:
> > I did, but I don't see anything that says it would be a violation of
> > SIP to try a number of transports in sequence, and to determine that
> > sequence by the proxy.  And I do understand that this is not a
> problem
> > with OpenSIPS, just trying to find a way to accomplish something new
> > perhaps.  We are working with some other networks which use a
> > different method of selecting transport.  And we are trying to
> > implement a similar method to select transport using OpenSIPS.  Very
> > similar to how route advancing works, but at the transport level.  I
> > am working now to do it at the scripting level, but just thought
> this
> > might be something to consider actually implementing as
> functionality
> > at the application level.  Perhaps it is just too unique of a
> problem
> > and not worth it.  The problem I believe is UDP is clearly the most
> > commonly used transport, but as devices get more capable (for
> example
> > in our situation with large SDPs for video, and traversing multiple
> > proxies adding record routes), packet sizes get larger, and TCP
> > becomes a more reliable transport.  Additionally many folks we work
> > with would prefer that is a secure connection is available, then it
> > should be used.  So the defaults on their network proxies will
> attempt
> > in the order of TLS, TCP then UDP to place a call.
> >
> > I will continue my work to try to get this going, but thought I
> would
> > post for comments here to get thoughts on the matter, or
> > recommendations on how this would be best implemented using
> OpenSIPS.
> >
> > Thanks.
> >
> > -dg
> >
> >
> > On Thu, Apr 15, 2010 at 1:59 AM, Bogdan-Andrei Iancu
> > mailto:bog...@voice-system.ro>
> >>
> wrote:
> >
> > Hi Daniel,
> >
> >
> > Have you read RFC3263 about Locating SIP Servers  (with proto
> > selection)  ?
> >
> >http://www.ietf.org/rfc/rfc3263.txt
> >
> > Regards,
> > Bogdan
> >
> > Daniel Goepp wrote:
> > > I had a previous question regarding default transport, and the
> > > response I got was that the RFC says the order should be UDP,
> > TCP then
> > > TLS.  However after reading into this further (and some recent
> > > experiences with other platforms) I'm wondering if I have
> a new
> > > feature request for OpenSIPS.  >From the RFC 3263 -
> Section 4.1
> > > Selecting a Transport Protocol, I read it as saying:
> > >
> > > 1.  If specified in the RURI it SHOULD use this (but doesn't
> > have to)
> > > 2.  Bunch of stuff on NAPTR (which we are not doing)
> > > 3.  The section related to what we are doing:
> > >
> > > -clip-
> > > If no NAPTR records are found, the client constructs SRV
> queries for
> > > those transport protocols it supports, and does a query
> for each.
> > > Queries are done using the service identifier "_sip" for SIP
> > URIs and
> > > "_sips" for SIPS URIs. A particular transport is supported
> if the
> > > query is successful. The client MAY use any transport
> protocol it
> > > desires which is supported by the server.
> > >
> > > This is a change from RFC 2543. It specified that a client
> would
> > > lookup SRV records for all transport

Re: [OpenSIPS-Users] Transport follow up

[Daniel Goepp]

If NAPTR was the method being used, but in this case is not setup.  So the
problem I'm trying to solve is what to do when the endpoints and the other
gateways are not being explicit via either URI or DNS.  The endpoint is not
specifying transport in the RURI, and DNS SRV is setup and exists with
entries for both TCP and UDP, but no NAPTR.  In this case, it's really
leaving it up to the proxy to decide what transport to prefer.

-dg


On Thu, Apr 15, 2010 at 8:44 AM, Bogdan-Andrei Iancu  wrote:

> Daniel,
>
> So, the transport to be used is chosen as follows:
>A)  if "transport" in URI -> use it
>B)  if no port in URI, try to use NAPTR
>B1) if NAPTR -> use the advertised protocols as per weight and
> priority in NAPTR records (in the given order)
>B2) if no NAPTR -> it is up to the proxy to choose the protocol
> (obeying the URI scheme, like sips).
>
> I guess you are referring to B2 case, which you can do in script, using
> a serial forking scenario (forcing different protos via $du ).
>
> Regards,
> Bogdan
>
> Daniel Goepp wrote:
> > I did, but I don't see anything that says it would be a violation of
> > SIP to try a number of transports in sequence, and to determine that
> > sequence by the proxy.  And I do understand that this is not a problem
> > with OpenSIPS, just trying to find a way to accomplish something new
> > perhaps.  We are working with some other networks which use a
> > different method of selecting transport.  And we are trying to
> > implement a similar method to select transport using OpenSIPS.  Very
> > similar to how route advancing works, but at the transport level.  I
> > am working now to do it at the scripting level, but just thought this
> > might be something to consider actually implementing as functionality
> > at the application level.  Perhaps it is just too unique of a problem
> > and not worth it.  The problem I believe is UDP is clearly the most
> > commonly used transport, but as devices get more capable (for example
> > in our situation with large SDPs for video, and traversing multiple
> > proxies adding record routes), packet sizes get larger, and TCP
> > becomes a more reliable transport.  Additionally many folks we work
> > with would prefer that is a secure connection is available, then it
> > should be used.  So the defaults on their network proxies will attempt
> > in the order of TLS, TCP then UDP to place a call.
> >
> > I will continue my work to try to get this going, but thought I would
> > post for comments here to get thoughts on the matter, or
> > recommendations on how this would be best implemented using OpenSIPS.
> >
> > Thanks.
> >
> > -dg
> >
> >
> > On Thu, Apr 15, 2010 at 1:59 AM, Bogdan-Andrei Iancu
> > mailto:bog...@voice-system.ro>> wrote:
> >
> > Hi Daniel,
> >
> >
> > Have you read RFC3263 about Locating SIP Servers  (with proto
> > selection)  ?
> >
> >http://www.ietf.org/rfc/rfc3263.txt
> >
> > Regards,
> > Bogdan
> >
> > Daniel Goepp wrote:
> > > I had a previous question regarding default transport, and the
> > > response I got was that the RFC says the order should be UDP,
> > TCP then
> > > TLS.  However after reading into this further (and some recent
> > > experiences with other platforms) I'm wondering if I have a new
> > > feature request for OpenSIPS.  >From the RFC 3263 - Section 4.1
> > > Selecting a Transport Protocol, I read it as saying:
> > >
> > > 1.  If specified in the RURI it SHOULD use this (but doesn't
> > have to)
> > > 2.  Bunch of stuff on NAPTR (which we are not doing)
> > > 3.  The section related to what we are doing:
> > >
> > > -clip-
> > > If no NAPTR records are found, the client constructs SRV queries
> for
> > > those transport protocols it supports, and does a query for each.
> > > Queries are done using the service identifier "_sip" for SIP
> > URIs and
> > > "_sips" for SIPS URIs. A particular transport is supported if the
> > > query is successful. The client MAY use any transport protocol it
> > > desires which is supported by the server.
> > >
> > > This is a change from RFC 2543. It specified that a client would
> > > lookup SRV records for all transports it supported, and merge the
> > > priority values across those records. Then, it would choose the
> > > most preferred record.
> > >
> > > If no SRV records are found, the client SHOULD use TCP for a SIPS
> > > URI, and UDP for a SIP URI. However, another transport protocol,
> > > such as TCP, MAY be used if the guidelines of SIP mandate it for
> > this
> > > particular request. That is the case, for example, for requests
> that
> > > exceed the path MTU.
> > > -clip-
> > >
> > > The way I read this is that OpenSIPS MAY select whatever
> > transport it
> > > likes, and if no DNS SRV is found, then it would default to
> > using UDP
> >

Re: [OpenSIPS-Users] Transport follow up

[Bogdan-Andrei Iancu]

Daniel,

So, the transport to be used is chosen as follows:
A)  if "transport" in URI -> use it
B)  if no port in URI, try to use NAPTR
B1) if NAPTR -> use the advertised protocols as per weight and 
priority in NAPTR records (in the given order)
B2) if no NAPTR -> it is up to the proxy to choose the protocol 
(obeying the URI scheme, like sips).

I guess you are referring to B2 case, which you can do in script, using 
a serial forking scenario (forcing different protos via $du ).

Regards,
Bogdan

Daniel Goepp wrote:
> I did, but I don't see anything that says it would be a violation of 
> SIP to try a number of transports in sequence, and to determine that 
> sequence by the proxy.  And I do understand that this is not a problem 
> with OpenSIPS, just trying to find a way to accomplish something new 
> perhaps.  We are working with some other networks which use a 
> different method of selecting transport.  And we are trying to 
> implement a similar method to select transport using OpenSIPS.  Very 
> similar to how route advancing works, but at the transport level.  I 
> am working now to do it at the scripting level, but just thought this 
> might be something to consider actually implementing as functionality 
> at the application level.  Perhaps it is just too unique of a problem 
> and not worth it.  The problem I believe is UDP is clearly the most 
> commonly used transport, but as devices get more capable (for example 
> in our situation with large SDPs for video, and traversing multiple 
> proxies adding record routes), packet sizes get larger, and TCP 
> becomes a more reliable transport.  Additionally many folks we work 
> with would prefer that is a secure connection is available, then it 
> should be used.  So the defaults on their network proxies will attempt 
> in the order of TLS, TCP then UDP to place a call.
>
> I will continue my work to try to get this going, but thought I would 
> post for comments here to get thoughts on the matter, or 
> recommendations on how this would be best implemented using OpenSIPS.
>
> Thanks.
>
> -dg
>
>
> On Thu, Apr 15, 2010 at 1:59 AM, Bogdan-Andrei Iancu 
> mailto:bog...@voice-system.ro>> wrote:
>
> Hi Daniel,
>
>
> Have you read RFC3263 about Locating SIP Servers  (with proto
> selection)  ?
>
>http://www.ietf.org/rfc/rfc3263.txt
>
> Regards,
> Bogdan
>
> Daniel Goepp wrote:
> > I had a previous question regarding default transport, and the
> > response I got was that the RFC says the order should be UDP,
> TCP then
> > TLS.  However after reading into this further (and some recent
> > experiences with other platforms) I'm wondering if I have a new
> > feature request for OpenSIPS.  >From the RFC 3263 - Section 4.1
> > Selecting a Transport Protocol, I read it as saying:
> >
> > 1.  If specified in the RURI it SHOULD use this (but doesn't
> have to)
> > 2.  Bunch of stuff on NAPTR (which we are not doing)
> > 3.  The section related to what we are doing:
> >
> > -clip-
> > If no NAPTR records are found, the client constructs SRV queries for
> > those transport protocols it supports, and does a query for each.
> > Queries are done using the service identifier "_sip" for SIP
> URIs and
> > "_sips" for SIPS URIs. A particular transport is supported if the
> > query is successful. The client MAY use any transport protocol it
> > desires which is supported by the server.
> >
> > This is a change from RFC 2543. It specified that a client would
> > lookup SRV records for all transports it supported, and merge the
> > priority values across those records. Then, it would choose the
> > most preferred record.
> >
> > If no SRV records are found, the client SHOULD use TCP for a SIPS
> > URI, and UDP for a SIP URI. However, another transport protocol,
> > such as TCP, MAY be used if the guidelines of SIP mandate it for
> this
> > particular request. That is the case, for example, for requests that
> > exceed the path MTU.
> > -clip-
> >
> > The way I read this is that OpenSIPS MAY select whatever
> transport it
> > likes, and if no DNS SRV is found, then it would default to
> using UDP
> > first for SIP.  But in our set, DNS SRV does exist, and there
> are both
> > TCP and UDP records.  We would like to decide the default transport
> > order to use, starting with TLS then TCP then UDP.  I think I
> can try
> > to write something in the script to do this, but I'm not sure
> yet.  I
> > don't want to rewrite the RURI, I just want to specify the
> transport.
> > It would be great if there was a global variable defined in the
> config
> > that was something like "transport_order=TLS,TCP,UDP"
> >
> > Thoughts?
> >
> > -dg
> >
> ---

Re: [OpenSIPS-Users] B2B No TO TAG found

[Anca Vamanu]

Antonio Anderson Souza wrote:
> Hi,
>
> I have on doubt, my scenario I have a SIP-Phone A that calls a 
> SIP-Phone B establish the calls, after some time the SIP-Phone B send 
> a Refer with Refer-To header pointing to a SIP-Phone C, the call 
> scenario is working properly, except that the Invite generated by the 
> B2B scenario to transfer the call to the SIP-Phone C is generated with 
> the SIP-Phone B as From, so to the SIP-Phone C seams that the 
> SIP-Phone B are calling him, but who is calling is SIP-Phone A.
>
> There are some way to change this behavior in the B2B call scenario, 
> or Can i use the UAC module in the script to replace the From header?
>
> Regards,
>
> Antonio Anderson Souza
> Voice Technology
> http://www.antonioams.com
>
Hi Antonio,

I have just committed a fix. Can you please update and test?

Regards,

--
Anca Vamanu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Opensips Control Panel - Statistics Monitor - Statistics Charts

[Erick Chinchilla Berrocal]

Alex

I can fix this issue

Thanks for your help 

 

I made the following change according your recommendation

chown www-data:www-data
/var/www/opensips-cp/web/tools/system/smonitor/generated -R

 

/var/www/opensips-cp/web/tools/system/smonitor/generated# ls -al

total 32

drwxr-xr-x 2 www-data www-data 4096 2010-04-15 08:40 .

drwxr-xr-x 7 root root 4096 2010-03-08 12:54 ..

-rw-r--r-- 1 www-data www-data 5664 2010-04-15 08:40 core:bad_msg_hdr.png

-rw-r--r-- 1 www-data www-data 5700 2010-04-15 08:40 core:bad_URIs_rcvd.png

-rw-r--r-- 1 www-data www-data 5312 2010-04-15 08:40 core:drop_replies.png

 

Thanks

Erick Ch.

From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Alex Ionescu
Sent: Thursday, April 15, 2010 3:01 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Opensips Control Panel - Statistics Monitor -
Statistics Charts

 

Hi Erick,

I think I have a solution for you problem.
You need to give apache/httpd write permissions on the folder
../opensips-cp/web/tools/system/smonitor/generated 
This is because apache is trying to create a png file in that folder. 
Let me know if you succeeded.

Regards,
Alex
On 4/14/2010 22:46, Erick Chinchilla Berrocal wrote: 

agepng($this->img, $fileName);

 

/var/www/opensips-cp/web/tools/system/smonitor/lib/libchart/classes/view/plo
t# vim Plot.php

 

please let me know what is the procedure for fix the problem

 

Thanks






-- 
Alex Ionescu
www.voice-system.ro 



__ Information from ESET NOD32 Antivirus, version of virus signature
database 3997 (20090409) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transport follow up

[Daniel Goepp]

I did, but I don't see anything that says it would be a violation of SIP to
try a number of transports in sequence, and to determine that sequence by
the proxy.  And I do understand that this is not a problem with OpenSIPS,
just trying to find a way to accomplish something new perhaps.  We are
working with some other networks which use a different method of selecting
transport.  And we are trying to implement a similar method to select
transport using OpenSIPS.  Very similar to how route advancing works, but at
the transport level.  I am working now to do it at the scripting level, but
just thought this might be something to consider actually implementing as
functionality at the application level.  Perhaps it is just too unique of a
problem and not worth it.  The problem I believe is UDP is clearly the most
commonly used transport, but as devices get more capable (for example in our
situation with large SDPs for video, and traversing multiple proxies adding
record routes), packet sizes get larger, and TCP becomes a more reliable
transport.  Additionally many folks we work with would prefer that is a
secure connection is available, then it should be used.  So the defaults on
their network proxies will attempt in the order of TLS, TCP then UDP to
place a call.

I will continue my work to try to get this going, but thought I would post
for comments here to get thoughts on the matter, or recommendations on how
this would be best implemented using OpenSIPS.

Thanks.

-dg


On Thu, Apr 15, 2010 at 1:59 AM, Bogdan-Andrei Iancu  wrote:

> Hi Daniel,
>
>
> Have you read RFC3263 about Locating SIP Servers  (with proto selection)  ?
>
>http://www.ietf.org/rfc/rfc3263.txt
>
> Regards,
> Bogdan
>
> Daniel Goepp wrote:
> > I had a previous question regarding default transport, and the
> > response I got was that the RFC says the order should be UDP, TCP then
> > TLS.  However after reading into this further (and some recent
> > experiences with other platforms) I'm wondering if I have a new
> > feature request for OpenSIPS.  >From the RFC 3263 - Section 4.1
> > Selecting a Transport Protocol, I read it as saying:
> >
> > 1.  If specified in the RURI it SHOULD use this (but doesn't have to)
> > 2.  Bunch of stuff on NAPTR (which we are not doing)
> > 3.  The section related to what we are doing:
> >
> > -clip-
> > If no NAPTR records are found, the client constructs SRV queries for
> > those transport protocols it supports, and does a query for each.
> > Queries are done using the service identifier "_sip" for SIP URIs and
> > "_sips" for SIPS URIs. A particular transport is supported if the
> > query is successful. The client MAY use any transport protocol it
> > desires which is supported by the server.
> >
> > This is a change from RFC 2543. It specified that a client would
> > lookup SRV records for all transports it supported, and merge the
> > priority values across those records. Then, it would choose the
> > most preferred record.
> >
> > If no SRV records are found, the client SHOULD use TCP for a SIPS
> > URI, and UDP for a SIP URI. However, another transport protocol,
> > such as TCP, MAY be used if the guidelines of SIP mandate it for this
> > particular request. That is the case, for example, for requests that
> > exceed the path MTU.
> > -clip-
> >
> > The way I read this is that OpenSIPS MAY select whatever transport it
> > likes, and if no DNS SRV is found, then it would default to using UDP
> > first for SIP.  But in our set, DNS SRV does exist, and there are both
> > TCP and UDP records.  We would like to decide the default transport
> > order to use, starting with TLS then TCP then UDP.  I think I can try
> > to write something in the script to do this, but I'm not sure yet.  I
> > don't want to rewrite the RURI, I just want to specify the transport.
> > It would be great if there was a global variable defined in the config
> > that was something like "transport_order=TLS,TCP,UDP"
> >
> > Thoughts?
> >
> > -dg
> > 
> >
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
>
>
> --
> Bogdan-Andrei Iancu
> www.voice-system.ro
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] One dispatcher mystery solved; Doesn't seem to be "remembering" a gateway is failed however

[Bogdan-Andrei Iancu]

Jock McKechnie wrote:
>
>
> On Tue, Apr 13, 2010 at 5:04 AM, Bogdan-Andrei Iancu 
> mailto:bog...@voice-system.ro>> wrote:
>
> Hi Jock,
>
> Jock McKechnie wrote:
> >
> > On Mon, Apr 12, 2010 at 10:48 AM, Bogdan-Andrei Iancu
> > mailto:bog...@voice-system.ro>
> >>
> wrote:
> >
> > Hi Jock,
> > > I'm wondering if the above error is some kind of AVP
> storage thing I
> > > haven't set up that is causing it not to properly "mark" the
> > gateway,
> > > or more likely, not remember the mark. But I can't spot
> anything in
> > > the dispatcher documentation that says as such.
> > your guess is right - dispatcher module uses AVPs to keep
> the state
> > (between sequential tries on the same dialog).
> >
> > I guess the ds_mark_dst() fails - can you check this?  
> (this function
> > search for the dst and grp avps to identify the last tried
> > destination.).
> >
> > Greetings Bogdan, and thanks as always;
> >
> > I tried this:
> > if( t_check_status("408") ){
> > xlog( "L_NOTICE", "[$Tf] FR: $ci -- TIMEOUT for
> > Gateway $rd (marking as bad)\n" );
> > if (!ds_mark_dst("p")) {
> > xlog("L_NOTICE", "[$Tf] Panic! Not
> marked\n");
> > }
> > }
> >
> > No 'Panic' in the logs.
> >
> > The dst and grp AVPs are set up, as you saw on my original post,
> > but... that doesn't mean I'm not missing anything.
> >
> So, ds_mark does not fail .
>
> Are you 100% sure your script does define the "cnt" "grp" "dst" avp
> params for the dispatcher module 
>
> Unless somehow I'm doing it wrong, pretty sure:
>
> # Set up the dispatcher
> modparam("dispatcher", "db_url", 
> "mysql://openser:passw...@192.168.0.20/company 
> ")
> modparam("dispatcher", "table_name", "dispatcher")
> modparam("dispatcher", "flags", 2 )
>
> modparam("dispatcher", "dst_avp", "$avp(i:271)")
> modparam("dispatcher", "grp_avp", "$avp(i:272)")
> modparam("dispatcher", "cnt_avp", "$avp(i:273)")
>
> modparam("dispatcher", "ds_ping_method", "OPTIONS")
> modparam("dispatcher", "ds_ping_interval", 5)
> modparam("dispatcher", "ds_ping_from", "sip:+1410...@192.168.0.2 
> ")
> modparam("dispatcher", "ds_probing_threshhold", 3)
>  
> As far as I can tell from the documentation and other people's 
> examples, this should be all that is required to make this function...
>
Could you check and be sure the error:

ERROR:core:search_first_avp: 0 ID or NULL NAME AVP!

comes from the ds_mark_dst() ? - put some logs before and after it. Also 
eabling full debug (level 4) may also help.

Regards,
Bogdan


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Opensips Control Panel - User

[Alex Ionescu]

 Hi Erick,

So, I understand that you have OCP installed.

On 4/15/2010 00:56, Erick Chinchilla Berrocal wrote:


FYI

I installed the opensips-cp

Now we have the following issue

Opensips Control Panel -- Module User

- We can add, remove users with the control panel and with opensipsctl

- We used two ip softphone "X-Lite" , the register is ok , make calls 
between the phones ( 1001 to 1002) ( 1002 a 1001)


- With the commands

opensipsctl ul show

opensipsctl monitor

the informations are ok

With the control panel with the control panel, I can see the user, add 
o remove


now we don't see the users if are online or no

I think that you should be able to see the online user by checking the 
"Online Users" radio button in the Search box under the User Management tab


We don't look any call in the control panel , module CDRViewer o Dialog

Well, to see calls in the CDR Viewer you have to make some configs (see 
the INSTALL file - see the three steps there - tables, stored procedure 
and a script to be put in cron)
To see the dialogs in Dialog module you have to load & configure the 
module *dialog* into the OpenSIPS config. - that is why you get errors 
like "*ERROR:mi_fifo:mi_fifo_server: command dlg_list is not 
available*". (I can see that you have other NOT loaded modules - like 
dispatcher ... )


Edit this file, but I have the same problem, according this link 
http://opensips-cp.sourceforge.net/


*opensips-cp/config/tools/admin/list_admins/db.inc.php*

This is the log/opensips

Apr 14 15:30:04 net /sbin/opensips[2750]: 
ERROR:mi_fifo:mi_fifo_server: command dlg_list is not available


Apr 14 15:30:06 net /sbin/opensips[2750]: 
ERROR:mi_fifo:mi_fifo_server: command ds_list is not available


Apr 14 15:30:06 net /sbin/opensips[2750]: 
ERROR:mi_fifo:mi_fifo_server: command ds_reload is not available


Apr 14 15:30:16 net /sbin/opensips[2750]: 
ERROR:mi_fifo:mi_fifo_server: command sip_trace is not available


Apr 14 15:30:22 net /sbin/opensips[2750]: 
ERROR:mi_fifo:mi_fifo_server: command sip_trace is not available


Apr 14 15:30:23 net /sbin/opensips[2750]: 
ERROR:mi_fifo:mi_fifo_server: command sip_trace is not available


Apr 14 15:30:36 net /sbin/opensips[2750]: 
ERROR:mi_fifo:mi_fifo_server: command dlg_list is not available


Apr 14 15:30:38 net /sbin/opensips[2750]: 
ERROR:mi_fifo:mi_fifo_server: command ds_list is not available


Apr 14 15:30:38 net /sbin/opensips[2750]: 
ERROR:mi_fifo:mi_fifo_server: command ds_reload is not available


Apr 14 15:37:39 net /sbin/opensips[2750]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:39 net /sbin/opensips[2737]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:39 net /sbin/opensips[2735]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:39 net /sbin/opensips[2734]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:39 net /sbin/opensips[2738]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:39 net /sbin/opensips[2748]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:39 net /sbin/opensips[2733]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:39 net /sbin/opensips[2752]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:39 net /sbin/opensips[2741]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:39 net /sbin/opensips[2760]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:39 net /sbin/opensips[2736]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:39 net /sbin/opensips[2758]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:39 net /sbin/opensips[2743]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:39 net /sbin/opensips[2754]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:39 net /sbin/opensips[2744]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:39 net /sbin/opensips[2755]: INFO:core:sig_usr: signal 15 
received


Apr 14 15:37:40 net opensips: INFO:core:init_tcp: using epoll_lt as 
the TCP io watch method (auto detected)


Apr 14 15:37:40 net /sbin/opensips[5466]: NOTICE:core:main: version: 
opensips 1.6.2-notls (i386/linux)


Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:core:main: using 128 Mb 
shared memory


Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:core:main: using 1 Mb 
private memory per process


Apr 14 15:37:40 net /sbin/opensips[5466]: NOTICE:signaling:mod_init: 
initializing module ...


Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:sl:mod_init: 
Initializing StateLess engine


Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:tm:mod_init: TM - 
initializing...


Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:maxfwd:mod_init: 
initializing...


Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:usrloc:ul_init_locks: 
locks array size 512


Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:registrar:mod_init: 
initializing...


Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:textops:mod_init: 
initializing...


Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:xlog:mod_init: 
initializing...


Apr 14 15:37:40 net /sbin/opensips[5466]: INFO:acc:mod_init: 
init

Re: [OpenSIPS-Users] B2B No TO TAG found

[Anca Vamanu]

Hi Antonio,

This is in fact a bug. I will fix it and let you know.

Regards,

-- 
Anca Vamanu
www.voice-system.ro



Antonio Anderson Souza wrote:
> Hi,
>
> I have on doubt, my scenario I have a SIP-Phone A that calls a 
> SIP-Phone B establish the calls, after some time the SIP-Phone B send 
> a Refer with Refer-To header pointing to a SIP-Phone C, the call 
> scenario is working properly, except that the Invite generated by the 
> B2B scenario to transfer the call to the SIP-Phone C is generated with 
> the SIP-Phone B as From, so to the SIP-Phone C seams that the 
> SIP-Phone B are calling him, but who is calling is SIP-Phone A.
>
> There are some way to change this behavior in the B2B call scenario, 
> or Can i use the UAC module in the script to replace the From header?
>
> Regards,
>
> Antonio Anderson Souza
> Voice Technology
> http://www.antonioams.com
>
>

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Call not being routed correctly with OSP module

[brianpocock]

Hi,

I'm using OpenSIPS in a test environment with an OSP server to provide
authorization for calls. The setup is 2 phones and an opensips sip proxy.   
SIP proxy has an IP of 192.168.1.2
Testphone has an IP of 192.168.1.4 and number 1202
Testphone 2 has an IP of 192.168.1.5 and number 1203
With no accounts setup on the OSP server when I try and make a call the sip
proxy returns a 503 because the device is not authorized by the OSP server.  
Now I have added devices to the OSP server and am trying to make a call from
1203 to 1202 I'm getting 404's.   When looking at call detail records on the
OSP server there are four calls there even though I only placed one.   They
all have sources of 192.168.1.5 and destinations of 1202 except one that has
a destination of 192.168.1.4 which is the IP of the phone I want to reach.  
The output in the opensips logfile of the routing logic is shown below:

ROUTE: Route IN - M=INVITE RURI=sip:1...@192.168.1.2
F=sip:testpho...@192.168.1.2 T=sip:1...@192.168.1.2 IP=192.168.1.5
id=001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5 
ROUTE: Processing INVITE 
OSP authorization validation logic 
Without OSP token, apply different authentication strategy 
Go ahead, everyone is welcomed 
ROUTE: Authentication passed 
ROUTE: Use OSP to get routing 
OSP authorization and routing logic 
Requesting OSP authorization and routing 
INFO:osp:ospRequestRouting: request auth and routing for: service_type '0'
source '[192.168.1.2]:5060' source_dev '[192.168.1.5]:5060' source_networkid
'' calling 'testphone2' called '1202' preferred '' nprn '' npcic '' npdi '0'
spid '' ocn '' spn '' altspn '' mcc '' mnc '' diversion_user ''
diversion_host '' call_id '001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5'
dest_count '5'  
INFO:osp:ospLoadRoutes: get destination '0': valid after
'2010-04-15T10:47:06Z' valid until '2010-04-15T10:57:06Z' time limit '14400'
seconds call id '001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5' calling
'testphone2' called '1202' host '[192.168.1.5]' nprn '' npcic '' npdi '0'
spid '' ocn '' spn '' altspn '' mcc '' mnc '' supported '1' network id ''
token size '0' 
INFO:osp:ospLoadRoutes: get destination '1': valid after
'2010-04-15T10:47:06Z' valid until '2010-04-15T10:57:06Z' time limit '14400'
seconds call id '001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5' calling
'testphone2' called '1202' host '[192.168.1.4]' nprn '' npcic '' npdi '0'
spid '' ocn '' spn '' altspn '' mcc '' mnc '' supported '1' network id ''
token size '0' 
INFO:osp:ospRequestRouting: there are '2' OSP routes, call_id
'001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5' 
Response received 
Try the 1st route 
Prepare route specific OSP information 
INFO:osp:ospPrepareDestination: prepare route to URI 'sip:1...@192.168.1.5'
for call_id '001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5' transaction_id
'5460314288097329217' 
ROUTE: Route OUT 
Try the next route 
Prepare route specific OSP information 
INFO:osp:ospPrepareDestination: prepare route to URI 'sip:1...@192.168.1.4'
for call_id '001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5' transaction_id
'5460314288097329217' 
Try the next route 
ROUTE: All destinations attempted for call ID
'001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5'. Call cannot be completed. 
INFO:osp:ospReportOrigSetupUsage: report orig setup for call_id
'001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5' transaction_id
'5460314288097329217' 
ROUTE: Route IN - M=ACK RURI=sip:1...@192.168.1.2
F=sip:testpho...@192.168.1.2 T=sip:1...@192.168.1.2 IP=192.168.1.5
id=001bd40b-d2130035-59ddb41e-b0c4f...@192.168.1.5 
ROUTE: Processing ACK 
ROUTE: Relay E2E ACK 
ROUTE: Route OUT

I cant seem to make sense of whats going on, can anyone see what the problem
is here?

Thanks

   
-- 
View this message in context: 
http://n2.nabble.com/Call-not-being-routed-correctly-with-OSP-module-tp4906928p4906928.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] [OpenSIPS-Devel] New features in BLF and presence

[Iñaki Baz Castillo]

2010/4/15 Anca Vamanu :
> Hi Inaki,
>
> The mixing is done as until now, no changes in this part. The presence
> info extracted from dialog is considered to have the greatest priority
> and is inserted the first. Here is an example:
>
> 
>  xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
> xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"
> xmlns:c="urn:ietf:params:xml:ns:pidf:cipid" entity="sip:a...@192.168.2.132">
>    
>        
>            open
>        
>    
>    On the phone
>     xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" id="pers_mixingid">
>        
>            
>        
>        On the phone
>    
>    
>        
>            open
>        
>    
>    
>        
>            
>        
>        Busy
>    
> 


Really nice. Thanks.



-- 
Iñaki Baz Castillo


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] New features in BLF and presence

[Anca Vamanu]

Iñaki Baz Castillo wrote:
> 2010/4/14 Anca Vamanu :
>   
>> Therefore, we decided to mix the dialog information with presence at the
>> presence server. Now, the presence server is able to tell you if a buddy
>> is in a call through presence Notifications even if his phone did not
>> send a presence Publish with this information. The mixing in fact
>> generates presence from dialog info when a call is in progress and mixes
>> this with the presence information received from his phone through
>> Publish. The result is that when a buddy is in a call you will see a
>> status indicating this and in the rest of the time you will see the
>> presence state that the buddy set in his client.
>> 
>
> Hi, this feature sounds really reasonable for the real world in which we live 
> :)
> Could I see how such NOTIFY (mixing presence and dialog information)
> looks? (just an example).
>
> Thanks.
>
>   
Hi Inaki,

The mixing is done as until now, no changes in this part. The presence 
info extracted from dialog is considered to have the greatest priority 
and is inserted the first. Here is an example:





open


On the phone




On the phone



open






Busy




Regards,

-- 
Anca Vamanu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Opensips Control Panel - Statistics Monitor - Statistics Charts

[Alex Ionescu]

Hi Erick,

I think I have a solution for you problem.
You need to give apache/httpd write permissions on the folder 
../opensips-cp/web/tools/system/smonitor/generated

This is because apache is trying to create a png file in that folder.
Let me know if you succeeded.

Regards,
Alex
On 4/14/2010 22:46, Erick Chinchilla Berrocal wrote:


agepng($this->img, $fileName);

/var/www/opensips-cp/web/tools/system/smonitor/lib/libchart/classes/view/plot# 
vim Plot.php


please let me know what is the procedure for fix the problem

Thanks




--
Alex Ionescu
www.voice-system.ro

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Transport follow up

[Bogdan-Andrei Iancu]

Hi Daniel,


Have you read RFC3263 about Locating SIP Servers  (with proto selection)  ?

http://www.ietf.org/rfc/rfc3263.txt

Regards,
Bogdan

Daniel Goepp wrote:
> I had a previous question regarding default transport, and the 
> response I got was that the RFC says the order should be UDP, TCP then 
> TLS.  However after reading into this further (and some recent 
> experiences with other platforms) I'm wondering if I have a new 
> feature request for OpenSIPS.  >From the RFC 3263 - Section 4.1 
> Selecting a Transport Protocol, I read it as saying:
>
> 1.  If specified in the RURI it SHOULD use this (but doesn't have to)
> 2.  Bunch of stuff on NAPTR (which we are not doing)
> 3.  The section related to what we are doing:
>
> -clip-
> If no NAPTR records are found, the client constructs SRV queries for
> those transport protocols it supports, and does a query for each.
> Queries are done using the service identifier "_sip" for SIP URIs and
> "_sips" for SIPS URIs. A particular transport is supported if the
> query is successful. The client MAY use any transport protocol it
> desires which is supported by the server.
>
> This is a change from RFC 2543. It specified that a client would
> lookup SRV records for all transports it supported, and merge the
> priority values across those records. Then, it would choose the
> most preferred record.
>
> If no SRV records are found, the client SHOULD use TCP for a SIPS
> URI, and UDP for a SIP URI. However, another transport protocol,
> such as TCP, MAY be used if the guidelines of SIP mandate it for this
> particular request. That is the case, for example, for requests that
> exceed the path MTU.
> -clip-
>
> The way I read this is that OpenSIPS MAY select whatever transport it 
> likes, and if no DNS SRV is found, then it would default to using UDP 
> first for SIP.  But in our set, DNS SRV does exist, and there are both 
> TCP and UDP records.  We would like to decide the default transport 
> order to use, starting with TLS then TCP then UDP.  I think I can try 
> to write something in the script to do this, but I'm not sure yet.  I 
> don't want to rewrite the RURI, I just want to specify the transport.  
> It would be great if there was a global variable defined in the config 
> that was something like "transport_order=TLS,TCP,UDP"
>
> Thoughts?
>
> -dg
> 
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] [OpenSIPS-Devel] New features in BLF and presence

[Anca Vamanu]

Schumann Sebastian wrote:
> Hi Anca
>
> Nice feature, one question:
>
>   
>> Publish. The result is that when a buddy is in a call you will see a
>> status indicating this and in the rest of the time you will see the
>> presence state that the buddy set in his client.
>> 
>
> Is this also done for buddies that did not publish any state before? How will 
> this be threaded by the module?
>
> Example: I am registered (but nothing published), performing a call and hang 
> up afterwards. I assume that it will trigger from offline to online but busy 
> to offline again.
>
> Is the module considering this or would this require the use of pua_usrloc to 
> have the correct behavior for clients that do not publish presence?
>
> Thanks!
>
> Sebastian
>   
Hi Sebastian,

The module does consider this case. The buddy will indeed appear offline 
until a call is preformed, then it will apear online with status 
'Calling' and then if answered 'On the phone' . After the call ends the 
user will appear again offline.


Regards,

-- 
Anca Vamanu
www.voice-system.ro


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] New features in BLF and presence

[Schumann Sebastian]

Hi Anca

Nice feature, one question:

> Publish. The result is that when a buddy is in a call you will see a
> status indicating this and in the rest of the time you will see the
> presence state that the buddy set in his client.

Is this also done for buddies that did not publish any state before? How will 
this be threaded by the module?

Example: I am registered (but nothing published), performing a call and hang up 
afterwards. I assume that it will trigger from offline to online but busy to 
offline again.

Is the module considering this or would this require the use of pua_usrloc to 
have the correct behavior for clients that do not publish presence?

Thanks!

Sebastian

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users