Hi... All ,
I am facing problem with SER presence status, when
authorization is enabled.
B elow is the scenario of my test.
1) PUA1 & PUA2 are two user agents subscribed to SER (2.0) presence
server.
2) PUA1 adds PUA2 into its buddly list . PUA2 gets Watcher-info
notification from PUA1 with subscription - state pending.
3) PUA2 accepts PUA1 and presence-rules.xml file is updated for PUA2
. In whitelist (Allow List)," <id PUA1(a)ser.org <mailto:PUA1@ser.org>
<id> " is added successfully.
problem statement :
PUA2 status is offline in PUA1 's buddy
list. I f PUA2 changes its status (sends PUBLISH with away/on
phone/busy activity ) , SER presence sends 200 OK success response ,
but no notifcation will be generated from server to watcher PUA1.
- also when PUA2 logs out and logs in again Wathcer-info subscription
will be generated with pending state though presence-rules.xml document
was already updated for this.
I have modified the ser.cfg for presence authorization below as per ser
presence Handbook .
modparam("pa", "auth", "xcap")
modparam("xcap", "xcap_root", "http://localhost/xcap-root
<http://localhost/xcap-root> ")
I have attached the
ser.cfg file. which i tried ... but doesn't work out.
let me know any of your comments.
regards,
Pravin .
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
Hi,
I am having problem with configuring FreeRadius to authenticate suername and
password. I have tried to test freeradius with a test client and it works
by sending the following message:
Ready to process requests.
User-Name = "1005(a)192.168.1.104"
User-Password = "1234"
Service-Type = Authenticate-Only
NAS-Port = 0
NAS-IP-Address = 127.0.0.1
The message that is sent by Openser is as follows:
Waking up in 1.9 seconds.
User-Name = "1005(a)192.168.1.104"
Digest-Attributes = 0x0a0631303036
Digest-Attributes = 0x010f3139322e3136382e312e313034
Digest-Attributes =
0x022a34383364376265396630623738663734363935343562386366373865303561316161623032633366
Digest-Attributes = 0x04137369703a3139322e3136382e312e313034
Digest-Attributes = 0x030a5245474953544552
Digest-Response = "eb5f24a5563e9c1096855ef8b2c72d2b"
Service-Type = IAPP-Register
X-Ascend-PW-Lifetime = 825241654
NAS-Port = 5060
NAS-IP-Address = 127.0.0.1
Freeradius can't find the password and is reject users as a result of that.
Also, is the Service-Type supposed to be Authenticate-Only instead?
Is this something to do with my openser.cfg setup that is causing the
problem?
Thanks in advance for your help.
Regards,
Pete
hi all
i read several docs of Openser, i didnt find the information to modify the A-number & B-number
does openser have the ability to modify A-number & B-number if yes, please send me the link to this
Thanks
Ha`
Dear All,
I use Openser for test SIP Text Message from IP phone to IP
phone. it's work perfect :) Look like only openser support this
feature light now.
Asterisk not support and Freeswitch fail also. (I use yealink ip
phone). So now my customer want to relay SIP text Message to PSTN via
SMSC
Can someone tell me is posible to use openser SMS module send
SIP text Message to SMSC ?
Best Regards.
Dome C.
Hello All!
After upgrading to 1.3.2 from 1.3.1 I'm encountered (similar to
described in that list already) issue, e.g. openser answers unreliably
slow to all messages (~40 seconds delay). DNS lookup related fix
doesn't helps.
I'll try to find what exactly caused this delay (if it's
openser-related issue and not something else).
--
With best regards!
Hi
I have two user clients behind separate NAT networks. My OpenSER is directly
connected to the Internet and has it's own external IP address.
Both clients are using STUN to get their external IP address and correct
port for SIP messages.
They successfully register with Openser, which is using Nathelper module and
Mediaproxy.
In this case, since the client is behind NAT, it puts the wrong port in the
Contact field of a SIP message.
As a result, SOME SIP messages from OpenSER are never received by the
client.
But with the help of Nathelper, OpenSER should correct the port in Contact
field, by replacing the NAT port with the src port of a SIP message (UDP
pack).
The problem is, that it looks like OpenSER only corrects the port in Contact
field for client A (The one who initiates the call) but not Client B(The one
who's called).
For a better explaination, please check out my logs from ngrep.
CLIENT A to OPENSER
U 2008/05/26 16:53:26.285586 157.157.78.173:54182 -> 212.50.206.33:5060
INVITE sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33> SIP/2.0.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
>;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>>.
Via: SIP/2.0/UDP 157.157.78.173:62356
;branch=z9hG4bKc0a8150a10007e0026261023.
Contact: 1006<sip:1006@157.157.78.173:62356>. !!!NB!!! <-- This is the WRONG
reply port.
OPENSER RELAYS TO CLIENT B
U 2008/05/26 16:53:26.301864 212.50.206.33:5060 -> 130.208.183.251:49211
INVITE sip:1001@130.208.183.251:49208 SIP/2.0.
Record-Route: <sip:212.50.206.33;lr;ftag=10007500-26260f5b;nat=yes>.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
>;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>>.
Via: SIP/2.0/UDP 212.50.206.33;branch=z9hG4bK5db1.ce9aea2.0;rport.
Via: SIP/2.0/UDP 157.157.78.173:62356
;rport=54182;branch=z9hG4bKc0a8150a10007e0026261023.
Contact: 1006<sip:1006@157.157.78.173:54182>. !!!NB!!! <-- OpenSER detects
it and changes it to correct reply port. Works great.
CLIENT B ANSWERS TO OPENSER
U 2008/05/26 16:53:27.301368 130.208.183.251:49211 -> 212.50.206.33:5060
SIP/2.0 200 OK.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
>;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>
>;tag=10007900-26261046.
Via: SIP/2.0/UDP 212.50.206.33;branch=z9hG4bK5db1.ce9aea2.0.
Via: SIP/2.0/UDP 157.157.78.173:62356
;branch=z9hG4bKc0a8150a10007e0026261023.
Contact: 1001<sip:1001@130.208.183.251:49208>. !!!NB!!! <-- Now lets try
Client B. Wrong reply port.
OPENSER TO CLIENT A
U 2008/05/26 16:53:27.305241 212.50.206.33:5060 -> 157.157.78.173:54182
SIP/2.0 200 OK.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
>;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>
>;tag=10007900-26261046.
Via: SIP/2.0/UDP 157.157.78.173:62356
;branch=z9hG4bKc0a8150a10007e0026261023.
Contact: 1001<sip:1001@130.208.183.251:49208>. !!!NB!!! <-- OpenSER didn't
change the port like before, so now Client B never receives ACK from Client
A.
CLIENT A TO OPENSER
U 2008/05/26 16:53:27.518621 157.157.78.173:54182 -> 212.50.206.33:5060
ACK sip:1001@130.208.183.251:49208 SIP/2.0.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
>;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>
>;tag=10007900-26261046.
Via: SIP/2.0/UDP 157.157.78.173:62356
;branch=z9hG4bKc0a8150a10007e0026261505.
Contact: 1006<sip:1006@157.157.78.173:62356>.
Route: <sip:212.50.206.33;lr;ftag=10007500-26260f5b;nat=yes>.
OPENSER TO CLIENT B
U 2008/05/26 16:53:27.519192 212.50.206.33:5060 -> 130.208.183.251:49208
!!!NB!!! <-- OpenSER sends to the WRONG port!
ACK sip:1001@130.208.183.251:49208 SIP/2.0.
Record-Route: <sip:212.50.206.33;lr;ftag=10007500-26260f5b;nat=yes>.
From: 1006<sip:1006@212.50.206.33 <sip%3A1006(a)212.50.206.33>
>;tag=10007500-26260f5b.
To: <sip:1001@212.50.206.33 <sip%3A1001(a)212.50.206.33>
>;tag=10007900-26261046.
CSeq: 101 ACK.
Via: SIP/2.0/UDP 212.50.206.33;branch=z9hG4bK5db1.ce9aea2.2;rport.
Via: SIP/2.0/UDP 157.157.78.173:62356
;rport=54182;branch=z9hG4bKc0a8150a10007e0026261505.
This last ACK message is never received by Client B because the client isn't
listening on port 49208.
If I manually use rewriteport("49211") it works, because obviously this last
package is then forced to port 49211 which the client listening on.
Also, the first line in my main route is force_rport(); but that still
doesn't do it.
I've been struggling with this problem for a few weeks now so all comments
and suggestions are very welcome.
My OpenSER config file can be found here: http://hoski.public.is/openser.cfg
Best regards,
Höskuldur
Hi all
i am intent to use Radius for prepaid but i need more information of RADIUS,
how to limit the call, how the RADIUS work together with Openser
could you suggest where i got it
Thanks
Ha
Hi, I use FRadius accounting. OpenSer tries to use a file /var/run/radius.seq
but it fails when restarting computer since OpenSer init script creates this
file as:
/var/run/openser/openser_radius.seq
create_radius_seqfile ()
{
# Create a radius sequence file to be used by the radius client if
# radius accounting is enabled. This is needed to avoid any issue
# with the file not being writable if openser first starts as user
# root because DUMP_CORE is enabled and creates this file as user
# root and then later it switches back to user openser and cannot
# write to the file. If the file exists before openser starts, it
# won't change it's ownership and will be writable for both root
# and openser, no matter what options are chosen at install time
RADIUS_SEQ_FILE=/var/run/openser/openser_radius.seq
I don't find where to change this file in OpenSer script. Isn't a bug if
default value is:
/var/run/radius.seq
but OpenSer init script (Debian Etch) creates it in:
/var/run/openser/openser_radius.seq
?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Hi,
In my scenario, I have UA1 -> Openser -> B2BUA -> Openser -> UA2.
The reason why I need B2BUA to originate the channel to UA2 is because it is
going to play a wav file when UA2 answers the call.
After the call has been answered by UA2 and dialog is in progress, is it
possible for B2BUA to notify Openser that it wants to be out of the look, so
the scenario can before:
UA1 -> Openser -> UA2 without UA2 hanging up?
How would I be able to config that?
Any help will be greatly appreciated.
Thanks,
Mark