Re: [OpenSIPS-Users] Registrant module invite auth
Hi Chris,
Please make sure that on your reply route x you call rtpproxy_answer()
method.
Regards,
Razvan Crainea
OpenSIPS Developer
On 17.06.2011 20:18, Chris Martineau wrote:
Hi,
On further investigation it would seem that the 183 and 200oks are not being updated by
rtpproxy with the new sdp parameters. I have added another t_on_reply(x) in
the failure route where the 407s are picked up to point at the 183/200 pickup but replies
seem to be bypassing this.
Any ideas on where to go with this would be greatly appreciated.
Regards
Chris
Hi,
Yes, changed to the realm and auth works ok.
However I now have a one way speech issue which may be due to rtpproxy having a
problem.
Do I need to do anything for rtpproxy when I send the auth'd invite? All the
original sdp changes are maintained but not sure if something is being lost as
I get no speech from the far end.
I assume drouting does a similar thing when trying different routes and that
works ok so not sure where the problem is.
Many thanks
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Ovidiu Sas
Sent: 17 June 2011 14:42
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Registrant module invite auth
The credential params must have the realm, not the domain. If the
realm is the same as your domain than you should be fine.
The script looks ok, make sure that you are going through it (add an
xlog before invoking uac_auth() and make sure that your credentials
are ok.
Regards,
Ovidiu Sas
On Fri, Jun 17, 2011 at 4:20 AM, Chris Martineauch...@ghosttelecom.com wrote:
Hi,
Thanks for that.
I have applied this as I think it should work and I get it resend the INVITE
but does not insert the auth header?
Here is a snapshot of the config file...
Modparam(uac,credential,username:domain:password)
failure_route[1]{
if (t_check_status(407)){
uac_auth();
t_relay();
exit();
}
Are there any other parameters I need to set? Is this process correct?
Many thanks
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Ovidiu Sas
Sent: 16 June 2011 17:45
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Registrant module invite auth
Use the uac module to authenticate INVITEs:
http://www.opensips.org/html/docs/modules/devel/uac.html#id292889
Because the CSeq will be the same, the end point may or may not like it.
Your mileage may vary.
Regards,
Ovidiu Sas
On Thu, Jun 16, 2011 at 12:37 PM, Chris Martineau
ch...@ghosttelecom.com wrote:
Hi,
Registrant module working however the destination is also requiring
authentication on invites is this possible?
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Chris Martineau
Sent: 16 June 2011 14:56
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Bye_on timeout_flag missing in 1.7
Ok thanks,
How stable is 1.7 as I will need to put this into a live high traffic
environment.
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Ovidiu Sas
Sent: 16 June 2011 14:25
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Bye_on timeout_flag missing in 1.7
Actually, there are some dependencies on new development on trunk and
therefor it will not work on the 1.6 branch.
Sorry for the false lead.
You will need to perform a full trunk install in order to get the
registrant functionality.
Regards,
Ovidiu Sas
On Thu, Jun 16, 2011 at 9:15 AM, Chris Martineauch...@ghosttelecom.com wrote:
Hi,
Tried this but the the make install stops with Error 2 when it tries to compile
this module. All permissions are fine on the files.
Anything I need to change for it to compile this correctly?
Many thanks
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Ovidiu Sas
Sent: 16 June 2011 13:06
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Bye_on timeout_flag missing in 1.7
Add the registrant directory to your 1.6 source code and
install/upgrade from there along with all the other modules in order
to maintain compatibility between modules and core.
Regards,
Ovidiu Sas
On Thu, Jun 16, 2011 at 7:51 AM, Chris Martineauch...@ghosttelecom.com wrote:
Hi Vlad,
Thanks for your help on this.
Just a quick question. I only need the registrant module from 1.7 can I
just compile this and copy the .so files over to my 1.6 installation?
Many thanks again
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Vlad Paiu
Sent: 16 June 2011 10:57
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] Bye_on
Re: [OpenSIPS-Users] Dialog Ping
Hello Brett, You are right, this was a bug, and I just commited a fix on trunk. Until now, the reply handler only considered internal OpenSIPS timeouts, and disregarded explicit 408 replies. Please update and let me know if it is ok. Regards, -- Vlad Paiu OpenSIPS Developer On 06/18/2011 01:20 AM, Brett Nemeroff wrote: Vlad, I just tested this today. Basically made a call with eyebeam, and once the call was up, I forcefully killed eyebeam. After that, I saw OPTIONS goto eyebeam and fail (retransmit). There was a dispatcher between the opensips box and eyebeam, so the dispatcher told opensips 408. At that point, opensips made no attempt at killing the dialog. In fact, it just kept on pinging it every X interval. I'm calling create_dialog(pPB) Am I doing something wrong? Thanks, Brett On Fri, Jun 17, 2011 at 3:11 AM, Vlad Paiu vladp...@opensips.org mailto:vladp...@opensips.org wrote: Hello Brett, Yes, the OPTIONs messages are dialog specific. They contain the proper to tag, from tag and callid, as well as the appropriate CSEQ header, etc. If one end-point isn't alive anymore, or if it responds with a messages telling that the end point is not aware of the dialog the message belongs to ( 481 Call/Transaction does not exist - like, for example, the UA quickly reboots, it is alive, but the dialog is not active from it's point of view ), the dialog will be killed from the middle. Regards, -- Vlad Paiu OpenSIPS Developer On 06/16/2011 11:50 PM, Brett Nemeroff wrote: Hello All, I had a question regarding the new dialog ping feature. Does this just check if the endpoints involved in a dialog are alive? Or is there anything dialog specific in the OPTIONs message? Thanks, Brett ___ Users mailing list Users@lists.opensips.org mailto:Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org mailto: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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Weird memory problems
Hello, This is really bad, seems like a memory corruption problem. It would be a great deal of help if you would follow the steps here [1] and reply when the problem reappears. Regards, -- Vlad Paiu OpenSIPS Developer [1] http://www.opensips.org/Resources/DocsTsMem On 06/17/2011 09:36 PM, Brett Nemeroff wrote: Hey All, Started getting some unusual memory issues. Running head from r7919. First thing I noticed was a few calls where the acc records written show a number of values way way off.. For example, one call shows duration as 1382576751 and setuptime show -1382576069. The timestamp is all 0's but the createdtime is a valid time. At the same time, I see this in the stats: shmem:total_size = 33554432 shmem:used_size = 22150480 shmem:real_used_size = 34565464 shmem:max_used_size = 35426568 shmem:free_size = 18446744073708540584 shmem:fragments = 3017 I see this on two servers. I've been running this version for a while and just all of a sudden noticed these issues. Any ideas? Thanks, Brett ___ 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] Registrant module invite auth
Hi,
This all works fine when not using the invite auth with everything
routing through the correct reply route for 183/200 responses (which
contain the correct rtpproxy_answer setups).
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Razvan Crainea
Sent: 20 June 2011 08:39
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] Registrant module invite auth
Hi Chris,
Please make sure that on your reply route x you call rtpproxy_answer()
method.
Regards,
Razvan Crainea
OpenSIPS Developer
On 17.06.2011 20:18, Chris Martineau wrote:
Hi,
On further investigation it would seem that the 183 and 200oks are not
being updated by rtpproxy with the new sdp parameters. I have added
another t_on_reply(x) in the failure route where the 407s are picked
up to point at the 183/200 pickup but replies seem to be bypassing this.
Any ideas on where to go with this would be greatly appreciated.
Regards
Chris
Hi,
Yes, changed to the realm and auth works ok.
However I now have a one way speech issue which may be due to rtpproxy
having a problem.
Do I need to do anything for rtpproxy when I send the auth'd invite?
All the original sdp changes are maintained but not sure if something is
being lost as I get no speech from the far end.
I assume drouting does a similar thing when trying different routes
and that works ok so not sure where the problem is.
Many thanks
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Ovidiu Sas
Sent: 17 June 2011 14:42
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Registrant module invite auth
The credential params must have the realm, not the domain. If the
realm is the same as your domain than you should be fine.
The script looks ok, make sure that you are going through it (add an
xlog before invoking uac_auth() and make sure that your credentials
are ok.
Regards,
Ovidiu Sas
On Fri, Jun 17, 2011 at 4:20 AM, Chris
Martineauch...@ghosttelecom.com wrote:
Hi,
Thanks for that.
I have applied this as I think it should work and I get it resend the
INVITE but does not insert the auth header?
Here is a snapshot of the config file...
Modparam(uac,credential,username:domain:password)
failure_route[1]{
if (t_check_status(407)){
uac_auth();
t_relay();
exit();
}
Are there any other parameters I need to set? Is this process
correct?
Many thanks
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Ovidiu Sas
Sent: 16 June 2011 17:45
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Registrant module invite auth
Use the uac module to authenticate INVITEs:
http://www.opensips.org/html/docs/modules/devel/uac.html#id292889
Because the CSeq will be the same, the end point may or may not like
it.
Your mileage may vary.
Regards,
Ovidiu Sas
On Thu, Jun 16, 2011 at 12:37 PM, Chris Martineau
ch...@ghosttelecom.com wrote:
Hi,
Registrant module working however the destination is also requiring
authentication on invites is this possible?
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Chris Martineau
Sent: 16 June 2011 14:56
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Bye_on timeout_flag missing in 1.7
Ok thanks,
How stable is 1.7 as I will need to put this into a live high
traffic environment.
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Ovidiu Sas
Sent: 16 June 2011 14:25
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Bye_on timeout_flag missing in 1.7
Actually, there are some dependencies on new development on trunk
and
therefor it will not work on the 1.6 branch.
Sorry for the false lead.
You will need to perform a full trunk install in order to get the
registrant functionality.
Regards,
Ovidiu Sas
On Thu, Jun 16, 2011 at 9:15 AM, Chris
Martineauch...@ghosttelecom.com wrote:
Hi,
Tried this but the the make install stops with Error 2 when it
tries to compile this module. All permissions are fine on the files.
Anything I need to change for it to compile this correctly?
Many thanks
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Ovidiu Sas
Sent: 16 June 2011 13:06
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Bye_on timeout_flag missing in 1.7
Add the registrant directory to your 1.6 source code and
install/upgrade from there along with all the other modules in
order
to maintain compatibility between modules and core.
Regards,
Re: [OpenSIPS-Users] Registrant module invite auth
Hi Chris,
You will only need to call rtpproxy_offer() for the authenticated INVITE
and register the onreply route that calls rtpproxy_answer() only for
these INVITEs.
Regards,
Razvan Crainea
OpenSIPS Developer
On 20.06.2011 12:04, Chris Martineau wrote:
Hi,
This all works fine when not using the invite auth with everything
routing through the correct reply route for 183/200 responses (which
contain the correct rtpproxy_answer setups).
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Razvan Crainea
Sent: 20 June 2011 08:39
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] Registrant module invite auth
Hi Chris,
Please make sure that on your reply route x you call rtpproxy_answer()
method.
Regards,
Razvan Crainea
OpenSIPS Developer
On 17.06.2011 20:18, Chris Martineau wrote:
Hi,
On further investigation it would seem that the 183 and 200oks are not
being updated by rtpproxy with the new sdp parameters. I have added
another t_on_reply(x) in the failure route where the 407s are picked
up to point at the 183/200 pickup but replies seem to be bypassing this.
Any ideas on where to go with this would be greatly appreciated.
Regards
Chris
Hi,
Yes, changed to the realm and auth works ok.
However I now have a one way speech issue which may be due to rtpproxy
having a problem.
Do I need to do anything for rtpproxy when I send the auth'd invite?
All the original sdp changes are maintained but not sure if something is
being lost as I get no speech from the far end.
I assume drouting does a similar thing when trying different routes
and that works ok so not sure where the problem is.
Many thanks
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Ovidiu Sas
Sent: 17 June 2011 14:42
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Registrant module invite auth
The credential params must have the realm, not the domain. If the
realm is the same as your domain than you should be fine.
The script looks ok, make sure that you are going through it (add an
xlog before invoking uac_auth() and make sure that your credentials
are ok.
Regards,
Ovidiu Sas
On Fri, Jun 17, 2011 at 4:20 AM, Chris
Martineauch...@ghosttelecom.com wrote:
Hi,
Thanks for that.
I have applied this as I think it should work and I get it resend the
INVITE but does not insert the auth header?
Here is a snapshot of the config file...
Modparam(uac,credential,username:domain:password)
failure_route[1]{
if (t_check_status(407)){
uac_auth();
t_relay();
exit();
}
Are there any other parameters I need to set? Is this process
correct?
Many thanks
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Ovidiu Sas
Sent: 16 June 2011 17:45
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Registrant module invite auth
Use the uac module to authenticate INVITEs:
http://www.opensips.org/html/docs/modules/devel/uac.html#id292889
Because the CSeq will be the same, the end point may or may not like
it.
Your mileage may vary.
Regards,
Ovidiu Sas
On Thu, Jun 16, 2011 at 12:37 PM, Chris Martineau
ch...@ghosttelecom.com wrote:
Hi,
Registrant module working however the destination is also requiring
authentication on invites is this possible?
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Chris Martineau
Sent: 16 June 2011 14:56
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Bye_on timeout_flag missing in 1.7
Ok thanks,
How stable is 1.7 as I will need to put this into a live high
traffic environment.
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Ovidiu Sas
Sent: 16 June 2011 14:25
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Bye_on timeout_flag missing in 1.7
Actually, there are some dependencies on new development on trunk
and
therefor it will not work on the 1.6 branch.
Sorry for the false lead.
You will need to perform a full trunk install in order to get the
registrant functionality.
Regards,
Ovidiu Sas
On Thu, Jun 16, 2011 at 9:15 AM, Chris
Martineauch...@ghosttelecom.com wrote:
Hi,
Tried this but the the make install stops with Error 2 when it
tries to compile this module. All permissions are fine on the files.
Anything I need to change for it to compile this correctly?
Many thanks
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Ovidiu Sas
Sent: 16 June 2011 13:06
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Bye_on
Re: [OpenSIPS-Users] Registrant module invite auth
Hi,
Figured it out, the order in the failure route was calling
unforce_rtpproxy before the 407 check.
Thanks for your help.
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Razvan Crainea
Sent: 20 June 2011 10:13
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] Registrant module invite auth
Hi Chris,
You will only need to call rtpproxy_offer() for the authenticated INVITE
and register the onreply route that calls rtpproxy_answer() only for
these INVITEs.
Regards,
Razvan Crainea
OpenSIPS Developer
On 20.06.2011 12:04, Chris Martineau wrote:
Hi,
This all works fine when not using the invite auth with everything
routing through the correct reply route for 183/200 responses (which
contain the correct rtpproxy_answer setups).
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Razvan Crainea
Sent: 20 June 2011 08:39
To: users@lists.opensips.org
Subject: Re: [OpenSIPS-Users] Registrant module invite auth
Hi Chris,
Please make sure that on your reply route x you call
rtpproxy_answer()
method.
Regards,
Razvan Crainea
OpenSIPS Developer
On 17.06.2011 20:18, Chris Martineau wrote:
Hi,
On further investigation it would seem that the 183 and 200oks are
not
being updated by rtpproxy with the new sdp parameters. I have added
another t_on_reply(x) in the failure route where the 407s are picked
up to point at the 183/200 pickup but replies seem to be bypassing
this.
Any ideas on where to go with this would be greatly appreciated.
Regards
Chris
Hi,
Yes, changed to the realm and auth works ok.
However I now have a one way speech issue which may be due to
rtpproxy
having a problem.
Do I need to do anything for rtpproxy when I send the auth'd invite?
All the original sdp changes are maintained but not sure if something
is
being lost as I get no speech from the far end.
I assume drouting does a similar thing when trying different routes
and that works ok so not sure where the problem is.
Many thanks
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Ovidiu Sas
Sent: 17 June 2011 14:42
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Registrant module invite auth
The credential params must have the realm, not the domain. If the
realm is the same as your domain than you should be fine.
The script looks ok, make sure that you are going through it (add an
xlog before invoking uac_auth() and make sure that your credentials
are ok.
Regards,
Ovidiu Sas
On Fri, Jun 17, 2011 at 4:20 AM, Chris
Martineauch...@ghosttelecom.com wrote:
Hi,
Thanks for that.
I have applied this as I think it should work and I get it resend
the
INVITE but does not insert the auth header?
Here is a snapshot of the config file...
Modparam(uac,credential,username:domain:password)
failure_route[1]{
if (t_check_status(407)){
uac_auth();
t_relay();
exit();
}
Are there any other parameters I need to set? Is this process
correct?
Many thanks
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Ovidiu Sas
Sent: 16 June 2011 17:45
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Registrant module invite auth
Use the uac module to authenticate INVITEs:
http://www.opensips.org/html/docs/modules/devel/uac.html#id292889
Because the CSeq will be the same, the end point may or may not like
it.
Your mileage may vary.
Regards,
Ovidiu Sas
On Thu, Jun 16, 2011 at 12:37 PM, Chris Martineau
ch...@ghosttelecom.com wrote:
Hi,
Registrant module working however the destination is also requiring
authentication on invites is this possible?
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Chris Martineau
Sent: 16 June 2011 14:56
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Bye_on timeout_flag missing in 1.7
Ok thanks,
How stable is 1.7 as I will need to put this into a live high
traffic environment.
Regards
Chris
-Original Message-
From: users-boun...@lists.opensips.org
[mailto:users-boun...@lists.opensips.org] On Behalf Of Ovidiu Sas
Sent: 16 June 2011 14:25
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Bye_on timeout_flag missing in 1.7
Actually, there are some dependencies on new development on trunk
and
therefor it will not work on the 1.6 branch.
Sorry for the false lead.
You will need to perform a full trunk install in order to get the
registrant functionality.
Regards,
Ovidiu Sas
On Thu, Jun 16, 2011 at 9:15 AM, Chris
[OpenSIPS-Users] 30x redirect for register
Hi all, It is viable solution to use 30(1|2|5) redirect for REGISTER sip messages ? Thanks, Dani ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presentity basicclosed/basic always Closed
Hi Duane, Sure looks like a Bria problem.. If it sends publishes with status closed, the presence server doesn't have what else to do but to believe that is the real state that it wants to publish. Maybe something in Bria's configuration leads to this... Regards, Anca Vamanu On Mon, Jun 20, 2011 at 5:10 AM, duane.lar...@gmail.com wrote: I have OpenSIPS set up with Presence and am using Counterpath's Bria Client. In the past I was able to get Bria/OpenSIPS/OpenXCAP to all work. Now I am trying to get it to work again and I'm having problems. When two users agree to view each others presence it doesn't work. I see that each user is recieving NOTIFY messages about the other users presence but the Bria client doesn't update the users status. I see that every time a Bria client starts up it is Publishing its presence but it always has basicclosed/basic in the xml U 2011/06/19 21:00:12.240159 108.67.136.231:31194 - 173.203.93.107:5060 PUBLISH sip:9013349...@irock.com SIP/2.0. Via: SIP/2.0/UDP 108.67.136.231:31194;branch=z9hG4bK-d8754z-96515b7ec527b151-1---d8754z-;rport. Max-Forwards: 70. Contact: sip:9013349018@108.67.136.231:31194;transport=udp. To: 9013349018sip:9013349...@irock.com. From: 9013349018sip:9013349...@irock.com;tag=71799813. Call-ID: NTJkNzgyYmMwMDQ1ZWUwMzExMzkyM2Y1OTgxNDgwN2U.. CSeq: 1 PUBLISH. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/pidf+xml. User-Agent: Bria 3 release 3.2.1 stamp 62387. Event: presence. Content-Length: 469. . ?xml version='1.0' encoding='UTF-8'?presence xmlns='urn:ietf:params:xml:ns:pidf' 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' xmlns:lt='urn:ietf:params:xml:ns:location-type' xmlns:caps='urn:ietf:params:xml:ns:pidf:caps' entity='sip:9013349018@ irock.com'tuple id='td9cbb9c2'statusbasicclosed/basic/status/tupledm:person id='p0f48c387'/dm:person/presence # U 2011/06/19 21:00:12.244401 173.203.93.107:5060 - 108.67.136.231:31194 SIP/2.0 200 OK. Via: SIP/2.0/UDP 108.67.136.231:31194;branch=z9hG4bK-d8754z-72b75f4a63995f60-1---d8754z-;rport=31194. To: sip:9013349...@irock.com;tag=31ec65e482de21ae66d7d44df69d3d8c-c4ef. From: 9013349018sip:9013349...@irock.com;tag=b5e76db3. Call-ID: ZGI1OTA4NmEyYjAzZjFiY2VhNDY4OWY1Njk5MWIwZDA.. CSeq: 1 SUBSCRIBE. Expires: 3600. Contact: sip:sa@173.203.93.107:5060. Server: Aethercommunications SIP Proxy. Content-Length: 0. Then in the Presentity table I have the following mysql select * from presentity; +--++---+--+--++---+-+++ | id | username | domain | event | etag | expires | received_time | body | extra_hdrs | sender | +--++---+--+--++---+-+++ | 2914 | 9013349018 | irock.com | presence | a.1308527728.29011.36.15 | 1308537940 | 1308534340 | ?xml version='1.0' encoding='UTF-8'?presence xmlns='urn:ietf:params:xml:ns:pidf' 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' xmlns:lt='urn:ietf:params:xml:ns:location-type' xmlns:caps='urn:ietf:params:xml:ns:pidf:caps' entity='sip:9013349018@ irock.com'tuple id='t1f9e4914'statusbasicclosed/basic/status/tupledm:person id='pf69e3d57'/dm:person/presence | | | | 2916 | 9013349018 | irock.com | presence | a.1308527728.29010.37.2 | 1308538423 | 1308534823 | ?xml version='1.0' encoding='UTF-8'?presence xmlns='urn:ietf:params:xml:ns:pidf' 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' xmlns:lt='urn:ietf:params:xml:ns:location-type' xmlns:caps='urn:ietf:params:xml:ns:pidf:caps' entity='sip:9013349018@
Re: [OpenSIPS-Users] Presentity basicclosed/basic always Closed
Anca, Doing some more testing it looks like the Bria client is sending PUBLISH messages and they are open. Only when they bria client is shut down is the record in the presentity table set to closed. Then when the Bria client is turned on again a new PUBLISH is sent and entered into the presentity table with open, but the NOTIFY that is sent to any watchers has the closed in the notify. So it appears that because there are multiple entries in the Presentity table for a single user it is confusing things. Here is an example I have user 9013349018 that just closed down Bria. Then the user starts Bria back up and you have the following in the table http://pastebin.com/1aZdXsbR So the new Presentity record for user 9013349018 is record id 2921. And as the bria client came up you see the following Notify message get sent to user 9013349019 and it has the closed in the notify message. Here are the Notify messages http://pastebin.com/QJvYiD1B So you see that the Bria client came up and sent OpenSIPS a PUBLISH message and it doesn't have closed in the XML. Yet when OpenSIPS relays a NOTIFY to a watcher you see that the closed gets placed in the xml. So now I am thinking that Bria isn't the issue. On Mon, Jun 20, 2011 at 11:46 AM, Anca Vamanu anca.vam...@gmail.com wrote: Hi Duane, Sure looks like a Bria problem.. If it sends publishes with status closed, the presence server doesn't have what else to do but to believe that is the real state that it wants to publish. Maybe something in Bria's configuration leads to this... Regards, Anca Vamanu On Mon, Jun 20, 2011 at 5:10 AM, duane.lar...@gmail.com wrote: I have OpenSIPS set up with Presence and am using Counterpath's Bria Client. In the past I was able to get Bria/OpenSIPS/OpenXCAP to all work. Now I am trying to get it to work again and I'm having problems. When two users agree to view each others presence it doesn't work. I see that each user is recieving NOTIFY messages about the other users presence but the Bria client doesn't update the users status. I see that every time a Bria client starts up it is Publishing its presence but it always has basicclosed/basic in the xml U 2011/06/19 21:00:12.240159 108.67.136.231:31194 - 173.203.93.107:5060 PUBLISH sip:9013349...@irock.com SIP/2.0. Via: SIP/2.0/UDP 108.67.136.231:31194;branch=z9hG4bK-d8754z-96515b7ec527b151-1---d8754z-;rport. Max-Forwards: 70. Contact: sip:9013349018@108.67.136.231:31194;transport=udp. To: 9013349018sip:9013349...@irock.com. From: 9013349018sip:9013349...@irock.com;tag=71799813. Call-ID: NTJkNzgyYmMwMDQ1ZWUwMzExMzkyM2Y1OTgxNDgwN2U.. CSeq: 1 PUBLISH. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/pidf+xml. User-Agent: Bria 3 release 3.2.1 stamp 62387. Event: presence. Content-Length: 469. . ?xml version='1.0' encoding='UTF-8'?presence xmlns='urn:ietf:params:xml:ns:pidf' 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' xmlns:lt='urn:ietf:params:xml:ns:location-type' xmlns:caps='urn:ietf:params:xml:ns:pidf:caps' entity='sip:9013349018@ irock.com'tuple id='td9cbb9c2'statusbasicclosed/basic/status/tupledm:person id='p0f48c387'/dm:person/presence # U 2011/06/19 21:00:12.244401 173.203.93.107:5060 - 108.67.136.231:31194 SIP/2.0 200 OK. Via: SIP/2.0/UDP 108.67.136.231:31194;branch=z9hG4bK-d8754z-72b75f4a63995f60-1---d8754z-;rport=31194. To: sip:9013349...@irock.com;tag=31ec65e482de21ae66d7d44df69d3d8c-c4ef. From: 9013349018sip:9013349...@irock.com;tag=b5e76db3. Call-ID: ZGI1OTA4NmEyYjAzZjFiY2VhNDY4OWY1Njk5MWIwZDA.. CSeq: 1 SUBSCRIBE. Expires: 3600. Contact: sip:sa@173.203.93.107:5060. Server: Aethercommunications SIP Proxy. Content-Length: 0. Then in the Presentity table I have the following mysql select * from presentity; +--++---+--+--++---+-+++ | id | username | domain | event | etag | expires | received_time | body | extra_hdrs | sender |
Re: [OpenSIPS-Users] Presentity basicclosed/basic always Closed
Anca, Please ignore. This is a Bria issue it appears. It is true that initially when you first log in with a Bria client it sends a Publish message and has statusbasicclosed/basic/status in the message. I was doing an NGREP and after that message is received if you wait a little while (about 11 seconds from the NGREP I did) a second Publish Message is sent from the Bria client and it has the SIP-If-Match withe correct etag and it sets the presence to statusbasicopen/basic/status Does that seem normal for Counterpath/Bria to send two Publish messages? Everything works after the second message is sent. I was just wondering if you are supposed to do that? The issue is this (which I found out a while back) http://opensips-open-sip-server.1449251.n2.nabble.com/Presentity-record-not-deleted-in-database-td5858207.html I thought I opened a ticket with Counterpath but it obviously isn't fixed. I can't believe I wasted a whole day on an issue I found a while back. On Jun 20, 2011 12:28pm, Duane Larson duane.lar...@gmail.com wrote: Anca, Doing some more testing it looks like the Bria client is sending PUBLISH messages and they are open. Only when they bria client is shut down is the record in the presentity table set to closed. Then when the Bria client is turned on again a new PUBLISH is sent and entered into the presentity table with open, but the NOTIFY that is sent to any watchers has the closed in the notify. So it appears that because there are multiple entries in the Presentity table for a single user it is confusing things. Here is an example I have user 9013349018 that just closed down Bria. Then the user starts Bria back up and you have the following in the table http://pastebin.com/1aZdXsbR So the new Presentity record for user 9013349018 is record id 2921. And as the bria client came up you see the following Notify message get sent to user 9013349019 and it has the closed in the notify message. Here are the Notify messages http://pastebin.com/QJvYiD1B So you see that the Bria client came up and sent OpenSIPS a PUBLISH message and it doesn't have closed in the XML. Yet when OpenSIPS relays a NOTIFY to a watcher you see that the closed gets placed in the xml. So now I am thinking that Bria isn't the issue. On Mon, Jun 20, 2011 at 11:46 AM, Anca Vamanu anca.vam...@gmail.com wrote: Hi Duane, Sure looks like a Bria problem.. If it sends publishes with status closed, the presence server doesn't have what else to do but to believe that is the real state that it wants to publish. Maybe something in Bria's configuration leads to this... Regards, Anca Vamanu On Mon, Jun 20, 2011 at 5:10 AM, duane.lar...@gmail.com wrote: I have OpenSIPS set up with Presence and am using Counterpath's Bria Client. In the past I was able to get Bria/OpenSIPS/OpenXCAP to all work. Now I am trying to get it to work again and I'm having problems. When two users agree to view each others presence it doesn't work. I see that each user is recieving NOTIFY messages about the other users presence but the Bria client doesn't update the users status. I see that every time a Bria client starts up it is Publishing its presence but it always has closed in the xml U 2011/06/19 21:00:12.240159 108.67.136.231:31194 - 173.203.93.107:5060 PUBLISH sip:9013349...@irock.com SIP/2.0. Via: SIP/2.0/UDP 108.67.136.231:31194;branch=z9hG4bK-d8754z-96515b7ec527b151-1---d8754z-;rport. Max-Forwards: 70. Contact: 9013349018@108.67.136.231:31194;transport=udp. To: 90133490189013349...@irock.com. From: 90133490189013349...@irock.com;tag=71799813. Call-ID: NTJkNzgyYmMwMDQ1ZWUwMzExMzkyM2Y1OTgxNDgwN2U.. CSeq: 1 PUBLISH. Expires: 3600. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/pidf+xml. User-Agent: Bria 3 release 3.2.1 stamp 62387. Event: presence. Content-Length: 469. . pidf' 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' xmlns:lt='urn:ietf:params:xml:ns:location-type' xmlns:caps='urn:ietf:params:xml:ns:pidf:caps' entity='sip:9013349...@irock.com'closedtuplepresence # U 2011/06/19 21:00:12.244401 173.203.93.107:5060 - 108.67.136.231:31194 SIP/2.0 200 OK. Via: SIP/2.0/UDP 108.67.136.231:31194;branch=z9hG4bK-d8754z-72b75f4a63995f60-1---d8754z-;rport=31194. To: 9013349...@irock.com;tag=31ec65e482de21ae66d7d44df69d3d8c-c4ef. From: 90133490189013349...@irock.com;tag=b5e76db3. Call-ID: ZGI1OTA4NmEyYjAzZjFiY2VhNDY4OWY1Njk5MWIwZDA.. CSeq: 1 SUBSCRIBE. Expires: 3600. Contact: sip:sa@173.203.93.107:5060. Server: Aethercommunications SIP Proxy. Content-Length: 0. Then in the Presentity table I have the following mysql select * from presentity;
