Re: [OpenSIPS-Users] Integrating OpenSIPs against Asterisk
Hi Sergio, I think I also want OpenSIPS to handle UA registrations as well, so I can remove that burden from the Asterisk boxes. Then OpenSIPS would rewrite the URI to send it to Asterisk. (Though maybe this isn't possible or makes things infinitely more complicated?) In addition, almost 100% of my current UAs are behind NAT (my asterisk box is not behind NAT), so all the SIP extensions in asterisk have nat=yes set. I assume if I want OpenSIPS to handle registrations, then it also needs to handle NAT as well before forwarding it to Asterisk. I know that having OpenSIPS handle UA registrations makes things a bit more complicated, but I think its important for scalability to remove that burden from Asterisk. I'm guessing that I would need to turn qualify off on each SIP extension in Asterisk as well, so Asterisk still tries to complete the call because it doesn't monitor it as well, though I suppose the OPTIONS messages sent out by Asterisk could be rewritten by OpenSIPs to qualify would still work as well? Thanks. -- James On Sat, Mar 7, 2009 at 10:30 AM, Sergio Gutierrez sag...@gmail.com wrote: Hi James. Your case sounds like you would use your OpenSIPS just as a proxy. Asterisk would be your UAS. If that is your situation, you could start from the example config file which is installed with source code; From that file you can take validations for SIP signaling; you would rewrite uri of SIP requests to route to your asterisk, or in case you have several asterisks, you could try loadbalancing if you need. Also, you could choose whether your OpenSIPS would operate as stateless or stateful proxy according to your particular needs. Finally, if you decide to perform accounting at proxy, some actions should be included in your config file (The comments in the example file would help). Feel free to ask any other thing you need. Best regards. Sergio. On Sat, Mar 7, 2009 at 1:18 PM, James Lamanna jlama...@gmail.com wrote: Hi, Does anyone have some good examples of an OpenSIPs configuration that integrates with Asterisk? Essentially I want to use OpenSIPs as the UA, but still run all the calls through Asterisk (for dialplan, etc..) I've tried searching for some good examples, but I haven't found any for Asterisk yet. Thanks. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Sergio Gutiérrez ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Integration with Asterisk/Trixbox
Hi, I want to use OpenSIPs as the registrar (and NAT handler) for an Asterisk/Trixbox installation. I've got things partially working, but I've totally made a mess of my config (I can post it if you would like). Some things that I need: I'm having problems with SIP-SIP calls because I need asterisk to stay in the media stream, so really the call has to be routed like: phone1 -- opensips -- asterisk -- opensips -- phone2. Does anyone have any configs that come close to this that I could stare at? The ones I've found on the web are useful in some ways, but not in others. Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Integration with Asterisk/Trixbox
On Wed, May 20, 2009 at 7:46 AM, Iñaki Baz Castillo i...@aliax.net wrote:
2009/5/20 James Lamanna jlama...@gmail.com:
Hi,
I want to use OpenSIPs as the registrar (and NAT handler) for an
Asterisk/Trixbox installation.
I've got things partially working, but I've totally made a mess of my
config (I can post it if you would like).
Some things that I need:
I'm having problems with SIP-SIP calls because I need asterisk to
stay in the media stream, so really the call has to be routed like:
phone1 -- opensips -- asterisk -- opensips -- phone2.
Does anyone have any configs that come close to this that I could stare at?
Set canreinvite=no for opensips peer in sip.conf.
The ones I've found on the web are useful in some ways, but not in others.
This question is more related to Asterisk.
Not really.
I'm using the basic NAT example with a little rewriting (as shown below).
The problem I have is that the SDP address is not being rewritten, so
on the asterisk box I see audio traces like this:
(x.x.x.x is the phone NAT IP address, y.y.y.y is the asterisk box address).
You'll notice that the first 2 lines are correct, but the second 2 are
not (asterisk sends to the private IP of the phone)
13:04:54.228511 IP (tos 0x0, ttl 118, id 8879, offset 0, flags [none],
proto: UDP (17), length: 200) x.x.x.x.47127 y.y.y.y.12232: UDP,
length 172
13:04:54.228555 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 200) y.y.y.y.10536 x.x.x.x.47128: UDP,
length 172
13:04:54.243209 IP (tos 0x0, ttl 54, id 22237, offset 0, flags
[none], proto: UDP (17), length: 200) x.x.x.x.47128 y.y.y.y.10536:
UDP, length 172
13:04:54.243254 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 200) y.y.y.y.12232 10.20.200.219.49154:
UDP, length 172
When asterisk sends an INVITE to connect the called phone, the SDP
isn't getting rewritten for some reason.
How do I make that work?
The setup signaling looks like:
Calling phone sends INVITE -- opensips forwards to asterisk --
asterisk sends INVITE --- opensips forwards INVITE to called phone...
-- James
debug=3 # debug level (cmd line: -dd)
fork=yes
log_stderror=no # (cmd line: -E)
# Uncomment these lines to enter debugging mode
fork=no
log_stderror=yes
#debug=4
check_via=no# (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=4
listen=udp:z.z.z.z:5060
# -- module loading --
#set module path
#mpath=/usr/local/lib/opensips/modules/
mpath=/usr/local/lib64/opensips/modules/
# Uncomment this if you want to use SQL database
#loadmodule db_mysql.so
loadmodule sl.so
loadmodule tm.so
loadmodule signaling.so
loadmodule rr.so
loadmodule maxfwd.so
loadmodule usrloc.so
loadmodule registrar.so
loadmodule textops.so
loadmodule mi_fifo.so
loadmodule xlog.so
# Uncomment this if you want digest authentication
# db_mysql.so must be loaded !
#loadmodule auth.so
#loadmodule auth_db.so
# !! Nathelper
loadmodule nathelper.so
# - setting module-specific parameters ---
# -- mi_fifo params --
modparam(mi_fifo, fifo_name, /tmp/opensips_fifo)
# -- usrloc params --
modparam(usrloc, db_mode, 0)
# Uncomment this if you want to use SQL database
# for persistent storage and comment the previous line
#modparam(usrloc, db_mode, 2)
# -- auth params --
# Uncomment if you are using auth module
#modparam(auth_db, calculate_ha1, yes)
#
# If you set calculate_ha1 parameter to yes (which true in this config),
# uncomment also the following parameter)
#modparam(auth_db, password_column, password)
# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam(rr, enable_full_lr, 1)
# !! Nathelper
modparam(usrloc,nat_bflag,6)
modparam(nathelper,sipping_bflag,8)
modparam(nathelper, ping_nated_only, 1) # Ping only clients behind NAT
modparam(nathelper, rtpproxy_sock, unix:/var/run/rtpproxy/rtpproxy.sock)
# - request routing logic ---
# main routing logic
route{
^[
xlog(L_INFO, New request - Request/failure/branch routes: M=$rm
RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n);
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header(10)) {
sl_send_reply(483,Too Many Hops);
exit;
};
if (msg:len = 2048 ) {
sl_send_reply(513, Message too big);
exit;
};
if (is_method(OPTIONS)) {
sl_send_reply(200, OK);
exit;
}
# !! Nathelper
# Special handling for NATed clients; first, NAT test is
# executed: it looks for via!=received and RFC1918 addresses
# in Contact (may fail if line-folding is used); also,
# the received test should, if completed, should check all
# vias for rpesence of received
if (nat_uac_test(3)) {
# Allow RR-ed requests, as these may indicate that
# a NAT-enabled proxy takes care of it; unless
[OpenSIPS-Users] Select rewrite destination based on authname
Hi, I've been looking for a way within OpenSIPS (without needing to write my own module), where I can select a rewrite host/port based on the authentication name (or from uri username) of a request. I've looked at dispatcher and drouting, but dispatcher calculates a hash over the username, and drouting appears to only be able to use the RURI. Is there some other mechanism or am I missing something. Ideally I would want a lookup table like: Username Dialplan Server 1234567890server1.mycompany.com:5060 9876543210server2.mycompany.com:5060 . Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Select rewrite destination based on authname
Nevermind. I figured out how to do this with avpops :) On Sun, May 24, 2009 at 7:45 PM, James Lamanna jlama...@gmail.com wrote: Hi, I've been looking for a way within OpenSIPS (without needing to write my own module), where I can select a rewrite host/port based on the authentication name (or from uri username) of a request. I've looked at dispatcher and drouting, but dispatcher calculates a hash over the username, and drouting appears to only be able to use the RURI. Is there some other mechanism or am I missing something. Ideally I would want a lookup table like: Username Dialplan Server 1234567890 server1.mycompany.com:5060 9876543210 server2.mycompany.com:5060 . Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Linksys SPA-942 BLF and OpenSIPS presence
Hi, Has anyone been able to get the BLF to work with a SPA-942 and the OpenSIPS presence module? There must be something different from the BLF responses from an Asterisk server and from OpenSIPS, because the BLF works great when the phone is monitoring the Asterisk server directly. I can see the SUBSCRIBE and the NOTIFY messages coming through, so maybe the phone just doesn't understand the NOTIFYs? Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Linksys SPA-942 BLF and OpenSIPS presence
On Wed, May 27, 2009 at 1:52 AM, Iñaki Baz Castillo i...@aliax.net wrote: 2009/5/27 James Lamanna jlama...@gmail.com: Hi, Has anyone been able to get the BLF to work with a SPA-942 and the OpenSIPS presence module? There are many types of presence: - Presence SIMPLE (user status: online, offline, away, on-meeting...) = Event: presence - Presence BLF (RFC 4235): line status (calling, on-call, idle...) = Event: dialog Asterisk supports **very poorly and wrongly** the BLF presence (but it does it VERY VERY wrongly, in a propietary way instead of following the RFC 4235. Linksys phones allos this painful Asterisk BLF presence. OpenSIPS presence module is generic, it allows any kind of presence, but somebody must send the PUBLISH with the user or line status. Users implementing SIMPLE presence (X-Lite, Eyebeam, Twinkle, Ekiga...) send PUBLISH (Event: presence) by themself, they arrive to the presence server (Opensips presence module) and it generates NOTIFY for subscribers. In case of BLF, something should send PUBLISH Event: dialog when a call occurs (in progress, established...). A phone couuld do it, but it's not very usual. However OpenSIPS has a module called pua_dialoginfo which generates PUBLISH Event: dialog when an INVITE occurs. I've tested it and didn't seem robust for me. Read the documentation about it. There must be something different from the BLF responses from an Asterisk server and from OpenSIPS, because the BLF works great when the phone is monitoring the Asterisk server directly. I can see the SUBSCRIBE and the NOTIFY messages coming through, so maybe the phone just doesn't understand the NOTIFYs? Presence is more complex that what you suggest. There are different kinds of presence packages. Thanks for the clarification! I'll play around with this more today to see what I can get working. The other thing that complicates this is that I would like to have the presence BLF from the Asterisk parking lot to work. Currently I can get this to work by forwarding the SUBSCRIBE packets for the parking lot extensions to Asterisk, however if I have to change the server type on the phone to something other than Asterisk, to get the presence BLF for extensions registered with OpenSIPS to work, this will most definitely break. Though in that case I could probably do some transformations to the NOTIFY reply from Asterisk to make it conform to RFC 4235? Regards. -- Iñaki Baz Castillo i...@aliax.net Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS Presence module causes SPA-942 to infinitely reboot
As an update, removing the call to handle_subscribe() stops the infinite rebooting as well. On Fri, Jun 5, 2009 at 6:01 PM, James Lamannajlama...@gmail.com wrote: Hi, I have a Linksys 942 (Phone A) where one of the line keys is setup to do BLF (Ext B). If I make a call from Phone A to Ext B, the BLF works the first time. However if I hangup and then make try to make that same call again, the phone reboots. Once this happens, the phone will reboot infinitely until opensips is stopped. Any ideas on this one? I really need to get BLF to work with these phones. Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS Presence module causes SPA-942 to infinitely reboot
On Fri, Jun 5, 2009 at 6:05 PM, James Lamannajlama...@gmail.com wrote: As an update, removing the call to handle_subscribe() stops the infinite rebooting as well. Leaving in handle_subscribe and removing presence_dialoginfo also stops the infinite reboot, however removing presence_dialoginfo causes the BLF to not work anymore. On Fri, Jun 5, 2009 at 6:01 PM, James Lamannajlama...@gmail.com wrote: Hi, I have a Linksys 942 (Phone A) where one of the line keys is setup to do BLF (Ext B). If I make a call from Phone A to Ext B, the BLF works the first time. However if I hangup and then make try to make that same call again, the phone reboots. Once this happens, the phone will reboot infinitely until opensips is stopped. Any ideas on this one? I really need to get BLF to work with these phones. Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Presence and hangup
Hi, So, I've got presence mostly working now, however I have the interesting problem that when someone hangs up, the BLF on my Linksys SPA-942 still remains red. Do I need to do some special BYE handling to make this clear? Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence and hangup
On Sat, Jun 6, 2009 at 12:21 PM, Iñaki Baz Castilloi...@aliax.net wrote: El Sábado, 6 de Junio de 2009, James Lamanna escribió: Hi, So, I've got presence mostly working now, however I have the interesting problem that when someone hangs up, the BLF on my Linksys SPA-942 still remains red. Do I need to do some special BYE handling to make this clear? Presence (SUBSCRIBE/PUBLISH Event: presence) has *nothing* to do with BLF (Dialog subscriptions - RFC 4235), *nothing*. Ok, thanks for the clarification. Then there seems to be a problem in the presence_dialoginfo module at 1.5.1, which according to the documentation implements RFC 4235, where the the phone is not getting a notification that the dialog has been destroyed. I'm currently building the SVN trunk to see if that fixes the problem. -- Iñaki Baz Castillo i...@aliax.net -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence and Hangup
El S?bado, 6 de Junio de 2009, James Lamanna escribi?: On Sat, Jun 6, 2009 at 12:21 PM, I?aki Baz Castilloi...@aliax.net wrote: El S?bado, 6 de Junio de 2009, James Lamanna escribi?: Hi, So, I've got presence mostly working now, however I have the interesting problem that when someone hangs up, the BLF on my Linksys SPA-942 still remains red. Do I need to do some special BYE handling to make this clear? Presence (SUBSCRIBE/PUBLISH Event: presence) has *nothing* to do with BLF (Dialog subscriptions - RFC 4235), *nothing*. Ok, thanks for the clarification. Then there seems to be a problem in the presence_dialoginfo module at 1.5.1, which according to the documentation implements RFC 4235, where the the phone is not getting a notification that the dialog has been destroyed. Are you also using pua_dialoginfo module? Yes I am using pua_dialoginfo. BLF does not work on the Linksys phones without it. However, these issues do seem to be fixed in trunk, though I would really like to run a stable version, and not bleeding edge. :) Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] BLF lights on Linksys 942/962 get stuck in off-hook state
I am using 1.5.2
--James
On Jul 28, 2009, at 1:48, Anca Vamanu a...@opensips.org wrote:
Hi James,
What OpenSIPS version are you using?
Anca
James Lamanna wrote:
Hi,
I have some SPA942 and 962 phones that I'm trying to get BLF to work
properly with.
I've found it works correctly most of the time, however on occasion,
the BLF lights will get stuck as RED
(someone on a call) even though that person has hung up.
Relevant parts of config:
modparam(presence, server_address, sip:s...@xxx.xxx.xxx.xxx:5060)
modparam(presence, expires_offset, 10)
modparam(presence_xml, force_active, 1)
modparam(presence_dialoginfo, force_single_dialog, 1)
modparam(pua_dialoginfo, presence_server,
sip:s...@xxx.xxx.xxx.xxx:5060)
modparam(pua_dialoginfo, include_callid, 1)
modparam(pua_dialoginfo, include_tags, 1)
modparam(pua_dialoginfo, caller_confirmed, 1)
modparam(pua_usrloc, default_domain, xxx.xxx.xxx.xxx)
modparam(pua_usrloc, presence_server, sip:s...@xxx.xxx.xxx.xxx:
5060)
...
if(is_method(PUBLISH)) {
if ($hdr(Sender) != NULL)
handle_publish($hdr(Sender));
else
handle_publish();
}
else if( is_method(SUBSCRIBE)) {
handle_subscribe();
}
Thanks.
-- James
___
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] BLF lights on Linksys 942/962 get stuck in off-hook state
Hi Anca,
I tried the latest trunk of Opensips and presence seems to be
completely broken for my Linksys phones.
The lights now flash orange, which I believe means that they are not subscribed.
I will say I have to have the ServerType on the phone set to
Asterisk because I have parking
lines that still need the BLF directly from the Asterisk server.
And as an aside, does anyone know if Asterisk 1.6 implements RFC4235 correctly?
Thanks.
-- James
On Tue, Jul 28, 2009 at 10:53 AM, James Lamannajlama...@gmail.com wrote:
I am using 1.5.2
--James
On Jul 28, 2009, at 1:48, Anca Vamanu a...@opensips.org wrote:
Hi James,
What OpenSIPS version are you using?
Anca
James Lamanna wrote:
Hi,
I have some SPA942 and 962 phones that I'm trying to get BLF to work
properly with.
I've found it works correctly most of the time, however on occasion,
the BLF lights will get stuck as RED
(someone on a call) even though that person has hung up.
Relevant parts of config:
modparam(presence, server_address, sip:s...@xxx.xxx.xxx.xxx:5060)
modparam(presence, expires_offset, 10)
modparam(presence_xml, force_active, 1)
modparam(presence_dialoginfo, force_single_dialog, 1)
modparam(pua_dialoginfo, presence_server,
sip:s...@xxx.xxx.xxx.xxx:5060)
modparam(pua_dialoginfo, include_callid, 1)
modparam(pua_dialoginfo, include_tags, 1)
modparam(pua_dialoginfo, caller_confirmed, 1)
modparam(pua_usrloc, default_domain, xxx.xxx.xxx.xxx)
modparam(pua_usrloc, presence_server, sip:s...@xxx.xxx.xxx.xxx:5060)
...
if(is_method(PUBLISH)) {
if ($hdr(Sender) != NULL)
handle_publish($hdr(Sender));
else
handle_publish();
}
else if( is_method(SUBSCRIBE)) {
handle_subscribe();
}
Thanks.
-- James
___
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] BLF lights on Linksys 942/962 get stuck in off-hook state
are you using?
Anca
James Lamanna wrote:
Hi,
I have some SPA942 and 962 phones that I'm trying to get BLF to work
properly with.
I've found it works correctly most of the time, however on occasion,
the BLF lights will get stuck as RED
(someone on a call) even though that person has hung up.
Relevant parts of config:
modparam(presence, server_address, sip:s...@xxx.xxx.xxx.xxx:5060)
modparam(presence, expires_offset, 10)
modparam(presence_xml, force_active, 1)
modparam(presence_dialoginfo, force_single_dialog, 1)
modparam(pua_dialoginfo, presence_server,
sip:s...@xxx.xxx.xxx.xxx:5060)
modparam(pua_dialoginfo, include_callid, 1)
modparam(pua_dialoginfo, include_tags, 1)
modparam(pua_dialoginfo, caller_confirmed, 1)
modparam(pua_usrloc, default_domain, xxx.xxx.xxx.xxx)
modparam(pua_usrloc, presence_server, sip:s...@xxx.xxx.xxx.xxx:5060)
...
if(is_method(PUBLISH)) {
if ($hdr(Sender) != NULL)
handle_publish($hdr(Sender));
else
handle_publish();
}
else if( is_method(SUBSCRIBE)) {
handle_subscribe();
}
Thanks.
-- James
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
broken_blfs.log
Description: Binary data
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] BLF lights on Linksys 942/962 get stuck in off-hook state
On Thu, Aug 6, 2009 at 7:27 AM, Anca Vamanua...@opensips.org wrote: Hi James, I have made a fixed in pua that should fix this problem. It is both in 1.5.x baranch and trunk. Please update and test now. Thanks! I will start testing this and let you know what I find right away. -- James regards, Anca James Lamanna wrote: Hi, I've managed to get a SIP trace of what happens when the light gets stuck on. Apparently opensips sends the terminated state correctly, but then for some reason immediately follows it up with a confirmed. Any help would be greatly appreciated because this issue is preventing me from moving to Opensips as a UA. Here is the end of the call from x to yy (I've also attached it as a text file): open.sips.ip:5060 - phone.nat.ip:1024 NOTIFY sip:xxx...@phone.nat.ip:1024 SIP/2.0..Via: SIP/2.0/UDP open.sips.ip;branch=z9hG4bK47c6.54ba3b12.0..To: sip:xxx...@open.sips.ip;tag=2bc2391ca644f0b4..From: sip:yyy...@208 .90.184.6;tag=89c56fdf6f5b6f30be24c8867d74b34a-50ee..CSeq: 135 NOTIFY..Call-ID: d3c20f3c-6cca1...@192.168.1.103..content-length: 577..User-Agent: OpenSIPS (1.5.2-notls (x86_64/linux))..Max-For wards: 70..Event: dialog..Contact: sip:s...@open.sips.ip:5060..Subscription-State: active;expires=201..Content-Type: application/dialog-info+xml?xml version=1.0?.dialog-info xmlns=urn :ietf:params:xml:ns:dialog-info version=119 state=full entity=yyy...@open.sips.ip. dialog id=6dc6f1db-3e4e1...@192.168.1.103 call-id=6dc6f1db-3e4e1...@192.168.1.103 di rection=recipient. stateconfirmed/state. remote. identitysip:xxx...@open.sips.ip/identity. target uri=sip:xxx...@open.sips.ip/. /remote. local . identitysip:yyy...@open.sips.ip/identity. target uri=sip:yyy...@open.sips.ip/. /local. /dialog./dialog-info. # U phone.nat.ip:1024 - open.sips.ip:5060 SIP/2.0 200 OK..To: sip:xxx...@open.sips.ip;tag=2bc2391ca644f0b4..From: sip:yyy...@open.sips.ip;tag=89c56fdf6f5b6f30be24c8867d74b34a-50ee..Call-ID: d3c20f3c-6cca1...@192.168.1.103.. CSeq: 133 NOTIFY..Via: SIP/2.0/UDP open.sips.ip;branch=z9hG4bK67c6.d79cd0b1.0..Server: Linksys/SPA962-6.1.5(a)..Content-Length: 0 # U phone.nat.ip:1024 - open.sips.ip:5060 SIP/2.0 200 OK..To: sip:xxx...@open.sips.ip;tag=2bc2391ca644f0b4..From: sip:yyy...@open.sips.ip;tag=89c56fdf6f5b6f30be24c8867d74b34a-50ee..Call-ID: d3c20f3c-6cca1...@192.168.1.103.. CSeq: 134 NOTIFY..Via: SIP/2.0/UDP open.sips.ip;branch=z9hG4bK37c6.cebb6d83.0..Server: Linksys/SPA962-6.1.5(a)..Content-Length: 0 # U phone.nat.ip:1024 - open.sips.ip:5060 ACK sip:yyy...@208.90.184.3:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.1.103:5060;branch=z9hG4bK-91d3e74f..From: sip:xxx...@open.sips.ip;tag=d73256a35148bf4do0..To: sip:yyy...@open.sips.ip;tag=as07ecc712..Call-ID: 6dc6f1db-3e4e1...@192.168.1.103..cseq: 102 ACK..Max-Forwards: 70..Route: sip:open.sips.ip;lr=on;ftag=d73256a35148bf4do0;did=75e.7a38 ec43..Proxy-Authorization: Digest username=xx,realm=asterisk,nonce=0309612d,uri=sip:yyy...@open.sips.ip,algorithm=MD5,response=1ff12fede7922f355cfabb7ec82203c6..Contact: sip:xxx...@192.168.1.103:5060..User-Agent: Linksys/SPA962-6.1.5(a)..Content-Length: 0 # U open.sips.ip:5060 - phone.nat.ip:1024 NOTIFY sip:xxx...@phone.nat.ip:1024 SIP/2.0..Via: SIP/2.0/UDP open.sips.ip;branch=z9hG4bK17c6.c007f975.0..To: sip:xxx...@open.sips.ip;tag=2bc2391ca644f0b4..From: sip:yyy...@208 .90.184.6;tag=89c56fdf6f5b6f30be24c8867d74b34a-50ee..CSeq: 136 NOTIFY..Call-ID: d3c20f3c-6cca1...@192.168.1.103..content-length: 577..User-Agent: OpenSIPS (1.5.2-notls (x86_64/linux))..Max-For wards: 70..Event: dialog..Contact: sip:s...@open.sips.ip:5060..Subscription-State: active;expires=201..Content-Type: application/dialog-info+xml?xml version=1.0?.dialog-info xmlns=urn :ietf:params:xml:ns:dialog-info version=120 state=full entity=yyy...@open.sips.ip. dialog id=6dc6f1db-3e4e1...@192.168.1.103 call-id=6dc6f1db-3e4e1...@192.168.1.103 di rection=recipient. stateconfirmed/state. remote. identitysip:xxx...@open.sips.ip/identity. target uri=sip:xxx...@open.sips.ip/. /remote. local . identitysip:yyy...@open.sips.ip/identity. target uri=sip:yyy...@open.sips.ip/. /local. /dialog./dialog-info. # U phone.nat.ip:1024 - open.sips.ip:5060 SIP/2.0 200 OK..To: sip:xxx...@open.sips.ip;tag=2bc2391ca644f0b4..From: sip:yyy...@open.sips.ip;tag=89c56fdf6f5b6f30be24c8867d74b34a-50ee..Call-ID: d3c20f3c-6cca1...@192.168.1.103.. CSeq: 135 NOTIFY..Via: SIP/2.0/UDP open.sips.ip;branch=z9hG4bK47c6.54ba3b12.0..Server: Linksys/SPA962-6.1.5(a)..Content-Length: 0 # U phone.nat.ip:1024 - open.sips.ip:5060 SIP/2.0 200 OK..To: sip:xxx...@open.sips.ip;tag=2bc2391ca644f0b4..From: sip:yyy...@open.sips.ip;tag
[OpenSIPS-Users] PROBLEM: Opensips stops replying to SIP packets
Hi, I'm running the svn 1.5 branch of opensips. I've noticed after some amount of time, usually a day or so, opensips just completely stops responding to incoming SIP requests, REGISTER, NOTIFY, etc... The only way to recover from this is to restart opensips. In fact it seems to stop doing anything, including writing debug output. Thank you. -- JAmes ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] OpenSIPS 1.5 SVN branch is NOT STABLE
Hi, Again, the OpenSIPS 1.5 branch I have built has stopped responding to any and all SIP requests. In fact, it has even stopped recording anything in the log. This has happened after maybe 2-3 days of very light use. Only 8 phones are using this OpenSIPS as a UA. Unfortunately the BLF fixes that I need are in this 1.5 branch, but now the whole system is unusable. Also, since the logfile stops being written to when this happens I can't offer any debug logging This is a x64 system running opensips as root with -m 512 Please help. Thank you. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] PROBLEM: Opensips stops replying to SIP packets
On Aug 12, 2009, at 10:36, Bogdan-Andrei Iancu bog...@voice- system.ro wrote: Hi James, when opensips comes to a stop, does it consume all the CPU ? I don't believe so but I will try and double check. I'm away from things for a few days but next week I'll have a definite answer. Regards, Bogdan -- James James Lamanna wrote: Hi, I'm running the svn 1.5 branch of opensips. I've noticed after some amount of time, usually a day or so, opensips just completely stops responding to incoming SIP requests, REGISTER, NOTIFY, etc... The only way to recover from this is to restart opensips. In fact it seems to stop doing anything, including writing debug output. Thank you. -- JAmes ___ 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] Presence and Linksys phones - not working 1.6.1
Hi, I'm trying to get presence (BLF) working with some Linksys 942 phones. I've noticed that I get the error, handle_subscribe: Missing or unsupported event header field value I did a trace and the phone is trying to subscribe to the x-spa-cti event. Is there a way to support/fix this? Is there something that supports that event? Thank you. This is opensips 1.6.1. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence and Linksys phones - not working 1.6.1
Sorry, I realized I had a configuration error on my phone, but the presence still does not work. The phone now subscribes to the event: dialog. Here are relevant parts of my opensips config: modparam(presence, server_address, sip:s...@xxx.xxx.xxx.xxx:5060) modparam(presence, expires_offset, 10) modparam(presence_xml, force_active, 1) modparam(presence_dialoginfo, force_single_dialog, 1) I have also verified that handle_subscribe() is being called when a SUBSCRIBE message comes in. Calling the phone doesn't seem to produce any PUBLISH messages or anything pertaining to presence. Thanks. -- James On Tue, Mar 30, 2010 at 7:56 PM, James Lamanna jlama...@gmail.com wrote: Hi, I'm trying to get presence (BLF) working with some Linksys 942 phones. I've noticed that I get the error, handle_subscribe: Missing or unsupported event header field value I did a trace and the phone is trying to subscribe to the x-spa-cti event. Is there a way to support/fix this? Is there something that supports that event? Thank you. This is opensips 1.6.1. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence and Linksys phones - not working 1.6.1
On Wed, Mar 31, 2010 at 10:28 AM, Anca Vamanu a...@opensips.org wrote:
James Lamanna wrote:
Anca Vamanu Wrote:
Andrew, this patch is already in 1.6.2 and trunk.
James, the first thing that you need to check is that you receive
Subscribes from the phones with event 'dialog'. And indeed as Andrew
said, you need to load pua and pua_dialoginfo modules.
Ok thanks. I'll upgrade to 1.6.2.
Do I still need to explicitly call dialoginfo_set()?
Yes, you have to call it.
Hi Anca,
I'm still having problems getting this to work at all.
I've now upgraded to 1.6.2.
Here is my entire config:
debug=3 # debug level (cmd line: -dd)
fork=yes
log_stderror=no # (cmd line: -E)
log_facility=LOG_LOCAL0
tos=0x60
# Uncomment these lines to enter debugging mode
#fork=no
log_stderror=yes
debug=6
check_via=no# (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=4
listen=udp:my.ip.address:5060
listen=udp:my.ip.address:5061
# -- module loading --
#set module path
#mpath=/usr/local/lib/opensips/modules/
mpath=/usr/local/lib64/opensips/modules/
# Uncomment this if you want to use SQL database
loadmodule db_mysql.so
loadmodule sl.so
loadmodule maxfwd.so
loadmodule textops.so
loadmodule avpops.so
loadmodule tm.so
loadmodule rr.so
loadmodule dialog.so
loadmodule signaling.so
loadmodule options.so
loadmodule localcache.so
loadmodule usrloc.so
loadmodule presence.so
loadmodule presence_xml.so
loadmodule presence_dialoginfo.so
loadmodule pua.so
loadmodule pua_dialoginfo.so
#loadmodule pua_bla.so
loadmodule pua_usrloc.so
loadmodule registrar.so
loadmodule mi_fifo.so
loadmodule xlog.so
# Uncomment this if you want digest authentication
# db_mysql.so must be loaded !
loadmodule auth.so
loadmodule auth_db.so
# !! Nathelper
loadmodule nathelper.so
# - setting module-specific parameters ---
# -- mi_fifo params --
modparam(mi_fifo, fifo_name, /tmp/opensips_fifo)
modparam(usrloc, db_mode, 2)
modparam(usrloc|dialog|dispatcher|presence|presence_xml|pua|avpops,
db_url, mysql://opensips:myp...@localhost/opensips)
modparam(avpops,avp_table,usr_preferences)
#modparam(dispatcher, force_dst, 1)
# Only use username
#modparam(dispatcher, flags, 1)
# Store passwords for 1 hour in cache
modparam(auth,username_spec,$avp(i:54))
modparam(auth,password_spec,$avp(i:55))
modparam(auth,calculate_ha1,1)
modparam(auth_db, db_url,
mysql://opensipsro:mypas...@localhost/opensips)
modparam(auth_db, calculate_ha1, yes)
modparam(auth_db, password_column, password)
modparam(auth_db, load_credentials, $avp(i:55)=password)
modparam(rr, enable_full_lr, 1)
modparam(dialog, dlg_flag, 4)
modparam(dialog, profiles_with_value, caller)
modparam(usrloc,nat_bflag,6)
modparam(nathelper,sipping_bflag,8)
#modparam(nathelper, natping_interval, 30)
modparam(nathelper, ping_nated_only, 1) # Ping only clients behind NAT
#modparam(nathelper, natping_interval, 30)
modparam(nathelper, sipping_from, sip:pin...@my.ip.address)
modparam(nathelper, rtpproxy_sock, unix:/var/run/rtpproxy/rtpproxy.sock)
modparam(presence, server_address, sip:s...@my.ip.address:5060)
modparam(presence, expires_offset, 10)
modparam(presence_xml, force_active, 1)
modparam(presence_dialoginfo, force_single_dialog, 1)
modparam(pua_dialoginfo, presence_server, sip:s...@my.ip.address:5060)
modparam(pua_dialoginfo, include_callid, 1)
modparam(pua_dialoginfo, include_tags, 1)
modparam(pua_dialoginfo, caller_confirmed, 1)
modparam(pua_usrloc, default_domain, my.ip.address)
modparam(pua_usrloc, presence_server, sip:s...@my.ip.address:5060)
# - request routing logic ---
# main routing logic
route{
if (!is_method(NOTIFY))
xlog(L_INFO, New request - Request/failure/branch routes:
M=$rm
RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n);
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header(10)) {
sl_send_reply(483,Too Many Hops);
exit;
};
if (msg:len = 2048 ) {
sl_send_reply(513, Message too big);
exit;
};
# !! Nathelper
# Special handling for NATed clients; first, NAT test is
# executed: it looks for via!=received and RFC1918 addresses
# in Contact (may fail if line-folding is used); also,
# the received test should, if completed, should check all
# vias for rpesence of received
if (nat_uac_test(3)) {
# Allow RR-ed requests, as these may indicate that
# a NAT-enabled proxy takes care of it; unless it is
# a REGISTER
if (is_method(REGISTER) || !is_present_hf(Record-Route)) {
#xlog(L_INFO, LOG:Someone trying to register from
private IP,
rewriting\n);
#xlog(L_INFO, $rb\n
Re: [OpenSIPS-Users] Presence and Linksys phones - not working 1.6.1
On Wed, Mar 31, 2010 at 9:16 PM, James Lamanna jlama...@gmail.com wrote: On Wed, Mar 31, 2010 at 10:28 AM, Anca Vamanu a...@opensips.org wrote: James Lamanna wrote: Anca Vamanu Wrote: Andrew, this patch is already in 1.6.2 and trunk. James, the first thing that you need to check is that you receive Subscribes from the phones with event 'dialog'. And indeed as Andrew said, you need to load pua and pua_dialoginfo modules. Ok thanks. I'll upgrade to 1.6.2. Do I still need to explicitly call dialoginfo_set()? Yes, you have to call it. Hi Anca, I'm still having problems getting this to work at all. I've now upgraded to 1.6.2. Here is my entire config: [snip] Ok I think I got this somewhat working. I was missing a dialoginfo_set() in another INVITE path. However, does anyone know how, if you add a new phone, to make the presence initialize to idle? The BLF light blinks amber until I call the phone that is being monitored, then it will blink red, and go back to green when the call is terminated. Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence and Linksys phones - not working 1.6.1
On Wed, Mar 31, 2010 at 9:28 PM, James Lamanna jlama...@gmail.com wrote: On Wed, Mar 31, 2010 at 9:16 PM, James Lamanna jlama...@gmail.com wrote: On Wed, Mar 31, 2010 at 10:28 AM, Anca Vamanu a...@opensips.org wrote: James Lamanna wrote: Anca Vamanu Wrote: Andrew, this patch is already in 1.6.2 and trunk. James, the first thing that you need to check is that you receive Subscribes from the phones with event 'dialog'. And indeed as Andrew said, you need to load pua and pua_dialoginfo modules. Ok thanks. I'll upgrade to 1.6.2. Do I still need to explicitly call dialoginfo_set()? Yes, you have to call it. Hi Anca, I'm still having problems getting this to work at all. I've now upgraded to 1.6.2. Here is my entire config: [snip] Ok I think I got this somewhat working. I was missing a dialoginfo_set() in another INVITE path. However, does anyone know how, if you add a new phone, to make the presence initialize to idle? The BLF light blinks amber until I call the phone that is being monitored, then it will blink red, and go back to green when the call is terminated. Also, I've found a case where the BLF light stays red, even when a call is hung up. This seems to happen in the intercom case, where the SIP URI is sip:u...@ip;intercom=true. It doesn't happen on every intercom call, but once it does happen, it is impossible to clear without clearing the presence tables and rebooting the phone.. -- James Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence and Linksys phones - not working 1.6.1
On Thu, Apr 1, 2010 at 12:26 AM, Anca Vamanu a...@opensips.org wrote: [snip] Ok I think I got this somewhat working. I was missing a dialoginfo_set() in another INVITE path. However, does anyone know how, if you add a new phone, to make the presence initialize to idle? The BLF light blinks amber until I call the phone that is being monitored, then it will blink red, and go back to green when the call is terminated. Hi James, Can you please run a network trace and catch the Notify that goes first to the phone and makes it blink amber as you said? Send that to me to see how we can fix that. Hi Anca, Attached is a log of a startup of 2 phones. Each phone is monitoring the other phone. This is a clean startup, so all presence tables are empty. I think this may be a lack of any NOTIFYs being sent at startup to the phone that a phone is online. Thanks. -- James opensips_init.log Description: Binary data ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence and Linksys phones - not working 1.6.1
Also, I've found a case where the BLF light stays red, even when a call is hung up. This seems to happen in the intercom case, where the SIP URI is sip:u...@ip;intercom=true. It doesn't happen on every intercom call, but once it does happen, it is impossible to clear without clearing the presence tables and rebooting the phone.. -- James Can you please catch the traces for this case also? All the presence traffic that you see when you hang up the phone - the Publish generated by OpenSIPS and the Notify sent to the phone. Thanks, Hi Anca, Here's the full trace. I call one phone (01) from my cell phone, and 02 is monitoring it. When 01 hangs up, the light on 02 stays red. Thanks for all your help! -- James opensips_red.log Description: Binary data ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence and Linksys phones - not working 1.6.1
On Fri, Apr 2, 2010 at 4:52 AM, Anca Vamanu a...@opensips.org wrote: Hi James, I think that the problem is with those Notifies without a body sent by OpenSIPS when the phone was started. This is normal behavior, correct and conform RFC - when the presence server does not have any record for that presentity - it includes no body. But since you say that Linksys does not like this and since it was not that difficult to change, I just committed a patch that sends a Notify with an empty dialoginfo tuple as body when no published record is found. Please upgrade from svn and test this case again. Hi Anca, I saw your patch and upgraded to the SVN 1.6 branch. However, I do not believe I ever hit that code path. In my debug logs I see No record exists in hash table (notify.c:853). I'm not sure if fallback2db is true, but I don't think it is, so I never make it to that codepath. Apr 2 16:42:24 [12585] DBG:presence:send_notify_request: dialog info: Apr 2 16:42:24 [12585] DBG:presence:printf_subs: [pres_uri]= sip:000...@opensips.ip [to_user]= 02 [to_domain]= opensips.ip [w_user]= 01[w_domain]= opensips.ip [event]= dialog [status]= active [expires]= 60 [callid]= 9673ec38-b54b9...@192.168.1.165 [local_cseq]=0 [to_tag]= 89c56fdf6f5b6f30be24c8867d74b34a-8b2f [from_tag]= f9ba884d0d82aab [contact]= sip:000...@phone.nat.ip:6095 [record_route]= Apr 2 16:42:24 [12585] DBG:presence:search_phtable: pres_uri= sip:000...@opensips.ip Apr 2 16:42:24 [12585] DBG:presence:get_p_notify_body: No record exists in hash_table Apr 2 16:42:24 [12585] DBG:presence_dialoginfo:dlginfo_agg_nbody: [pres_user]=02 [pres_domain]= opensips.ip, [n]=0 Apr 2 16:42:24 [12585] DBG:presence_dialoginfo:build_dialoginfo: [pres_uri] sip:000...@opensips.ip Apr 2 16:42:24 [12585] DBG:presence:search_phtable: pres_uri= sip:000...@opensips.ip Apr 2 16:42:24 [12585] DBG:presence_dialoginfo:build_dialoginfo: No record exists in hash_table Apr 2 16:42:24 [12585] DBG:presence:send_notify_request: Could not get the notify_body Apr 2 16:42:24 [12585] DBG:presence:send_notify_request: headers: Max-Forwards: 70^M Event: dialog^M Contact: sip:s...@opensips.ip:5060^M Subscription-State: active;expires=50^M Apr 2 16:42:24 [12585] DBG:presence:build_dlg_t: CONTACT = sip:000...@phone.nat.ip:6095 Apr 2 16:42:24 [12585] DBG:tm:t_uac: next_hop=sip:000...@phone.nat.ip::6095 Apr 2 16:42:24 [12585] DBG:core:mk_proxy: doing DNS lookup... Apr 2 16:42:24 [12585] DBG:tm:dlg2hash: 63929 Apr 2 16:42:24 [12585] DBG:tm:print_request_uri: sip:000...@phone.nat.ip::6095 Apr 2 16:42:24 [12585] DBG:tm:set_timer: relative timeout is 50 Apr 2 16:42:24 [12585] DBG:tm:insert_timer_unsafe: [4]: 0x7f0f225b44d0 (580) Apr 2 16:42:24 [12585] DBG:tm:set_timer: relative timeout is 30 Apr 2 16:42:24 [12585] DBG:tm:insert_timer_unsafe: [0]: 0x7f0f225b4500 (35) Apr 2 16:42:24 [12585] INFO:presence:send_notify_request: NOTIFY sip:000...@opensips.ip via sip:000...@phone.nat.ip::6095 on Regards, -- Anca Vamanu www.voice-system.ro -- James James Lamanna wrote: On Thu, Apr 1, 2010 at 12:26 AM, Anca Vamanu a...@opensips.org wrote: [snip] Ok I think I got this somewhat working. I was missing a dialoginfo_set() in another INVITE path. However, does anyone know how, if you add a new phone, to make the presence initialize to idle? The BLF light blinks amber until I call the phone that is being monitored, then it will blink red, and go back to green when the call is terminated. Hi James, Can you please run a network trace and catch the Notify that goes first to the phone and makes it blink amber as you said? Send that to me to see how we can fix that. Hi Anca, Attached is a log of a startup of 2 phones. Each phone is monitoring the other phone. This is a clean startup, so all presence tables are empty. I think this may be a lack of any NOTIFYs being sent at startup to the phone that a phone is online. Thanks. -- James ___ 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence and Linksys phones - not working 1.6.1
On Fri, Apr 2, 2010 at 4:40 PM, James Lamanna jlama...@gmail.com wrote: On Fri, Apr 2, 2010 at 4:52 AM, Anca Vamanu a...@opensips.org wrote: Hi James, I think that the problem is with those Notifies without a body sent by OpenSIPS when the phone was started. This is normal behavior, correct and conform RFC - when the presence server does not have any record for that presentity - it includes no body. But since you say that Linksys does not like this and since it was not that difficult to change, I just committed a patch that sends a Notify with an empty dialoginfo tuple as body when no published record is found. Please upgrade from svn and test this case again. Hi Anca, I saw your patch and upgraded to the SVN 1.6 branch. However, I do not believe I ever hit that code path. In my debug logs I see No record exists in hash table (notify.c:853). I'm not sure if fallback2db is true, but I don't think it is, so I never make it to that codepath. [snip] Setting fallback2db == 1 as a modparam doesn't hit it either because it aggregates the body. Also, that has another side effect of crashing opensips after about 1 minute as well. Last entry in the log in that case is termination due to SIGCHLD. Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] When do I need MediaProxy?
Hi, I'm trying to use OpenSips as a registration server for Asterisk (assuming we can get presence working ok). Do I need to setup and use MediaProxy (or similar)? Or is the nathelper stuff good enough? I've made test calls from phones behind NAT to opensips to asterisk and I haven't experienced any one-way audio problems. Also, the phones are not allowed to reinvite, because I need to keep Asterisk in the media path. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] When do I need MediaProxy?
On Sat, Apr 3, 2010 at 3:05 PM, Brian Chamberlain br...@asterisk.ie wrote: Why are you splitting the registrations from Asterisk? I've had issues with Asterisk causing large groups of phones to go unreachable for a minute or so. This is with approximately 500-600 devices registered at one time on one box. Asterisk does not seem to be designed to be able to handle registrations for that many devices, especially when it is also under load from handling 50+ simultaneous calls. -- James On 3 Apr 2010, at 20:31, James Lamanna wrote: Hi, I'm trying to use OpenSips as a registration server for Asterisk (assuming we can get presence working ok). Do I need to setup and use MediaProxy (or similar)? Or is the nathelper stuff good enough? I've made test calls from phones behind NAT to opensips to asterisk and I haven't experienced any one-way audio problems. Also, the phones are not allowed to reinvite, because I need to keep Asterisk in the media path. -- James ___ 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Presence and Linksys phones - not working 1.6.1
On Mon, Apr 5, 2010 at 12:52 AM, Angel Marin an...@anmar.eu.org wrote: On 03/04/10 01:40, James Lamanna wrote: On Fri, Apr 2, 2010 at 4:52 AM, Anca Vamanu a...@opensips.org wrote: Hi James, I think that the problem is with those Notifies without a body sent by OpenSIPS when the phone was started. This is normal behavior, correct and conform RFC - when the presence server does not have any record for that presentity - it includes no body. But since you say that Linksys does not like this and since it was not that difficult to change, I just committed a patch that sends a Notify with an empty dialoginfo tuple as body when no published record is found. Please upgrade from svn and test this case again. Hi Anca, I saw your patch and upgraded to the SVN 1.6 branch. However, I do not believe I ever hit that code path. In my debug logs I see No record exists in hash table (notify.c:853). I'm not sure if fallback2db is true, but I don't think it is, so I never make it to that codepath. Give the attached patch a shot, it should do what you're looking for. Though I'm not sure generating an empty dialog without a presence entry is the correct approach, I mean, the monitored extension is not there, so why not hint it as a blinking light? In a cold start scenario, it'll go green once your re-subscribe time comes, so set it to a couple minutes or lower in the phone and you'll be good to go. Actually, it never changes from blinking to green in that scenario, even after multiple subscribes and registers. Also, I just noticed that I'm receiving a peculiar response, a 501 Not Implemented from the phones in response to a PUBLISH (I swear it wasn't doing this before!)... -- James -- Angel Marin http://anmar.eu.org/ ___ 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] Presence and Linksys phones - not working 1.6.1
On Apr 6, 2010, at 3:24, Anca Vamanu a...@opensips.org wrote: James Lamanna wrote: On Mon, Apr 5, 2010 at 12:52 AM, Angel Marin an...@anmar.eu.org wrote: On 03/04/10 01:40, James Lamanna wrote: On Fri, Apr 2, 2010 at 4:52 AM, Anca Vamanu a...@opensips.org wrote: Hi James, I think that the problem is with those Notifies without a body sent by OpenSIPS when the phone was started. This is normal behavior, correct and conform RFC - when the presence server does not have any record for that presentity - it includes no body. But since you say that Linksys does not like this and since it was not that difficult to change, I just committed a patch that sends a Notify with an empty dialoginfo tuple as body when no published record is found. Please upgrade from svn and test this case again. Hi Anca, I saw your patch and upgraded to the SVN 1.6 branch. However, I do not believe I ever hit that code path. In my debug logs I see No record exists in hash table (notify.c: 853). I'm not sure if fallback2db is true, but I don't think it is, so I never make it to that codepath. Give the attached patch a shot, it should do what you're looking for. Though I'm not sure generating an empty dialog without a presence entry is the correct approach, I mean, the monitored extension is not there, so why not hint it as a blinking light? In a cold start scenario, it'll go green once your re-subscribe time comes, so set it to a couple minutes or lower in the phone and you'll be good to go. Actually, it never changes from blinking to green in that scenario, even after multiple subscribes and registers. Also, I just noticed that I'm receiving a peculiar response, a 501 Not Implemented from the phones in response to a PUBLISH (I swear it wasn't doing this before!)... -- James Hi James, The phones should never receive the Publish message. Please catch a trace containing this Publish and send it to me. What do you mean by before? Before updating from svn with my patch? Before I updated from 1.6.2 to SVN I think - I'll try and double-check. I have a revised patch that covers my case that I'll submit this afternoon with the trace. Any luck with the stuck BLF trace I submitted as well? I also think that my configuration might need some help wrt when and where to call presence functions - I will post that once I get in the office. I noticed that with svn I'm not getting any entries in pua or presentity, only in active_watchers. Thanks. -- James 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] Presence and Linksys phones - not working 1.6.1
The phones should never receive the Publish message. Please catch a trace containing this Publish and send it to me. What do you mean by before? Before updating from svn with my patch? Before I updated from 1.6.2 to SVN I think - I'll try and double-check. I have a revised patch that covers my case that I'll submit this afternoon with the trace. Any luck with the stuck BLF trace I submitted as well? I also think that my configuration might need some help wrt when and where to call presence functions - I will post that once I get in the office. I noticed that with svn I'm not getting any entries in pua or presentity, only in active_watchers. Ok here's what I saw, running the 1.6 branch SVN HEAD - it is attached in bad_publish.txt. Also, I've attached my opensips.cfg to see if I'm doing anything bad in there as well. Thanks. -- James U opensips.ip:5060 - phone.nat.ip:8640 INVITE sip:000...@phone.nat.ip:8640 SIP/2.0..Record-Route: sip:opensips.ip;r2=on;lr=on;ftag=as0175fba8;did=9e5.a4630c74..Record-Route: sip:opensips.ip:5061;r2=on;lr=on;ftag=as0175fba8;did=9e5.a4630c74..Via: SIP/2.0/UDP opensips.ip;branch=z9hG4bK9b4b.3093b021.0..Via: SIP/2.0/UDP asterisk.server.ip:5060;received=asterisk.server.ip;branch=z9hG4bK58a5bbd7;rport=5060..From: 6266395478 sip:16266395...@asterisk.server.ip;tag=as0175fba8..To: sip:000...@opensips.ip:5061..Contact: sip:16266395...@asterisk.server.ip..Call-ID: 6355d0e82d3d60622ced249859e95...@asterisk.server.ip..cseq: 102 INVITE..User-Agent: Asterisk PBX..Max-Forwards: 69..Date: Tue, 06 Apr 2010 15:12:11 GMT..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO..Supported: replaces..Content-Type: application/sdp..Content-Length: 280..P-hint: usrloc appliedv=0..o=root 6818 6818 IN IP4 asterisk.server.ip..s=session..c=IN IP4 opensips.ip..t=0 0..m=audio 35470 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -..a=ptime:20..a=sendrecv..a=nortpproxy:yes.. # U phone.nat.ip:8640 - opensips.ip:5060 SIP/2.0 100 Trying..To: sip:000...@opensips.ip:5061..From: 6266395478 sip:16266395...@asterisk.server.ip;tag=as0175fba8..Call-ID: 6355d0e82d3d60622ced249859e95...@asterisk.server.ip..cseq: 102 INVITE..Via: SIP/2.0/UDP opensips.ip;branch=z9hG4bK9b4b.3093b021.0..Via: SIP/2.0/UDP asterisk.server.ip:5060;received=asterisk.server.ip;branch=z9hG4bK58a5bbd7;rport=5060..Record-Route: sip:opensips.ip;r2=on;lr=on;ftag=as0175fba8;did=9e5.a4630c74..Record-Route: sip:opensips.ip:5061;r2=on;lr=on;ftag=as0175fba8;did=9e5.a4630c74..Server: Linksys/SPA942-6.1.3(a)..Content-Length: 0 # U phone.nat.ip:8640 - opensips.ip:5060 SIP/2.0 180 Ringing..To: sip:000...@opensips.ip:5061;tag=c3f142fab548cb0i0..From: 6266395478 sip:16266395...@asterisk.server.ip;tag=as0175fba8..Call-ID: 6355d0e82d3d60622ced249859e95...@asterisk.server.ip..cseq: 102 INVITE..Via: SIP/2.0/UDP opensips.ip;branch=z9hG4bK9b4b.3093b021.0..Via: SIP/2.0/UDP asterisk.server.ip:5060;received=asterisk.server.ip;branch=z9hG4bK58a5bbd7;rport=5060..Record-Route: sip:opensips.ip;r2=on;lr=on;ftag=as0175fba8;did=9e5.a4630c74..Record-Route: sip:opensips.ip:5061;r2=on;lr=on;ftag=as0175fba8;did=9e5.a4630c74..Contact: 000-000-0002 sip:000...@192.168.1.151:8640..Server: Linksys/SPA942-6.1.3(a)..Content-Length: 0 # U opensips.ip:5060 - phone.nat.ip:8640 PUBLISH sip:000...@phone.nat.ip:8640 SIP/2.0..Record-Route: sip:opensips.ip;lr=on;ftag=501689153a5b5fe31491a47f27dc82f5-5f2e..Via: SIP/2.0/UDP opensips.ip;branch=z9hG4bKa371.56493fb4.0..Via: SIP/2.0/UDP opensips.ip;branch=z9hG4bKa371.46493fb4.0..To: sip:000...@phone.nat.ip:8640..From: sip:000...@phone.nat.ip:8640;tag=501689153a5b5fe31491a47f27dc82f5-5f2e..CSeq: 10 PUBLISH..Call-ID: 77b9fe2016a10a4c-30...@opensips.ip..content-length: 627..User-Agent: OpenSIPS (1.6.2-notls (x86_64/linux))..Max-Forwards: 69..Event: dialog..Expires: 43201..Content-Type: application/dialog-info+xml..P-hint: outbound?xml version=1.0?.dialog-info xmlns=urn:ietf:params:xml:ns:dialog-info version=0 state=full entity=sip:000...@phone.nat.ip:8640dialog id=6355d0e82d3d60622ced249859e95...@asterisk.server.ip call-id=6355d0e82d3d60622ced249859e95...@asterisk.server.ip local-tag=c3f142fab548cb0i0 remote-tag=as0175fba8 direction=recipientstateearly/stateremoteidentity display=6266395478sip:16266395...@asterisk.server.ip/identitytarget uri=sip:16266395...@asterisk.server.ip//remotelocalidentitysip:000...@phone.nat.ip:8640/identitytarget uri=sip:000...@phone.nat.ip:8640//local/dialog/dialog-info. # U phone.nat.ip:8640 - opensips.ip:5060 SIP/2.0 501 Not Implemented..To: sip:000...@phone.nat.ip:8640;tag=1ded7a2d320fb7c4i0..From: sip:000...@phone.nat.ip:8640;tag=501689153a5b5fe31491a47f27dc82f5-5f2e..Call-ID: 77b9fe2016a10a4c-30...@opensips.ip..cseq: 10 PUBLISH..Via: SIP/2.0/UDP
Re: [OpenSIPS-Users] Presence and Linksys phones - not working 1.6.1
On Wed, Apr 7, 2010 at 2:06 AM, Anca Vamanu a...@opensips.org wrote: Hi James, What you see happens because of a improvement that I made in pua_dialoginfo module. Now the presentity_uri for the callee ( the uri that will be used as RURI in Publish message) is taken from RURI of Invite in the moment you call dialoginfo_set(before this To header was used). From the trace it seems that you call this function after you do lookup(location). Move this call upper, before lookup() changes the RURI to the contact of the phone. Also you can check out the possibility to set custom uris to be used as presentity uri by setting some pseudovariables (http://www.opensips.org/html/docs/modules/devel/pua_dialoginfo.html#id227160 ). Hi Anca, Moving the dialoginfo_set() above location() seems to fix the problem! I will let you know how things go. I also added another patch to get the green light upon startup, but I believe this causes the light to go solid amber during the first call, but then all subsequent calls seem to work ok. I will also try and see if I can duplicate the stuck 'red' state. Thanks for all your help. Regards, -- Anca Vamanu www.voice-system.ro -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS hang - 1.6.3
Btw, this happens whenever I try to place a call.
It also crashes my phone, a Cisco 509G.
-- James
On Sun, Oct 3, 2010 at 8:05 AM, James Lamanna jlama...@gmail.com wrote:
Hi,
I just had a situation where the opensips process has totally hung and
now will not respond to SIP traffic.
These are the last lines in the log file (debug=6)
Oct 3 07:54:16 [27900] DBG:tm:update_totag_set: new totag
Oct 3 07:54:16 [27900] DBG:tm:insert_timer_unsafe: [2]: 0x7f0a85d96698 (478)
Oct 3 07:54:16 [27900] DBG:tm:run_trans_callbacks:
trans=0x7f0a85d96618, callback type 128, id 0 entered
Oct 3 07:54:16 [27900] DBG:dialog:next_state_dlg: dialog
0x7f0a85d81a88 changed from state 1 to state 3, due event 3
Oct 3 07:54:16 [27900] DBG:dialog:dlg_onreply: dialog 0x7f0a85d81a88
confirmed
Oct 3 07:54:16 [27900] DBG:dialog:insert_dlg_timer_unsafe: inserting
0x7f0a85d81ac0 for 43673
Oct 3 07:54:16 [27900] DBG:dialog:ref_dlg: ref dlg 0x7f0a85d81a88 with 1 - 3
Oct 3 07:54:16 [27900] DBG:dialog:run_dlg_callbacks:
dialog=0x7f0a85d81a88, type=8
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: looking for dlg_peer
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: var found-
Voice Mailsip:99...@x.x.x.x:5060
!
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:__dialog_sendpublish:
peer_uri = Voice Mailsip:99...@x.x.x.x:5060
Oct 3 07:54:16 [27900] DBG:core:parse_to: end of header reached, state=10
Oct 3 07:54:16 [27900] DBG:core:parse_to: display={Voice Mail},
ruri={sip:99...@x.x.x.x:5060}
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: looking for dlginfo_flag
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: var NOT found!
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:__dialog_sendpublish: flag = D
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: looking for dlg_entity
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: var NOT found!
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:__dialog_sendpublish:
dialog confirmed, from=sip:u...@opensips.server
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:build_dialoginfo: new_body:
?xml version=1.0?
dialog-info xmlns=urn:ietf:params:xml:ns:dialog-info version=0
state=full entity=sip:u...@opensips.serverdialog
id=5c7ed6ad-9d1a1...@192.168.2.7
call-id=5c7ed6ad-9d1a1...@192.168.2.7
direction=initiatorstateconfirmed/stateremoteidentity
display=Voice Mailsip:99...@x.x.x.x:5060/identitytarget
uri=sip:99...@x.x.x.x:5060//remotelocalidentitysip:u...@opensips.server/identitytarget
uri=sip:u...@x.x.x.x//local/dialog/dialog-info
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:print_publ: publ:
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:print_publ: uri=
sip:u...@opensips.server
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:print_publ: id= DIALOG_PUBLISH
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:print_publ: expires= 43200
Oct 3 07:54:16 [27900] DBG:pua:send_publish:
pres_uri=sip:u...@opensips.server
Oct 3 07:54:16 [27900] DBG:pua:send_publish: Try to get hash lock [495]
Oct 3 07:54:16 [27900] DBG:pua:send_publish: Got hash lock 495
Oct 3 07:54:16 [27900] DBG:pua:search_htable: core_hash= 495
Oct 3 07:54:16 [27900] DBG:pua:search_htable: Searched:
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: pres_uri=
sip:u...@opensips.server len= 27
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: etag= - len= 0
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: id= DIALOG_PUBLISH
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: expires= -1286117656
Oct 3 07:54:16 [27900] DBG:pua:search_htable:
Oct 3 07:54:16 [27900] DBG:pua:search_htable: Found
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: pres_uri=
sip:u...@opensips.server len= 27
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: etag=
a.1286117182.27900.2.0 - len= 22
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: id= DIALOG_PUBLISH
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: expires= 3590
Oct 3 07:54:16 [27900] DBG:pua:search_htable:
Oct 3 07:54:16 [27900] DBG:pua:search_htable: no etag restriction
Oct 3 07:54:16 [27900] DBG:pua:search_htable: found record
Oct 3 07:54:16 [27900] DBG:pua:send_publish: record found in hash_table
Oct 3 07:54:16 [27900] DBG:pua:send_publish: Try to get presentity
lock 0x7f0a85d7dff0
Oct 3 07:54:16 [27902] DBG:tm:utimer_routine: timer
routine:4,tl=0x7f0a85d7f9f8 next=0x7f0a85d796e8, timeout=47340
Oct 3 07:54:16 [27902] DBG:tm:utimer_routine: timer
routine:4,tl=0x7f0a85d796e8 next=0x7f0a85d82db8, timeout=47340
Oct 3 07:54:16 [27902] DBG:tm:utimer_routine: timer
routine:4,tl=0x7f0a85d82db8 next=0x7f0a85d88ed0, timeout=47340
Oct 3 07:54:16 [27902] DBG:tm:utimer_routine: timer
routine:4,tl=0x7f0a85d88ed0 next=0x7f0a85d82ce0, timeout=47340
Oct 3 07:54:16 [27902] DBG:tm:utimer_routine: timer
routine:4,tl=0x7f0a85d82ce0 next=0x7f0a85d8bdd8, timeout=47340
Oct 3 07:54:16 [27902] DBG:tm:utimer_routine: timer
routine:4,tl=0x7f0a85d8bdd8 next=0x7f0a85d8d630, timeout=47340
Oct 3 07:54:16 [27902] DBG:tm:utimer_routine: timer
Re: [OpenSIPS-Users] OpenSIPS hang - 1.6.3
On Sun, Oct 3, 2010 at 8:17 AM, James Lamanna jlama...@gmail.com wrote:
Btw, this happens whenever I try to place a call.
It also crashes my phone, a Cisco 509G.
Also, removing all pua/presence function calls enables calls to be made again.
I assume something changed in 1.6.3 that has made my config file incorrect?
-- James
On Sun, Oct 3, 2010 at 8:05 AM, James Lamanna jlama...@gmail.com wrote:
Hi,
I just had a situation where the opensips process has totally hung and
now will not respond to SIP traffic.
These are the last lines in the log file (debug=6)
Oct 3 07:54:16 [27900] DBG:tm:update_totag_set: new totag
Oct 3 07:54:16 [27900] DBG:tm:insert_timer_unsafe: [2]: 0x7f0a85d96698 (478)
Oct 3 07:54:16 [27900] DBG:tm:run_trans_callbacks:
trans=0x7f0a85d96618, callback type 128, id 0 entered
Oct 3 07:54:16 [27900] DBG:dialog:next_state_dlg: dialog
0x7f0a85d81a88 changed from state 1 to state 3, due event 3
Oct 3 07:54:16 [27900] DBG:dialog:dlg_onreply: dialog 0x7f0a85d81a88
confirmed
Oct 3 07:54:16 [27900] DBG:dialog:insert_dlg_timer_unsafe: inserting
0x7f0a85d81ac0 for 43673
Oct 3 07:54:16 [27900] DBG:dialog:ref_dlg: ref dlg 0x7f0a85d81a88 with 1 -
3
Oct 3 07:54:16 [27900] DBG:dialog:run_dlg_callbacks:
dialog=0x7f0a85d81a88, type=8
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: looking for dlg_peer
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: var found-
Voice Mailsip:99...@x.x.x.x:5060
!
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:__dialog_sendpublish:
peer_uri = Voice Mailsip:99...@x.x.x.x:5060
Oct 3 07:54:16 [27900] DBG:core:parse_to: end of header reached, state=10
Oct 3 07:54:16 [27900] DBG:core:parse_to: display={Voice Mail},
ruri={sip:99...@x.x.x.x:5060}
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: looking for
dlginfo_flag
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: var NOT found!
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:__dialog_sendpublish: flag = D
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: looking for dlg_entity
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: var NOT found!
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:__dialog_sendpublish:
dialog confirmed, from=sip:u...@opensips.server
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:build_dialoginfo: new_body:
?xml version=1.0?
dialog-info xmlns=urn:ietf:params:xml:ns:dialog-info version=0
state=full entity=sip:u...@opensips.serverdialog
id=5c7ed6ad-9d1a1...@192.168.2.7
call-id=5c7ed6ad-9d1a1...@192.168.2.7
direction=initiatorstateconfirmed/stateremoteidentity
display=Voice Mailsip:99...@x.x.x.x:5060/identitytarget
uri=sip:99...@x.x.x.x:5060//remotelocalidentitysip:u...@opensips.server/identitytarget
uri=sip:u...@x.x.x.x//local/dialog/dialog-info
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:print_publ: publ:
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:print_publ: uri=
sip:u...@opensips.server
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:print_publ: id= DIALOG_PUBLISH
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:print_publ: expires= 43200
Oct 3 07:54:16 [27900] DBG:pua:send_publish:
pres_uri=sip:u...@opensips.server
Oct 3 07:54:16 [27900] DBG:pua:send_publish: Try to get hash lock [495]
Oct 3 07:54:16 [27900] DBG:pua:send_publish: Got hash lock 495
Oct 3 07:54:16 [27900] DBG:pua:search_htable: core_hash= 495
Oct 3 07:54:16 [27900] DBG:pua:search_htable: Searched:
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: pres_uri=
sip:u...@opensips.server len= 27
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: etag= - len= 0
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: id= DIALOG_PUBLISH
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: expires= -1286117656
Oct 3 07:54:16 [27900] DBG:pua:search_htable:
Oct 3 07:54:16 [27900] DBG:pua:search_htable: Found
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: pres_uri=
sip:u...@opensips.server len= 27
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: etag=
a.1286117182.27900.2.0 - len= 22
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: id= DIALOG_PUBLISH
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: expires= 3590
Oct 3 07:54:16 [27900] DBG:pua:search_htable:
Oct 3 07:54:16 [27900] DBG:pua:search_htable: no etag restriction
Oct 3 07:54:16 [27900] DBG:pua:search_htable: found record
Oct 3 07:54:16 [27900] DBG:pua:send_publish: record found in hash_table
Oct 3 07:54:16 [27900] DBG:pua:send_publish: Try to get presentity
lock 0x7f0a85d7dff0
Oct 3 07:54:16 [27902] DBG:tm:utimer_routine: timer
routine:4,tl=0x7f0a85d7f9f8 next=0x7f0a85d796e8, timeout=47340
Oct 3 07:54:16 [27902] DBG:tm:utimer_routine: timer
routine:4,tl=0x7f0a85d796e8 next=0x7f0a85d82db8, timeout=47340
Oct 3 07:54:16 [27902] DBG:tm:utimer_routine: timer
routine:4,tl=0x7f0a85d82db8 next=0x7f0a85d88ed0, timeout=47340
Oct 3 07:54:16 [27902] DBG:tm:utimer_routine: timer
routine:4,tl=0x7f0a85d88ed0 next=0x7f0a85d82ce0, timeout=47340
Oct 3 07:54:16 [27902] DBG:tm:utimer_routine: timer
Re: [OpenSIPS-Users] OpenSIPS hang - 1.6.3
On Sun, Oct 3, 2010 at 8:24 AM, James Lamanna jlama...@gmail.com wrote:
On Sun, Oct 3, 2010 at 8:17 AM, James Lamanna jlama...@gmail.com wrote:
Btw, this happens whenever I try to place a call.
It also crashes my phone, a Cisco 509G.
Also, removing all pua/presence function calls enables calls to be made again.
I assume something changed in 1.6.3 that has made my config file incorrect?
If I remove the second dialoginfo_set() from the local INVITE (from a
phone), then the program goes away.
However, if I need to maintain presence, don't I need to publish this,
so SUBSCRIBED phones get notified that the phone making the call is in
use?
-- James
-- James
On Sun, Oct 3, 2010 at 8:05 AM, James Lamanna jlama...@gmail.com wrote:
Hi,
I just had a situation where the opensips process has totally hung and
now will not respond to SIP traffic.
These are the last lines in the log file (debug=6)
Oct 3 07:54:16 [27900] DBG:tm:update_totag_set: new totag
Oct 3 07:54:16 [27900] DBG:tm:insert_timer_unsafe: [2]: 0x7f0a85d96698
(478)
Oct 3 07:54:16 [27900] DBG:tm:run_trans_callbacks:
trans=0x7f0a85d96618, callback type 128, id 0 entered
Oct 3 07:54:16 [27900] DBG:dialog:next_state_dlg: dialog
0x7f0a85d81a88 changed from state 1 to state 3, due event 3
Oct 3 07:54:16 [27900] DBG:dialog:dlg_onreply: dialog 0x7f0a85d81a88
confirmed
Oct 3 07:54:16 [27900] DBG:dialog:insert_dlg_timer_unsafe: inserting
0x7f0a85d81ac0 for 43673
Oct 3 07:54:16 [27900] DBG:dialog:ref_dlg: ref dlg 0x7f0a85d81a88 with 1
- 3
Oct 3 07:54:16 [27900] DBG:dialog:run_dlg_callbacks:
dialog=0x7f0a85d81a88, type=8
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: looking for dlg_peer
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: var found-
Voice Mailsip:99...@x.x.x.x:5060
!
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:__dialog_sendpublish:
peer_uri = Voice Mailsip:99...@x.x.x.x:5060
Oct 3 07:54:16 [27900] DBG:core:parse_to: end of header reached, state=10
Oct 3 07:54:16 [27900] DBG:core:parse_to: display={Voice Mail},
ruri={sip:99...@x.x.x.x:5060}
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: looking for
dlginfo_flag
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: var NOT found!
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:__dialog_sendpublish: flag = D
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: looking for dlg_entity
Oct 3 07:54:16 [27900] DBG:dialog:fetch_dlg_value: var NOT found!
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:__dialog_sendpublish:
dialog confirmed, from=sip:u...@opensips.server
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:build_dialoginfo: new_body:
?xml version=1.0?
dialog-info xmlns=urn:ietf:params:xml:ns:dialog-info version=0
state=full entity=sip:u...@opensips.serverdialog
id=5c7ed6ad-9d1a1...@192.168.2.7
call-id=5c7ed6ad-9d1a1...@192.168.2.7
direction=initiatorstateconfirmed/stateremoteidentity
display=Voice Mailsip:99...@x.x.x.x:5060/identitytarget
uri=sip:99...@x.x.x.x:5060//remotelocalidentitysip:u...@opensips.server/identitytarget
uri=sip:u...@x.x.x.x//local/dialog/dialog-info
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:print_publ: publ:
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:print_publ: uri=
sip:u...@opensips.server
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:print_publ: id= DIALOG_PUBLISH
Oct 3 07:54:16 [27900] DBG:pua_dialoginfo:print_publ: expires= 43200
Oct 3 07:54:16 [27900] DBG:pua:send_publish:
pres_uri=sip:u...@opensips.server
Oct 3 07:54:16 [27900] DBG:pua:send_publish: Try to get hash lock [495]
Oct 3 07:54:16 [27900] DBG:pua:send_publish: Got hash lock 495
Oct 3 07:54:16 [27900] DBG:pua:search_htable: core_hash= 495
Oct 3 07:54:16 [27900] DBG:pua:search_htable: Searched:
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: pres_uri=
sip:u...@opensips.server len= 27
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: etag= - len= 0
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: id= DIALOG_PUBLISH
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: expires= -1286117656
Oct 3 07:54:16 [27900] DBG:pua:search_htable:
Oct 3 07:54:16 [27900] DBG:pua:search_htable: Found
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: pres_uri=
sip:u...@opensips.server len= 27
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: etag=
a.1286117182.27900.2.0 - len= 22
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: id= DIALOG_PUBLISH
Oct 3 07:54:16 [27900] DBG:pua:print_ua_pres: expires= 3590
Oct 3 07:54:16 [27900] DBG:pua:search_htable:
Oct 3 07:54:16 [27900] DBG:pua:search_htable: no etag restriction
Oct 3 07:54:16 [27900] DBG:pua:search_htable: found record
Oct 3 07:54:16 [27900] DBG:pua:send_publish: record found in hash_table
Oct 3 07:54:16 [27900] DBG:pua:send_publish: Try to get presentity
lock 0x7f0a85d7dff0
Oct 3 07:54:16 [27902] DBG:tm:utimer_routine: timer
routine:4,tl=0x7f0a85d7f9f8 next=0x7f0a85d796e8, timeout=47340
Oct 3 07:54:16 [27902] DBG:tm:utimer_routine: timer
routine:4,tl=0x7f0a85d796e8
Re: [OpenSIPS-Users] OpenSIPS hang - 1.6.3
Unfortunately, I'm still getting a hang of some sort with 1.6 trunk. It doesn't happen quite as fast, but it still occurs after I try and make a call. However, the call still does not complete. Sometimes it doesn't totally hang, but the registration of my phone is dropped. Opensips then appears to reset and get the registration back. -- James On Mon, Oct 4, 2010 at 2:39 AM, Anca Vamanu a...@opensips.org wrote: Hi James, Please try the svn version, also for 1.6 branch. There was indeed a deadlock problem, but it has been in the svn version. Regards, -- Anca Vamanu www.voice-system.ro On 10/03/2010 06:36 PM, James Lamanna wrote: On Sun, Oct 3, 2010 at 8:24 AM, James Lamannajlama...@gmail.com wrote: On Sun, Oct 3, 2010 at 8:17 AM, James Lamannajlama...@gmail.com wrote: Btw, this happens whenever I try to place a call. It also crashes my phone, a Cisco 509G. Also, removing all pua/presence function calls enables calls to be made again. I assume something changed in 1.6.3 that has made my config file incorrect? If I remove the second dialoginfo_set() from the local INVITE (from a phone), then the program goes away. However, if I need to maintain presence, don't I need to publish this, so SUBSCRIBED phones get notified that the phone making the call is in use? -- James ___ 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] OpenSIPS hang - 1.6.3
Yeah, I've never successfully had presence for BLF work properly for me with Linksys/Cisco SPA 9xx/5xx phones. This is the one thing that is blocking me from moving all my phone registrations to OpenSIPS, so I'm really hoping that we can get it all working. -- James On Mon, Oct 4, 2010 at 8:49 PM, osiris123d duane.lar...@gmail.com wrote: A long time ago I was working with PUA and Presence and I started having issues. I upgraded to the latest version when I heard about the deadlock, but I am still noticing from Monit that stuff freezes up. I usually have to restart the opensips process and all is better again. I am reinstalling a fresh version of OpenSIPS on a new VM, but I swear when I started messing with PUA to get Call Pickup and BLF my box started having issues. We shall see with the new box. Hopefully it was something else. -- View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-hang-1-6-3-tp5596289p5601771.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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] OpenSIPS hang - 1.6.3
Ok it looks like the 1.6 trunk has an error in the build/install process: # svn up At revision 7247. # make all (or make install) . make[1]: Entering directory `/home/james/opensips_1_6/modules/xlog' make[1]: *** No targets specified and no makefile found. Stop. make[1]: Leaving directory `/home/james/opensips_1_6/modules/xlog' make: *** [modules] Error 2 -- James On Tue, Oct 5, 2010 at 4:43 AM, Anca Vamanu a...@opensips.org wrote: Hi James, Please describe the problems that you see - there is no one else reporting problems with the new version of pua module so I need to know exactly which is the behavior. Do you see the opensips process ocupying 100% cpu or what happens? Regards, -- Anca Vamanu www.voice-system.ro On 10/05/2010 04:09 AM, James Lamanna wrote: Unfortunately, I'm still getting a hang of some sort with 1.6 trunk. It doesn't happen quite as fast, but it still occurs after I try and make a call. However, the call still does not complete. Sometimes it doesn't totally hang, but the registration of my phone is dropped. Opensips then appears to reset and get the registration back. -- James On Mon, Oct 4, 2010 at 2:39 AM, Anca Vamanua...@opensips.org wrote: Hi James, Please try the svn version, also for 1.6 branch. There was indeed a deadlock problem, but it has been in the svn version. Regards, -- Anca Vamanu www.voice-system.ro On 10/03/2010 06:36 PM, James Lamanna wrote: On Sun, Oct 3, 2010 at 8:24 AM, James Lamannajlama...@gmail.com wrote: On Sun, Oct 3, 2010 at 8:17 AM, James Lamannajlama...@gmail.com wrote: Btw, this happens whenever I try to place a call. It also crashes my phone, a Cisco 509G. Also, removing all pua/presence function calls enables calls to be made again. I assume something changed in 1.6.3 that has made my config file incorrect? If I remove the second dialoginfo_set() from the local INVITE (from a phone), then the program goes away. However, if I need to maintain presence, don't I need to publish this, so SUBSCRIBED phones get notified that the phone making the call is in use? -- James ___ 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] OpenSIPS hang - 1.6.3
I removed the modules/xlog directory and rebuilt, and now things seem to be working better. I'll let you know if I have any more issues Thanks for your help. -- James On Tue, Oct 5, 2010 at 7:12 AM, James Lamanna jlama...@gmail.com wrote: Ok it looks like the 1.6 trunk has an error in the build/install process: # svn up At revision 7247. # make all (or make install) . make[1]: Entering directory `/home/james/opensips_1_6/modules/xlog' make[1]: *** No targets specified and no makefile found. Stop. make[1]: Leaving directory `/home/james/opensips_1_6/modules/xlog' make: *** [modules] Error 2 -- James On Tue, Oct 5, 2010 at 4:43 AM, Anca Vamanu a...@opensips.org wrote: Hi James, Please describe the problems that you see - there is no one else reporting problems with the new version of pua module so I need to know exactly which is the behavior. Do you see the opensips process ocupying 100% cpu or what happens? Regards, -- Anca Vamanu www.voice-system.ro On 10/05/2010 04:09 AM, James Lamanna wrote: Unfortunately, I'm still getting a hang of some sort with 1.6 trunk. It doesn't happen quite as fast, but it still occurs after I try and make a call. However, the call still does not complete. Sometimes it doesn't totally hang, but the registration of my phone is dropped. Opensips then appears to reset and get the registration back. -- James On Mon, Oct 4, 2010 at 2:39 AM, Anca Vamanua...@opensips.org wrote: Hi James, Please try the svn version, also for 1.6 branch. There was indeed a deadlock problem, but it has been in the svn version. Regards, -- Anca Vamanu www.voice-system.ro On 10/03/2010 06:36 PM, James Lamanna wrote: On Sun, Oct 3, 2010 at 8:24 AM, James Lamannajlama...@gmail.com wrote: On Sun, Oct 3, 2010 at 8:17 AM, James Lamannajlama...@gmail.com wrote: Btw, this happens whenever I try to place a call. It also crashes my phone, a Cisco 509G. Also, removing all pua/presence function calls enables calls to be made again. I assume something changed in 1.6.3 that has made my config file incorrect? If I remove the second dialoginfo_set() from the local INVITE (from a phone), then the program goes away. However, if I need to maintain presence, don't I need to publish this, so SUBSCRIBED phones get notified that the phone making the call is in use? -- James ___ 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] Getting a Cisco 7960 to register behind a PIX
Hi, I was wondering if anyone had any experience getting a Cisco 7960 phone to register to opensips when the phone is behind a PIX firewall. I'm having a hell of a time getting it to register. I see these messages: U nat.ip:2260 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a..From: sip:...@opensips.ip;user=phone..To: sip:x...@opensips.ip;user=phone..Call-ID: 0003 6be7-b0aa0007-46220771-115f4...@10.20.33.22..date: Mon, 06 Dec 2010 18:10:49 GMT..CSeq: 107 REGISTER ..User-Agent: CSCO/7..Contact: sip:x...@10.20.33.22:5060..Content-Length: 0..Expires: 45 # U opensips.ip:5060 - nat.ip:2260 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a;rport=2260;receiv ed=208.90.184.123..From: sip:xx...@opensips.ip;user=phone..To: sip:x...@opensips.ip; user=phone;tag=c5cd5e6c2a1d4c975e04c2ff1b643904.5bf3..Call-ID: 00036be7-b0aa0007-46220771-115f4fcc@ 10.20.33.22..CSeq: 107 REGISTER..WWW-Authenticate: Digest realm=asterisk, nonce=4cfd27fe780d7 1826527370e7c8b97f663425df75489..Server: OpenSIPS (1.6.3-notls (x86_64/linux))..Content-Length: 0.. .. # U nat.ip:2260 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a..From: sip:xx...@opensips.ip;user=phone..To: sip:x...@opensips.ip;user=phone..Call-ID: 0003 6be7-b0aa0007-46220771-115f4...@10.20.33.22..date: Mon, 06 Dec 2010 18:10:49 GMT..CSeq: 107 REGISTER ..User-Agent: CSCO/7..Contact: sip:xx...@10.20.33.22:5060..Content-Length: 0..Expires: 45 # U opensips.ip:5060 - nat.ip:2260 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a;rport=2260;receiv ed=208.90.184.123..From: sip:x...@opensips.ip;user=phone..To: sip:xx...@opensips.ip; user=phone;tag=c5cd5e6c2a1d4c975e04c2ff1b643904.5bf3..Call-ID: 00036be7-b0aa0007-46220771-115f4fcc@ 10.20.33.22..CSeq: 107 REGISTER..WWW-Authenticate: Digest realm=asterisk, nonce=4cfd2800780e5 c3381d838a044479357aa6c660df432..Server: OpenSIPS (1.6.3-notls (x86_64/linux))..Content-Length: 0.. This suggests the 401 response is not making it back to the phonebut I'm not sure why the PIX would be blocking it. All sip fixup is off. Any configuration suggestions would be much appreciated. The phone has: nat_enable: 0 nat_received_processing: 0 That was the only way I could get opensips to send the responses back to the correct port. Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Getting a Cisco 7960 to register behind a PIX
Hi Mario, On Mon, Dec 6, 2010 at 11:08 AM, Advantia VoIP Systems i...@advantia.ca wrote: James, On your TFTP server, add this line to either SIPDefault.cnf or SIPmacaddress.cnf: nat_enable : 1 Then reboot your phone. Adding that results in a problem where OpenSIPS does not send the reply back to the correct port: U nat.ip:2370 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP nat.ip:8427;branch=z9hG4bK79682dfb.. From: sip:9515013...@opensips.ip;user=phone..To: sip:9515013...@opensips.ip;user=phone..Call-ID: 00036be7-b0aa0007-736f1483-25859...@nat.ip..date: Mon, 06 Dec 2010 21:28:11 GMT..CSeq: 200 REGISTER..User-Agent : CSCO/7..Contact: sip:9515013...@nat.ip:8427..Content-Length: 0..Expires: 45 # U opensips.ip:5060 - nat.ip:8427 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP nat.ip:8427;branch=z9hG4bK79682dfb..From: sip:9515013...@opensips.ip;user=phone..To: sip:9515013...@opensips.ip;user=phone;tag=c5cd5e6c2a1d4c975e04c2ff1b643904.b4fc..Call-ID: 00036be7-b0aa0007-736f1483-25859...@nat.ip..cseq: 200 REGISTER..WWW-Authenticate: Digest realm=asterisk, nonce=4cfd563d7e883d77627517b1b7e55ed334da11e6d088..Server: OpenSIPS (1.6.3-notls (x86_64/linux))..Content-Length: 0 -- James Mario http://advantia.ca On Mon, Dec 6, 2010 at 10:17 AM, James Lamanna jlama...@gmail.com wrote: Hi, I was wondering if anyone had any experience getting a Cisco 7960 phone to register to opensips when the phone is behind a PIX firewall. I'm having a hell of a time getting it to register. I see these messages: U nat.ip:2260 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a..From: sip:...@opensips.ip;user=phone..To: sip:x...@opensips.ip;user=phone..Call-ID: 0003 6be7-b0aa0007-46220771-115f4...@10.20.33.22..date: Mon, 06 Dec 2010 18:10:49 GMT..CSeq: 107 REGISTER ..User-Agent: CSCO/7..Contact: sip:x...@10.20.33.22:5060..Content-Length: 0..Expires: 45 # U opensips.ip:5060 - nat.ip:2260 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a;rport=2260;receiv ed=208.90.184.123..From: sip:xx...@opensips.ip;user=phone..To: sip:x...@opensips.ip; user=phone;tag=c5cd5e6c2a1d4c975e04c2ff1b643904.5bf3..Call-ID: 00036be7-b0aa0007-46220771-115f4fcc@ 10.20.33.22..CSeq: 107 REGISTER..WWW-Authenticate: Digest realm=asterisk, nonce=4cfd27fe780d7 1826527370e7c8b97f663425df75489..Server: OpenSIPS (1.6.3-notls (x86_64/linux))..Content-Length: 0.. .. # U nat.ip:2260 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a..From: sip:xx...@opensips.ip;user=phone..To: sip:x...@opensips.ip;user=phone..Call-ID: 0003 6be7-b0aa0007-46220771-115f4...@10.20.33.22..date: Mon, 06 Dec 2010 18:10:49 GMT..CSeq: 107 REGISTER ..User-Agent: CSCO/7..Contact: sip:xx...@10.20.33.22:5060..Content-Length: 0..Expires: 45 # U opensips.ip:5060 - nat.ip:2260 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a;rport=2260;receiv ed=208.90.184.123..From: sip:x...@opensips.ip;user=phone..To: sip:xx...@opensips.ip; user=phone;tag=c5cd5e6c2a1d4c975e04c2ff1b643904.5bf3..Call-ID: 00036be7-b0aa0007-46220771-115f4fcc@ 10.20.33.22..CSeq: 107 REGISTER..WWW-Authenticate: Digest realm=asterisk, nonce=4cfd2800780e5 c3381d838a044479357aa6c660df432..Server: OpenSIPS (1.6.3-notls (x86_64/linux))..Content-Length: 0.. This suggests the 401 response is not making it back to the phonebut I'm not sure why the PIX would be blocking it. All sip fixup is off. Any configuration suggestions would be much appreciated. The phone has: nat_enable: 0 nat_received_processing: 0 That was the only way I could get opensips to send the responses back to the correct port. Thanks. -- James ___ 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Getting a Cisco 7960 to register behind a PIX
Hi Bogdan, I guess I'm confused as to why you say its being transmitted back to the same IP:Port: U nat.ip:2370 - opensips.ip:5060 U opensips.ip:5060 - nat.ip:8427 Shouldn't it be going back to port 2370? And not 8427? -- James On Tue, Dec 7, 2010 at 2:43 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi James, From proxy point of view, everything looks ok - I see the reply sent back to the exact IP:port where the request came fromSo the reply should make it through the NAT...But it seams it doesn't as the phone keeps retransmitting the REGISTER.. Again, from NAT pov, opensips is doing the right stuff (doing symmetric signalling) - there is nothing more you can do here for opensips..Maybe it is something specific to the NAT device - any possibility to debug/trace on it ? Regards, Bogdan James Lamanna wrote: Hi, I was wondering if anyone had any experience getting a Cisco 7960 phone to register to opensips when the phone is behind a PIX firewall. I'm having a hell of a time getting it to register. I see these messages: U nat.ip:2260 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a..From: sip:...@opensips.ip;user=phone..To: sip:x...@opensips.ip;user=phone..Call-ID: 0003 6be7-b0aa0007-46220771-115f4...@10.20.33.22..date: Mon, 06 Dec 2010 18:10:49 GMT..CSeq: 107 REGISTER ..User-Agent: CSCO/7..Contact: sip:x...@10.20.33.22:5060..Content-Length: 0..Expires: 45 # U opensips.ip:5060 - nat.ip:2260 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a;rport=2260;receiv ed=208.90.184.123..From: sip:xx...@opensips.ip;user=phone..To: sip:x...@opensips.ip; user=phone;tag=c5cd5e6c2a1d4c975e04c2ff1b643904.5bf3..Call-ID: 00036be7-b0aa0007-46220771-115f4fcc@ 10.20.33.22..CSeq: 107 REGISTER..WWW-Authenticate: Digest realm=asterisk, nonce=4cfd27fe780d7 1826527370e7c8b97f663425df75489..Server: OpenSIPS (1.6.3-notls (x86_64/linux))..Content-Length: 0.. .. # U nat.ip:2260 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a..From: sip:xx...@opensips.ip;user=phone..To: sip:x...@opensips.ip;user=phone..Call-ID: 0003 6be7-b0aa0007-46220771-115f4...@10.20.33.22..date: Mon, 06 Dec 2010 18:10:49 GMT..CSeq: 107 REGISTER ..User-Agent: CSCO/7..Contact: sip:xx...@10.20.33.22:5060..Content-Length: 0..Expires: 45 # U opensips.ip:5060 - nat.ip:2260 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a;rport=2260;receiv ed=208.90.184.123..From: sip:x...@opensips.ip;user=phone..To: sip:xx...@opensips.ip; user=phone;tag=c5cd5e6c2a1d4c975e04c2ff1b643904.5bf3..Call-ID: 00036be7-b0aa0007-46220771-115f4fcc@ 10.20.33.22..CSeq: 107 REGISTER..WWW-Authenticate: Digest realm=asterisk, nonce=4cfd2800780e5 c3381d838a044479357aa6c660df432..Server: OpenSIPS (1.6.3-notls (x86_64/linux))..Content-Length: 0.. This suggests the 401 response is not making it back to the phonebut I'm not sure why the PIX would be blocking it. All sip fixup is off. Any configuration suggestions would be much appreciated. The phone has: nat_enable: 0 nat_received_processing: 0 That was the only way I could get opensips to send the responses back to the correct port. Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA 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] Getting a Cisco 7960 to register behind a PIX
On Tue, Dec 7, 2010 at 9:32 AM, Duane Larson duane.lar...@gmail.com wrote: From your SIP message U nat.ip:2370 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP nat.ip:8427;branch=z9hG4bK79682dfb.. From: sip:9515013...@opensips.ip;user=phone..To: sip:9515013...@opensips.ip;user=phone..Call-ID: 00036be7-b0aa0007-736f1483-25859...@nat.ip..date: Mon, 06 Dec 2010 21:28:11 GMT..CSeq: 200 REGISTER..User-Agent : CSCO/7..Contact: sip:9515013...@nat.ip:8427..Content-Length: 0..Expires: 45 In the VIA header I believe your phone is saying Talk to me over nat.ip:8427 You might want to set up logging on your PIX/ASA firewall to see whats getting blocked, but from the way you've explained the issue it doesn't sound like an OpenSIPS issue. Sounds like a firewall issue or Cisco phone issue. Logging on the PIX definitely sees packets coming back 8427, which since they aren't part of an established connection get dropped. Maybe going to opensips these phones need sip fixup on, though going directly to Asterisk, they have been working with sip fixup off... -- James On Tue, Dec 7, 2010 at 10:22 AM, James Lamanna jlama...@gmail.com wrote: Hi Bogdan, I guess I'm confused as to why you say its being transmitted back to the same IP:Port: U nat.ip:2370 - opensips.ip:5060 U opensips.ip:5060 - nat.ip:8427 Shouldn't it be going back to port 2370? And not 8427? -- James On Tue, Dec 7, 2010 at 2:43 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi James, From proxy point of view, everything looks ok - I see the reply sent back to the exact IP:port where the request came fromSo the reply should make it through the NAT...But it seams it doesn't as the phone keeps retransmitting the REGISTER.. Again, from NAT pov, opensips is doing the right stuff (doing symmetric signalling) - there is nothing more you can do here for opensips..Maybe it is something specific to the NAT device - any possibility to debug/trace on it ? Regards, Bogdan James Lamanna wrote: Hi, I was wondering if anyone had any experience getting a Cisco 7960 phone to register to opensips when the phone is behind a PIX firewall. I'm having a hell of a time getting it to register. I see these messages: U nat.ip:2260 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a..From: sip:...@opensips.ip;user=phone..To: sip:x...@opensips.ip;user=phone..Call-ID: 0003 6be7-b0aa0007-46220771-115f4...@10.20.33.22..date: Mon, 06 Dec 2010 18:10:49 GMT..CSeq: 107 REGISTER ..User-Agent: CSCO/7..Contact: sip:x...@10.20.33.22:5060..Content-Length: 0..Expires: 45 # U opensips.ip:5060 - nat.ip:2260 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a;rport=2260;receiv ed=208.90.184.123..From: sip:xx...@opensips.ip;user=phone..To: sip:x...@opensips.ip; user=phone;tag=c5cd5e6c2a1d4c975e04c2ff1b643904.5bf3..Call-ID: 00036be7-b0aa0007-46220771-115f4fcc@ 10.20.33.22..CSeq: 107 REGISTER..WWW-Authenticate: Digest realm=asterisk, nonce=4cfd27fe780d7 1826527370e7c8b97f663425df75489..Server: OpenSIPS (1.6.3-notls (x86_64/linux))..Content-Length: 0.. .. # U nat.ip:2260 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a..From: sip:xx...@opensips.ip;user=phone..To: sip:x...@opensips.ip;user=phone..Call-ID: 0003 6be7-b0aa0007-46220771-115f4...@10.20.33.22..date: Mon, 06 Dec 2010 18:10:49 GMT..CSeq: 107 REGISTER ..User-Agent: CSCO/7..Contact: sip:xx...@10.20.33.22:5060..Content-Length: 0..Expires: 45 # U opensips.ip:5060 - nat.ip:2260 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a;rport=2260;receiv ed=208.90.184.123..From: sip:x...@opensips.ip;user=phone..To: sip:xx...@opensips.ip; user=phone;tag=c5cd5e6c2a1d4c975e04c2ff1b643904.5bf3..Call-ID: 00036be7-b0aa0007-46220771-115f4fcc@ 10.20.33.22..CSeq: 107 REGISTER..WWW-Authenticate: Digest realm=asterisk, nonce=4cfd2800780e5 c3381d838a044479357aa6c660df432..Server: OpenSIPS (1.6.3-notls (x86_64/linux))..Content-Length: 0.. This suggests the 401 response is not making it back to the phonebut I'm not sure why the PIX would be blocking it. All sip fixup is off. Any configuration suggestions would be much appreciated. The phone has: nat_enable: 0 nat_received_processing: 0 That was the only way I could get opensips to send the responses back to the correct port. Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro
Re: [OpenSIPS-Users] Getting a Cisco 7960 to register behind a PIX
On Tue, Dec 7, 2010 at 11:42 AM, Duane Larson duane.lar...@gmail.com wrote: From your original post before you set up nat enable on the Cisco phone OpenSIPS was replying back on the 2260 port U nat.ip:2260 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP # U opensips.ip:5060 - nat.ip:2260 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP So right there without configuring NatEnable on the Cisco phone OpenSIPS is sending back to the original port that the Cisco phone used correct? Yes, that is correct. That is with nat_enable : 0. -- James On Tue, Dec 7, 2010 at 1:34 PM, James Lamanna jlama...@gmail.com wrote: On Tue, Dec 7, 2010 at 9:32 AM, Duane Larson duane.lar...@gmail.com wrote: From your SIP message U nat.ip:2370 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP nat.ip:8427;branch=z9hG4bK79682dfb.. From: sip:9515013...@opensips.ip;user=phone..To: sip:9515013...@opensips.ip;user=phone..Call-ID: 00036be7-b0aa0007-736f1483-25859...@nat.ip..date: Mon, 06 Dec 2010 21:28:11 GMT..CSeq: 200 REGISTER..User-Agent : CSCO/7..Contact: sip:9515013...@nat.ip:8427..Content-Length: 0..Expires: 45 In the VIA header I believe your phone is saying Talk to me over nat.ip:8427 You might want to set up logging on your PIX/ASA firewall to see whats getting blocked, but from the way you've explained the issue it doesn't sound like an OpenSIPS issue. Sounds like a firewall issue or Cisco phone issue. Logging on the PIX definitely sees packets coming back 8427, which since they aren't part of an established connection get dropped. Maybe going to opensips these phones need sip fixup on, though going directly to Asterisk, they have been working with sip fixup off... -- James On Tue, Dec 7, 2010 at 10:22 AM, James Lamanna jlama...@gmail.com wrote: Hi Bogdan, I guess I'm confused as to why you say its being transmitted back to the same IP:Port: U nat.ip:2370 - opensips.ip:5060 U opensips.ip:5060 - nat.ip:8427 Shouldn't it be going back to port 2370? And not 8427? -- James On Tue, Dec 7, 2010 at 2:43 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi James, From proxy point of view, everything looks ok - I see the reply sent back to the exact IP:port where the request came fromSo the reply should make it through the NAT...But it seams it doesn't as the phone keeps retransmitting the REGISTER.. Again, from NAT pov, opensips is doing the right stuff (doing symmetric signalling) - there is nothing more you can do here for opensips..Maybe it is something specific to the NAT device - any possibility to debug/trace on it ? Regards, Bogdan James Lamanna wrote: Hi, I was wondering if anyone had any experience getting a Cisco 7960 phone to register to opensips when the phone is behind a PIX firewall. I'm having a hell of a time getting it to register. I see these messages: U nat.ip:2260 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a..From: sip:...@opensips.ip;user=phone..To: sip:x...@opensips.ip;user=phone..Call-ID: 0003 6be7-b0aa0007-46220771-115f4...@10.20.33.22..date: Mon, 06 Dec 2010 18:10:49 GMT..CSeq: 107 REGISTER ..User-Agent: CSCO/7..Contact: sip:x...@10.20.33.22:5060..Content-Length: 0..Expires: 45 # U opensips.ip:5060 - nat.ip:2260 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a;rport=2260;receiv ed=208.90.184.123..From: sip:xx...@opensips.ip;user=phone..To: sip:x...@opensips.ip; user=phone;tag=c5cd5e6c2a1d4c975e04c2ff1b643904.5bf3..Call-ID: 00036be7-b0aa0007-46220771-115f4fcc@ 10.20.33.22..CSeq: 107 REGISTER..WWW-Authenticate: Digest realm=asterisk, nonce=4cfd27fe780d7 1826527370e7c8b97f663425df75489..Server: OpenSIPS (1.6.3-notls (x86_64/linux))..Content-Length: 0.. .. # U nat.ip:2260 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a..From: sip:xx...@opensips.ip;user=phone..To: sip:x...@opensips.ip;user=phone..Call-ID: 0003 6be7-b0aa0007-46220771-115f4...@10.20.33.22..date: Mon, 06 Dec 2010 18:10:49 GMT..CSeq: 107 REGISTER ..User-Agent: CSCO/7..Contact: sip:xx...@10.20.33.22:5060..Content-Length: 0..Expires: 45 # U opensips.ip:5060 - nat.ip:2260 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a;rport=2260;receiv ed=208.90.184.123..From: sip:x...@opensips.ip;user=phone..To: sip:xx...@opensips.ip; user=phone;tag=c5cd5e6c2a1d4c975e04c2ff1b643904.5bf3..Call-ID: 00036be7-b0aa0007-46220771-115f4fcc@ 10.20.33.22..CSeq: 107 REGISTER..WWW-Authenticate: Digest realm=asterisk, nonce=4cfd2800780e5
Re: [OpenSIPS-Users] Getting a Cisco 7960 to register behind a PIX
Here's the SIP traffic from my phone now running v8.9 with nat_enable = 1 and nat_received_processing = 1. BTW this phone has no issues registering to asterisk on a different line key. -- James U nat.ip:6212 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP nat.ip:8427;branch=z9hG4bK67291d74..From: sip:...@opensips.ip;tag=00036be7b0aa000731de6fab-4eefd488..To: sip:...@opensips.ip.. Call-ID: 00036be7-b0aa0007-5a172506-53e80...@nat.ip..max-forwards: 70..CSeq: 101 REGISTER..User-Agent: Cisco-CP7960G/8.0..Contact: sip:x...@nat.ip:8427;user=phone;transport=udp;+sip. instance=urn:uuid:----00036be7b0aa;+u.sip!model.ccm.cisco.com=7..Content-Length: 0..Expires: 45 # Uopensips.ip:5060 - nat.ip:8427 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP nat.ip:8427;branch=z9hG4bK67291d74..From: sip:x...@opensips.ip;tag=00036be7b0aa000731de6fab-4eefd488..To: sip:xx...@opensips.ip;tag=c5cd5e 6c2a1d4c975e04c2ff1b643904.c6b0..Call-ID: 00036be7-b0aa0007-5a172506-53e80...@nat.ip..cseq: 101 REGISTER..WWW-Authenticate: Digest realm=asterisk, nonce=4d010bf1000104ac9cec46f3f3eafb667ac1d37dd4 c56fce..Server: OpenSIPS (1.6.3-notls (x86_64/linux))..Content-Length: 0 On Tue, Dec 7, 2010 at 2:29 PM, Advantia VoIP Systems i...@advantia.ca wrote: James, When I look at my 7940 phones, I am running version 8.8. It seems to me that this could/should be fixable at your PIX but what are the chance of you flashing your phone to a more recent firmware and seeing if that is helps with the port numbering issue. Just a guess... Mario On Tue, Dec 7, 2010 at 1:14 PM, James Lamanna jlama...@gmail.com wrote: On Tue, Dec 7, 2010 at 11:42 AM, Duane Larson duane.lar...@gmail.com wrote: From your original post before you set up nat enable on the Cisco phone OpenSIPS was replying back on the 2260 port U nat.ip:2260 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP # U opensips.ip:5060 - nat.ip:2260 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP So right there without configuring NatEnable on the Cisco phone OpenSIPS is sending back to the original port that the Cisco phone used correct? Yes, that is correct. That is with nat_enable : 0. -- James On Tue, Dec 7, 2010 at 1:34 PM, James Lamanna jlama...@gmail.com wrote: On Tue, Dec 7, 2010 at 9:32 AM, Duane Larson duane.lar...@gmail.com wrote: From your SIP message U nat.ip:2370 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP nat.ip:8427;branch=z9hG4bK79682dfb.. From: sip:9515013...@opensips.ip;user=phone..To: sip:9515013...@opensips.ip;user=phone..Call-ID: 00036be7-b0aa0007-736f1483-25859...@nat.ip..date: Mon, 06 Dec 2010 21:28:11 GMT..CSeq: 200 REGISTER..User-Agent : CSCO/7..Contact: sip:9515013...@nat.ip:8427..Content-Length: 0..Expires: 45 In the VIA header I believe your phone is saying Talk to me over nat.ip:8427 You might want to set up logging on your PIX/ASA firewall to see whats getting blocked, but from the way you've explained the issue it doesn't sound like an OpenSIPS issue. Sounds like a firewall issue or Cisco phone issue. Logging on the PIX definitely sees packets coming back 8427, which since they aren't part of an established connection get dropped. Maybe going to opensips these phones need sip fixup on, though going directly to Asterisk, they have been working with sip fixup off... -- James On Tue, Dec 7, 2010 at 10:22 AM, James Lamanna jlama...@gmail.com wrote: Hi Bogdan, I guess I'm confused as to why you say its being transmitted back to the same IP:Port: U nat.ip:2370 - opensips.ip:5060 U opensips.ip:5060 - nat.ip:8427 Shouldn't it be going back to port 2370? And not 8427? -- James On Tue, Dec 7, 2010 at 2:43 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi James, From proxy point of view, everything looks ok - I see the reply sent back to the exact IP:port where the request came fromSo the reply should make it through the NAT...But it seams it doesn't as the phone keeps retransmitting the REGISTER.. Again, from NAT pov, opensips is doing the right stuff (doing symmetric signalling) - there is nothing more you can do here for opensips..Maybe it is something specific to the NAT device - any possibility to debug/trace on it ? Regards, Bogdan James Lamanna wrote: Hi, I was wondering if anyone had any experience getting a Cisco 7960 phone to register to opensips when the phone is behind a PIX firewall. I'm having a hell of a time getting it to register. I see these messages: U nat.ip:2260 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP 10.20.33.22:5060;branch=z9hG4bK48039e3a..From: sip:
Re: [OpenSIPS-Users] Getting a Cisco 7960 to register behind a PIX
So here's something I noticed, I'm using nat_uac_test(3) in my configuration. If you look at the REGISTER message, this test does not pass, because the NATed IP is in the Contact Header and the VIA tag. However, test 16 looks at the source port != VIA port, which would pass. I wonder if this would fix the issue. Is adding that test bad in any way? -- James On Thu, Dec 9, 2010 at 9:04 AM, James Lamanna jlama...@gmail.com wrote: Here's the SIP traffic from my phone now running v8.9 with nat_enable = 1 and nat_received_processing = 1. BTW this phone has no issues registering to asterisk on a different line key. -- James U nat.ip:6212 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP nat.ip:8427;branch=z9hG4bK67291d74..From: sip:...@opensips.ip;tag=00036be7b0aa000731de6fab-4eefd488..To: sip:...@opensips.ip.. Call-ID: 00036be7-b0aa0007-5a172506-53e80...@nat.ip..max-forwards: 70..CSeq: 101 REGISTER..User-Agent: Cisco-CP7960G/8.0..Contact: sip:x...@nat.ip:8427;user=phone;transport=udp;+sip. instance=urn:uuid:----00036be7b0aa;+u.sip!model.ccm.cisco.com=7..Content-Length: 0..Expires: 45 # Uopensips.ip:5060 - nat.ip:8427 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP nat.ip:8427;branch=z9hG4bK67291d74..From: sip:x...@opensips.ip;tag=00036be7b0aa000731de6fab-4eefd488..To: sip:xx...@opensips.ip;tag=c5cd5e 6c2a1d4c975e04c2ff1b643904.c6b0..Call-ID: 00036be7-b0aa0007-5a172506-53e80...@nat.ip..cseq: 101 REGISTER..WWW-Authenticate: Digest realm=asterisk, nonce=4d010bf1000104ac9cec46f3f3eafb667ac1d37dd4 c56fce..Server: OpenSIPS (1.6.3-notls (x86_64/linux))..Content-Length: 0 On Tue, Dec 7, 2010 at 2:29 PM, Advantia VoIP Systems i...@advantia.ca wrote: James, When I look at my 7940 phones, I am running version 8.8. It seems to me that this could/should be fixable at your PIX but what are the chance of you flashing your phone to a more recent firmware and seeing if that is helps with the port numbering issue. Just a guess... Mario On Tue, Dec 7, 2010 at 1:14 PM, James Lamanna jlama...@gmail.com wrote: On Tue, Dec 7, 2010 at 11:42 AM, Duane Larson duane.lar...@gmail.com wrote: From your original post before you set up nat enable on the Cisco phone OpenSIPS was replying back on the 2260 port U nat.ip:2260 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP # U opensips.ip:5060 - nat.ip:2260 SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP So right there without configuring NatEnable on the Cisco phone OpenSIPS is sending back to the original port that the Cisco phone used correct? Yes, that is correct. That is with nat_enable : 0. -- James On Tue, Dec 7, 2010 at 1:34 PM, James Lamanna jlama...@gmail.com wrote: On Tue, Dec 7, 2010 at 9:32 AM, Duane Larson duane.lar...@gmail.com wrote: From your SIP message U nat.ip:2370 - opensips.ip:5060 REGISTER sip:opensips.ip SIP/2.0..Via: SIP/2.0/UDP nat.ip:8427;branch=z9hG4bK79682dfb.. From: sip:9515013...@opensips.ip;user=phone..To: sip:9515013...@opensips.ip;user=phone..Call-ID: 00036be7-b0aa0007-736f1483-25859...@nat.ip..date: Mon, 06 Dec 2010 21:28:11 GMT..CSeq: 200 REGISTER..User-Agent : CSCO/7..Contact: sip:9515013...@nat.ip:8427..Content-Length: 0..Expires: 45 In the VIA header I believe your phone is saying Talk to me over nat.ip:8427 You might want to set up logging on your PIX/ASA firewall to see whats getting blocked, but from the way you've explained the issue it doesn't sound like an OpenSIPS issue. Sounds like a firewall issue or Cisco phone issue. Logging on the PIX definitely sees packets coming back 8427, which since they aren't part of an established connection get dropped. Maybe going to opensips these phones need sip fixup on, though going directly to Asterisk, they have been working with sip fixup off... -- James On Tue, Dec 7, 2010 at 10:22 AM, James Lamanna jlama...@gmail.com wrote: Hi Bogdan, I guess I'm confused as to why you say its being transmitted back to the same IP:Port: U nat.ip:2370 - opensips.ip:5060 U opensips.ip:5060 - nat.ip:8427 Shouldn't it be going back to port 2370? And not 8427? -- James On Tue, Dec 7, 2010 at 2:43 AM, Bogdan-Andrei Iancu bog...@voice-system.ro wrote: Hi James, From proxy point of view, everything looks ok - I see the reply sent back to the exact IP:port where the request came fromSo the reply should make it through the NAT...But it seams it doesn't as the phone keeps retransmitting the REGISTER.. Again, from NAT pov, opensips is doing the right stuff (doing symmetric signalling) - there is nothing more you can do here for opensips..Maybe it is something specific to the NAT device - any possibility to debug/trace
[OpenSIPS-Users] Need some help with NAT/rtpproxy
Hi,
I'm having some issues getting a correct NAT configuration going.
The problem I'm having is
I get a 479 We don't forward to private IP addresses back when
receiving a call to a phone from Asterisk, presumably because the
location table has private IPs in it for some reason.
This seems to be related to my failed attempt to use fix_nated_register().
Removing the call to fix_nated_register and just using
fix_nated_contact allows calls to go through, but then I get no audio
on either side...
Config follows.
Thanks.
-- James
debug=3 # debug level (cmd line: -dd)
fork=yes
log_stderror=no # (cmd line: -E)
log_facility=LOG_LOCAL0
tos=0x60
# Uncomment these lines to enter debugging mode
#fork=no
#log_stderror=yes
#debug=6
check_via=no# (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=4
listen=udp:208.xxx.xxx.6:5060
listen=udp:208.xxx.xxx.6:5061
# -- module loading --
#set module path
#mpath=/usr/local/lib/opensips/modules/
mpath=/usr/local/lib64/opensips/modules/
# Uncomment this if you want to use SQL database
loadmodule db_mysql.so
loadmodule sl.so
loadmodule maxfwd.so
loadmodule textops.so
loadmodule avpops.so
loadmodule tm.so
loadmodule rr.so
loadmodule dialog.so
loadmodule signaling.so
loadmodule options.so
loadmodule localcache.so
loadmodule usrloc.so
loadmodule presence.so
loadmodule presence_xml.so
loadmodule presence_dialoginfo.so
loadmodule pua.so
loadmodule pua_dialoginfo.so
#loadmodule pua_bla.so
loadmodule pua_usrloc.so
loadmodule registrar.so
loadmodule mi_fifo.so
#loadmodule xlog.so
# Uncomment this if you want digest authentication
# db_mysql.so must be loaded !
loadmodule auth.so
loadmodule auth_db.so
# !! Nathelper
loadmodule nathelper.so
# - setting module-specific parameters ---
# -- mi_fifo params --
modparam(mi_fifo, fifo_name, /tmp/opensips_fifo)
modparam(usrloc, db_mode, 2)
modparam(usrloc|dialog|dispatcher|presence|presence_xml|pua|avpops,
db_url, mysql://opensips:xx...@localhost/opensips)
modparam(avpops,avp_table,usr_preferences)
#modparam(dispatcher, force_dst, 1)
# Only use username
#modparam(dispatcher, flags, 1)
# Store passwords for 1 hour in cache
modparam(auth,username_spec,$avp(i:54))
modparam(auth,password_spec,$avp(i:55))
modparam(auth,calculate_ha1,1)
modparam(auth_db, db_url,
mysql://opensipsro:x...@localhost/opensips)
modparam(auth_db, calculate_ha1, yes)
modparam(auth_db, password_column, password)
modparam(auth_db, load_credentials, $avp(i:55)=password)
modparam(rr, enable_full_lr, 1)
modparam(dialog, dlg_flag, 4)
modparam(dialog, profiles_with_value, caller)
modparam(usrloc,nat_bflag,6)
modparam(nathelper,sipping_bflag,8)
#modparam(nathelper, natping_interval, 30)
modparam(nathelper, ping_nated_only, 1) # Ping only clients behind NAT
#modparam(nathelper, natping_interval, 30)
modparam(nathelper, sipping_from, sip:pin...@208.xxx.xxx.6)
modparam(nathelper, rtpproxy_sock, unix:/var/run/rtpproxy/rtpproxy.sock)
modparam(nathelper, received_avp, $avp(i:42))
modparam(registrar, received_avp, $avp(i:42))
modparam(presence, server_address, sip:s...@208.xxx.xxx.6:5060)
modparam(presence, expires_offset, 10)
modparam(presence, mix_dialog_presence, 1)
#modparam(presence, fallback2db, 1)
modparam(presence_xml, force_active, 1)
modparam(presence_dialoginfo, force_single_dialog, 1)
modparam(pua_dialoginfo, presence_server, sip:s...@208.xxx.xxx.6:5060)
modparam(pua_dialoginfo, include_callid, 1)
modparam(pua_dialoginfo, include_tags, 1)
modparam(pua_dialoginfo, caller_confirmed, 1)
modparam(pua_usrloc, default_domain, 208.xxx.xxx.6)
modparam(pua_usrloc, presence_server, sip:s...@208.xxx.xxx.6:5060)
#modparam(stun,primary_ip,208.xxx.xxx.6)
#modparam(stun,alternate_ip,208.90.184.10)
#modparam(stun,primary_port,5060)
#modparam(stun,alternate_port,3479)
# - request routing logic ---
# main routing logic
route{
if (!is_method(NOTIFY))
xlog(L_INFO, New request - Request/failure/branch routes:
M=$rm
RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n);
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header(10)) {
sl_send_reply(483,Too Many Hops);
exit;
};
if (msg:len = 2048 ) {
sl_send_reply(513, Message too big);
exit;
};
# !! Nathelper
# Special handling for NATed clients; first, NAT test is
# executed: it looks for via!=received and RFC1918 addresses
# in Contact (may fail if line-folding is used); also,
# the received test should, if completed, should check all
# vias for rpesence of received
if (nat_uac_test(19)) {
# Allow RR-ed requests, as these may indicate that
# a NAT-enabled proxy takes care of it;
Re: [OpenSIPS-Users] Need some help with NAT/rtpproxy
Does anyone have a working example with fix_nated_register() that they
could post (or email me directly).
I'd really like to see how this is done properly.
Thanks.
-- James
On Mon, Dec 13, 2010 at 5:54 PM, James Lamanna jlama...@gmail.com wrote:
Some other weird stuff that happens if I remove the fix_nated_register call:
Sometimes everything will work fine, audio is fine, etc..
However, sometimes I'll call a phone, and the phone will immediately
place a call back out to the number I'm dialing from!
(very strange).
-- James
On Mon, Dec 13, 2010 at 5:28 PM, James Lamanna jlama...@gmail.com wrote:
Hi,
I'm having some issues getting a correct NAT configuration going.
The problem I'm having is
I get a 479 We don't forward to private IP addresses back when
receiving a call to a phone from Asterisk, presumably because the
location table has private IPs in it for some reason.
This seems to be related to my failed attempt to use fix_nated_register().
Removing the call to fix_nated_register and just using
fix_nated_contact allows calls to go through, but then I get no audio
on either side...
Config follows.
Thanks.
-- James
debug=3 # debug level (cmd line: -dd)
fork=yes
log_stderror=no # (cmd line: -E)
log_facility=LOG_LOCAL0
tos=0x60
# Uncomment these lines to enter debugging mode
#fork=no
#log_stderror=yes
#debug=6
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=4
listen=udp:208.xxx.xxx.6:5060
listen=udp:208.xxx.xxx.6:5061
# -- module loading --
#set module path
#mpath=/usr/local/lib/opensips/modules/
mpath=/usr/local/lib64/opensips/modules/
# Uncomment this if you want to use SQL database
loadmodule db_mysql.so
loadmodule sl.so
loadmodule maxfwd.so
loadmodule textops.so
loadmodule avpops.so
loadmodule tm.so
loadmodule rr.so
loadmodule dialog.so
loadmodule signaling.so
loadmodule options.so
loadmodule localcache.so
loadmodule usrloc.so
loadmodule presence.so
loadmodule presence_xml.so
loadmodule presence_dialoginfo.so
loadmodule pua.so
loadmodule pua_dialoginfo.so
#loadmodule pua_bla.so
loadmodule pua_usrloc.so
loadmodule registrar.so
loadmodule mi_fifo.so
#loadmodule xlog.so
# Uncomment this if you want digest authentication
# db_mysql.so must be loaded !
loadmodule auth.so
loadmodule auth_db.so
# !! Nathelper
loadmodule nathelper.so
# - setting module-specific parameters ---
# -- mi_fifo params --
modparam(mi_fifo, fifo_name, /tmp/opensips_fifo)
modparam(usrloc, db_mode, 2)
modparam(usrloc|dialog|dispatcher|presence|presence_xml|pua|avpops,
db_url, mysql://opensips:xx...@localhost/opensips)
modparam(avpops,avp_table,usr_preferences)
#modparam(dispatcher, force_dst, 1)
# Only use username
#modparam(dispatcher, flags, 1)
# Store passwords for 1 hour in cache
modparam(auth,username_spec,$avp(i:54))
modparam(auth,password_spec,$avp(i:55))
modparam(auth,calculate_ha1,1)
modparam(auth_db, db_url,
mysql://opensipsro:x...@localhost/opensips)
modparam(auth_db, calculate_ha1, yes)
modparam(auth_db, password_column, password)
modparam(auth_db, load_credentials, $avp(i:55)=password)
modparam(rr, enable_full_lr, 1)
modparam(dialog, dlg_flag, 4)
modparam(dialog, profiles_with_value, caller)
modparam(usrloc,nat_bflag,6)
modparam(nathelper,sipping_bflag,8)
#modparam(nathelper, natping_interval, 30)
modparam(nathelper, ping_nated_only, 1) # Ping only clients behind NAT
#modparam(nathelper, natping_interval, 30)
modparam(nathelper, sipping_from, sip:pin...@208.xxx.xxx.6)
modparam(nathelper, rtpproxy_sock,
unix:/var/run/rtpproxy/rtpproxy.sock)
modparam(nathelper, received_avp, $avp(i:42))
modparam(registrar, received_avp, $avp(i:42))
modparam(presence, server_address, sip:s...@208.xxx.xxx.6:5060)
modparam(presence, expires_offset, 10)
modparam(presence, mix_dialog_presence, 1)
#modparam(presence, fallback2db, 1)
modparam(presence_xml, force_active, 1)
modparam(presence_dialoginfo, force_single_dialog, 1)
modparam(pua_dialoginfo, presence_server, sip:s...@208.xxx.xxx.6:5060)
modparam(pua_dialoginfo, include_callid, 1)
modparam(pua_dialoginfo, include_tags, 1)
modparam(pua_dialoginfo, caller_confirmed, 1)
modparam(pua_usrloc, default_domain, 208.xxx.xxx.6)
modparam(pua_usrloc, presence_server, sip:s...@208.xxx.xxx.6:5060)
#modparam(stun,primary_ip,208.xxx.xxx.6)
#modparam(stun,alternate_ip,208.90.184.10)
#modparam(stun,primary_port,5060)
#modparam(stun,alternate_port,3479)
# - request routing logic ---
# main routing logic
route{
if (!is_method(NOTIFY))
xlog(L_INFO, New request - Request/failure/branch routes:
M=$rm
RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n);
# max_forwards==0, or excessively long requests
[OpenSIPS-Users] Shared DB tables among several opensips instances
Hi, Is it possible to share the same DB tables among several running OpenSIPs instances? What I'm trying to do is use OpenSIPs as a registration front-end to Asterisk. The idea is to have a cluster of registration servers, and then a cluster of Asterisk servers. Can an Asterisk server pass a call to any of the OpenSIPs servers in the cluster, and have opensips deliver the call even if the phone isn't directly registered to that particular server? Or does the call always have to be passed to the opensips instance that the phone is directly registered to, even if there is a shared DB? Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Example config for NATed UACs, RTPproxy, and NATed OpenSIPS (version 1.6.4)
Bogdan,
Wow, I didn't know about the live DVD.
Any chance someone could create this as an OpenVZ container in
addition to VMWare?
-- James
On Mon, Jan 10, 2011 at 2:25 AM, Bogdan-Andrei Iancu
bog...@voice-system.ro wrote:
Hi Damon,
Well, the answer is simple - download the opensips virtual machine
(http://www.voice-system.ro/shortcuts::opensips_livedvd) were you have a
ready to run opensips platform with NAT traversal support - you can see in
the script form the VM how the NAT traversal is done (for signalling and
media).
If you have questions on that, please come back here.
Regards,
Bogdan
Damon Miller wrote:
All,
I've seen many requests for an example working config that shows a working
RTPproxy configuration with NATed clients, but I haven't seen many
responses. I recently spent an absurd amount of time getting a working
configuration in place so I thought I would post it here in case it's
helpful to anyone.
Three quick points:
1. I have only tested this with clients behind a NAT firewall, i.e. I
haven't tested with clients that have a public IP.
2. My OpenSIPS server is behind a NAT firewall itself. To deal with
this, I added the two advertised options, as follows:
advertised_address=xx.xx.xx.xx
alias=xx.xx.xx.xx:5060
(Replace the xx.xx.xx.xx with the NAT firewall's public IP.)
I also had to use a modified version of RTPproxy that presents the
firewall's public IP even though it binds to a private IP. Here's a post
which summarizes that version of RTPproxy:
http://opensips-open-sip-server.1449251.n2.nabble.com/Rtpproxy-behind-the-NAT-td5008041.html
I run RTPproxy like this:
rtpproxy -A xx.xx.xx.xx -l 192.168.20.154 -s udp:127.0.0.1:12221 -m 25000
-M 65000 -F -d DBUG:LOCAL1
3. I had to tell OpenSIPS that my firewall's public IP was one of its
local domains. I'm using MySQL as you'll see in the config file so all I
had to do was insert a value into the 'domain' table. That was pretty
obvious, i.e.:
mysql insert into domain (domain) values (xx.xx.xx.xx);
(Replace 'xx.xx.xx.xx' with your public IP.)
Here's my 'opensips.cfg' file:
--
# --- global configuration parameters
debug=3
fork=yes
log_facility=LOG_LOCAL0
log_stderror=no
children=4
port=5060
dns=no
rev_dns=no
advertised_address=xx.xx.xx.xx
alias=xx.xx.xx.xx:5060
# -- module loading --
mpath=/usr/local/lib64/opensips/modules/
loadmodule db_mysql.so
loadmodule signaling.so
loadmodule sl.so
loadmodule tm.so
loadmodule rr.so
loadmodule maxfwd.so
loadmodule usrloc.so
loadmodule registrar.so
loadmodule textops.so
loadmodule mi_fifo.so
loadmodule uri.so
loadmodule nathelper.so
loadmodule domain.so
# - setting module-specific parameters ---
modparam(mi_fifo, fifo_name, /tmp/opensips_fifo)
modparam(usrloc, db_url,
mysql://opensipsrw:opensip...@localhost/opensips)
modparam(usrloc, db_mode, 2)
modparam(rr, enable_full_lr, 1)
modparam(nathelper, rtpproxy_sock, udp:127.0.0.1:12221)
modparam(nathelper, nortpproxy_str, )
modparam(domain, db_url,
mysql://opensipsrw:opensip...@localhost/opensips)
## NAT ##
modparam(usrloc, nat_bflag, 6)
modparam(nathelper, ping_nated_only, 1)
modparam(nathelper, sipping_bflag, 8)
modparam(nathelper, received_avp, $avp(i:801))
## NAT ##
# main routing logic
route {
# initial sanity checks
if (!mf_process_maxfwd_header(10)) {
sl_send_reply(483,Too Many Hops);
exit;
};
if (msg:len = 2048 ) {
sl_send_reply(513, Message too big);
exit;
};
## NAT ##
if (nat_uac_test(3)) {
if (is_method(REGISTER) !is_present_hf(Record-Route)) {
# Rewrite contact with source IP of signalling
fix_nated_contact();
force_rport();
setbflag(6); # Mark as NATed
# if you want SIP NAT pinging
setbflag(8);
};
};
## NAT ##
if (!method==REGISTER)
record_route();
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
# mark routing logic in request
append_hf(P-hint: rr-enforced\r\n);
route(1);
};
if (!uri==myself) {
# mark routing logic in request
append_hf(P-hint: outbound\r\n);
route(1);
};
if (uri==myself) {
if (method==REGISTER) {
save(location);
exit;
};
}
if (is_method(BYE))
unforce_rtp_proxy();
if (!lookup(location,m)) {
switch ($retcode) {
case -1:
case -3:
t_newtran();
t_on_failure(1);
t_reply(404, Not Found);
exit;
[OpenSIPS-Users] DND and presence
Hi, I'm trying to move to OpenSIPS as being the registrar front end for cluster of Asterisk boxes. One of the services we currently offer is DND w/ BLF. I'm trying to figure out how to implement this with OpenSIPS. From what I've read, DND can be implemented through ACLs, correct? However, is there any way to tie this into the presence module? Asterisk has a notion of 'hints' where you can say, set the value of hint *761234567890, and then a phone can subscribe to that hint see the BLF. Is there any way to do this in OpenSIPS presence? And another question on presence, is it possible, if I have 2 OpenSIPS servers that share a presence database, for client A on server 1 to subscribe to the presence of client B registered on server 2 by just subscribing to clientB@ServerA? (clientA doesn't know what server clientB might be registered on). Or do I have to add logic to rewrite the To header so that it subscribes to clientB@ServerB (which also implies a shared location db). Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] DND and presence
Hi Anca, On Fri, Jan 14, 2011 at 6:19 AM, Anca Vamanu a...@opensips.org wrote: Hi James, On 01/13/2011 06:43 PM, James Lamanna wrote: Hi, I'm trying to move to OpenSIPS as being the registrar front end for cluster of Asterisk boxes. One of the services we currently offer is DND w/ BLF. I'm trying to figure out how to implement this with OpenSIPS. From what I've read, DND can be implemented through ACLs, correct? However, is there any way to tie this into the presence module? Asterisk has a notion of 'hints' where you can say, set the value of hint *761234567890, and then a phone can subscribe to that hint see the BLF. Is there any way to do this in OpenSIPS presence? As Dani said, there is no way to correlate presence status with call permissions. A BLF functionality is present in opensips - see http://www.opensips.org/Resources/PuaExtensions#pua_dialoginfo. It permits subscriptions to the dialog state of a line. So from what you are saying, there isn't a way from an opensips config to add a presence entry based on call permissions? So there's no way to for a phone to subscribe to the DND state of another line? The phone wouldn't be subscribing to the extension, but a prefixed extension (like *762005551212). If there's no way to do this, then that is unfortunate, because that means DND handling will have to be pushed out to Asterisk because this is one of the features we provide to our users, being able to subscribe to DND state. Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Two Opensips proxies sharing the same DB
Hi Jeff Bogdan, I'm looking into a setup very similar to this as well, essentially I want to have a cluster of OpenSIPS servers for registration and then a cluster of Asterisk Boxes for all the dialplan handling. I have the unfortunate problem that all of my clients are going to be behind NAT. My main issue I think is going to be dealing with NAT, and I'm looking for any ideas here. My initial idea is this: - Identify an OpenSIPS server as a relay between Asterisk Servers and the OpenSIPS Servers. - On an incoming call from PSTN/Asterisk, divert the call to the relay to lookup which OpenSIPS server the callee is registered on. - Redirect the INVITE to this OpenSIPS server, so that the call can be send back appropriately through NAT. That seems reasonable, however, what's the best way to lookup the socket column to determine which server the callee is registed on? (or is there another way) Thanks. -- James 2011/1/20 Jeff Pyle jp...@fidelityvoice.com: Bogdan, I think I've got it now. Details inline. On 1/20/11 3:44 PM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Jeff Pyle wrote: We're looking to add a second Opensips instance on a separate server for failover. Or, from an operational perspective, it could be described as active-active since both will be available at any one time. We'll control the traffic flow to the proxies with the SRV records used by the clients. Looking through the db tables used, it seems there may be some conflict with the location and dialog tables. The usrloc module clearly saves the local socket used during the registration. Is there a way to tell Opensips 1.6 to ignore this when loading the record? socket;s are discarded at load time if not local. I run db_mode=3 to keep everything current in the db. The performance is acceptable (MySQL cluster helps). If I understand you correctly: on a shared table, if I save() a registration on Proxy A, but then load() it into Proxy B, Proxy B will ignore it since the socket is non-local. the socket is ignored, not the record - the record will be used, but the socket info discarded Ah ha! So it will work on a shared table, and the default socket of Proxy B will be used in the scenario I described. Excellent. Any way to work around that within Opensips itself? If I ran separate location tables on each, I might be able to work something up with MySQL triggers to push a saved registration from one table to the other at save()-time, changing the socket field as it goes. That's a bit more hackery than I was hoping to have to implement. That way, either proxy can use records saved by either proxy. A force socket option perhaps to the local IP? Clients are all public IPs no NAT. depends on what db_mode you use for usrloc - if you use a DB mode involving caching, the DB is read only at startup (otherwise, at runtime, it is just written), so data will not be shared at all. Of course you completely disable the usrloc caching via DB_ONLY db_mode, but the performance penalty is high - maybe you should consider register replication at SIP level. Replication at the SIP level. That is, have the SIP client register with both proxies at once? yes. UAC registers with P1 and P1 replicates to P2 (see the t_replicate() function in TM module). But again, this makes sense only if using cache for usrloc Indeed. I see now. Thanks. - Jeff Regards, Bogdan -- Bogdan-Andrei Iancu OpenSIPS Event - expo, conf, social, bootcamp 2 - 4 February 2011, ITExpo, Miami, USA OpenSIPS solutions and know-how ___ 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Distributing Presence
I should probably re-title this Using Multiple Presence Servers with NAT. What I want my setup to be is a cluster of opensips instances where any phone can register to any server and also be able to subscribe to the presence of any other phone. What complicates this is that all the phones are behind NAT. The idea here is to create a registration/presence cluster where any node can be taken offline at any time, and phones using that node can re-register to the other available nodes. I've attempted to use presence in fallback2db mode, but I don't seem to be having much success. Currently the presence DB is being shared across 2 instances, but dialog SUBSCRIBE requests are not being inserted into active_watchers (or they are and are being removed). My initial thought was to not use fallback2db but propagate PUBLISH events to all the nodes in the cluster so that the node that each phone is registered to manages its subscriptions and sends out the appropriate NOTIFYs, since all phone are behind NAT. For various reasons, PUBLISH events don't seem to be able to be propagated between servers (E_tag problems). If anyone has any other ideas on how to make this work, it would be much appreciated. Presence/BLF for my phones works great when everything is on the same opensips instance, but my goal here is not to have single instances managing a specific group of phones. Thanks. -- James On Sun, Jan 30, 2011 at 10:11 AM, James Lamanna jlama...@gmail.com wrote: Hi, I'm trying to create an opensips registration cluster that also supports distributed presence. The idea is that a UA can register to any server and subscribe to another UA that may be registered at a different server, along with making calls to them, etc.. I already have REGISTER duplication working through the use of the path module and t_replicate. However, I noticed I cannot use the same approach with PUBLISH messages generated by pua_dialoginfo and pua_usrloc. The remote server that I replicate to always has the error of No E_Tag match when calling handle_publish(). Is there any way to replicate PUBLISH Presence and Dialog events out to other opensips instances? Or do I need to use shared database tables (and db_mode 3). Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Two Opensips proxies sharing the same DB
Hi Hank, Soon after I wrote that email I discovered the path module and t_replicate to replicate the REGISTERs with path information to all of the nodes in my cluster. Which allows a call to come in from the PSTN to _any_ node and be routed appropriately. Now my next issue is presence handling (which I just wrote a couple emails about to the list), which I hope I can get working. -- James On Sat, Jan 29, 2011 at 8:50 PM, Henk Hesselink opensips-us...@voipro.nl wrote: Hi James, You might want to look at the nat_traversal module plus the path module. Run nat_traversal on your customer-facing boxes, it will take care of NAT including all sorts of corner cases. Pass REGISTER requests to your internal registrar servers after calling add_path/add_path_received. On the registrar do save(p0v) and subsequent lookups on any of the registrars will automatically go to the right NAT box. Regards, Henk On 29-01-11 22:13, James Lamanna wrote: Hi Jeff Bogdan, I'm looking into a setup very similar to this as well, essentially I want to have a cluster of OpenSIPS servers for registration and then a cluster of Asterisk Boxes for all the dialplan handling. I have the unfortunate problem that all of my clients are going to be behind NAT. My main issue I think is going to be dealing with NAT, and I'm looking for any ideas here. My initial idea is this: - Identify an OpenSIPS server as a relay between Asterisk Servers and the OpenSIPS Servers. - On an incoming call from PSTN/Asterisk, divert the call to the relay to lookup which OpenSIPS server the callee is registered on. - Redirect the INVITE to this OpenSIPS server, so that the call can be send back appropriately through NAT. That seems reasonable, however, what's the best way to lookup the socket column to determine which server the callee is registed on? (or is there another way) Thanks. -- James 2011/1/20 Jeff Pylejp...@fidelityvoice.com: Bogdan, I think I've got it now. Details inline. On 1/20/11 3:44 PM, Bogdan-Andrei Iancubog...@opensips.org wrote: Jeff Pyle wrote: We're looking to add a second Opensips instance on a separate server for failover. Or, from an operational perspective, it could be described as active-active since both will be available at any one time. We'll control the traffic flow to the proxies with the SRV records used by the clients. Looking through the db tables used, it seems there may be some conflict with the location and dialog tables. The usrloc module clearly saves the local socket used during the registration. Is there a way to tell Opensips 1.6 to ignore this when loading the record? socket;s are discarded at load time if not local. I run db_mode=3 to keep everything current in the db. The performance is acceptable (MySQL cluster helps). If I understand you correctly: on a shared table, if I save() a registration on Proxy A, but then load() it into Proxy B, Proxy B will ignore it since the socket is non-local. the socket is ignored, not the record - the record will be used, but the socket info discarded Ah ha! So it will work on a shared table, and the default socket of Proxy B will be used in the scenario I described. Excellent. Any way to work around that within Opensips itself? If I ran separate location tables on each, I might be able to work something up with MySQL triggers to push a saved registration from one table to the other at save()-time, changing the socket field as it goes. That's a bit more hackery than I was hoping to have to implement. That way, either proxy can use records saved by either proxy. A force socket option perhaps to the local IP? Clients are all public IPs no NAT. depends on what db_mode you use for usrloc - if you use a DB mode involving caching, the DB is read only at startup (otherwise, at runtime, it is just written), so data will not be shared at all. Of course you completely disable the usrloc caching via DB_ONLY db_mode, but the performance penalty is high - maybe you should consider register replication at SIP level. Replication at the SIP level. That is, have the SIP client register with both proxies at once? yes. UAC registers with P1 and P1 replicates to P2 (see the t_replicate() function in TM module). But again, this makes sense only if using cache for usrloc Indeed. I see now. Thanks. - Jeff Regards, Bogdan -- Bogdan-Andrei Iancu OpenSIPS Event - expo, conf, social, bootcamp 2 - 4 February 2011, ITExpo, Miami, USA OpenSIPS solutions and know-how ___ 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 ___ Users mailing list Users@lists.opensips.org http
[OpenSIPS-Users] Redirecting REGISTER requests to another proxy
Hi, I'm trying to redirect a REGISTER request to a different proxy, mostly for load balancing purposes. The UAC is behind NAT, so in order to properly communicate directly with the next proxy, the UAC must send a new REGISTER request to the new proxy. I've tried sending back a 302 Moved Temporarily or 305 Use Proxy response, but the UAC I'm using (SJPhone) doesn't seem to respond favorably to either. Is there another approach I should take? Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Redirecting REGISTER requests to another proxy
Hi Bogdan, The UAC - P1 - P2 scenario was something I was hoping to avoid because it puts a reliance on P1 being up, even though its really not needed. I've been trying to play with DNS SRV, and returning some sort of failure code so that a UAC would at least move to the next server with the same priority, but alas it doesn't appear that DNS SRV is a well implemented thing in UACs. Thanks. -- James On Fri, Feb 4, 2011 at 5:18 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi James, it is a know issue that most of UAC do not properly implement 3xx for REGISTER requests... Talk to pjsip guys, they are really good and fast in fixing their stack. About other solutionscomplicated ones...If P1 receives the REGISTERs it needs to deal with the NAT issues and act as a mid registering for P2, the real register server. Like UAC registers via NAT to P1 and P1 registers to P2. You can do this by playing with the contact when forwarding the REGISTER from P1 to P2. Regards, Bogdan James Lamanna wrote: Hi, I'm trying to redirect a REGISTER request to a different proxy, mostly for load balancing purposes. The UAC is behind NAT, so in order to properly communicate directly with the next proxy, the UAC must send a new REGISTER request to the new proxy. I've tried sending back a 302 Moved Temporarily or 305 Use Proxy response, but the UAC I'm using (SJPhone) doesn't seem to respond favorably to either. Is there another approach I should take? Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Event - expo, conf, social, bootcamp 2 - 4 February 2011, ITExpo, Miami, USA OpenSIPS solutions and know-how ___ 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] BUG in nathelper - can miss contacts to ping
Hi,
I've been investigating a problem where I was noticing that nathelper
was not pinging all the contacts it should be pinging.
I've narrowed down the problem to this code in nh_timer() in nathelper.c:
rval = ul.get_all_ucontacts(buf, cblen, (ping_nated_only?ul.nat_flag:0),
((unsigned int)(unsigned long)timer_idx)*natping_interval+iteration,
natping_processes*natping_interval);
if (rval0) {
LM_ERR(failed to fetch contacts\n);
goto done;
}
if (rval 0) {
if (buf != NULL)
pkg_free(buf);
cblen = rval * 2;
buf = pkg_malloc(cblen);
if (buf == NULL) {
LM_ERR(out of pkg memory\n);
goto done;
}
rval = ul.get_all_ucontacts(buf,cblen,(ping_nated_only?ul.nat_flag:0),
((unsigned int)(unsigned long)timer_idx)*natping_interval+iteration,
natping_processes*natping_interval);
if (rval != 0) {
pkg_free(buf);
goto done;
}
}
The problem here is if the first call to ul.get_all_ucontacts fails
for insufficent buffer size
(such as if it returns more than 1 contact), the second call
multiplies the shortage by 2 and then tries it!
This results in the second buffer actually being smaller than the
first in many cases, which causes the
contacts in that call to be skipped due to insufficient buffer size again...
I would propose that the second call actually allocates the correct
amount of memory like this patch:
Index: modules/nathelper/nathelper.c
===
--- modules/nathelper/nathelper.c (revision 7939)
+++ modules/nathelper/nathelper.c (working copy)
@@ -1130,7 +1130,7 @@
if (rval 0) {
if (buf != NULL)
pkg_free(buf);
- cblen = rval * 2;
+ cblen += rval;
buf = pkg_malloc(cblen);
if (buf == NULL) {
LM_ERR(out of pkg memory\n);
This problem looks like it has been around a long time, so if you use
NATed contacts, and have had issues
with firewalls closing connections on you, you should apply this patch
to see if your problem is fixed.
Thanks.
-- James
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Nathelper ping does not consistently ping all contacts
Hi, I've noticed after a period of time, Nathelper will stop sending pings to some contacts. I've verified that the contact is still registered (it is even in the location table) but the ping process appears to skip some contacts for unknown reasons. Could someone please look into this? I have phones behind NAT that stop being able to receive calls because firewalls close down the UDP mapping since this feature is not working properly. Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Nathelper ping does not consistently ping all contacts
Hi Bogdan,
I've been monitoring it (I wrote myself a script that checks the AORs
in memory against syslog).
I haven't seen any issues lately.
The trailing garbage is weird as well. In the DB, the contacts look ok.
I haven't tracked down where that is coming from yet.
-- James
On Fri, Jul 8, 2011 at 8:42 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote:
Hi James,
thanks a lot for the feedback.
The log you added does not show anything wrong - the path fields may be
missing and the so called contact part (returned by usrloc) is either the
received URI (if present), either the contact URI (if not received URI).
What looks scary are the trailing chars for the URIbut the question is
if the bogus contact happens because it get bogus when returned by usrloc
(by get_all_mem_contacts) function or because the received URI was bogusly
saved in ursloc from the beginning via the fix_nated_registered() function
Regards,
Bogdan
On 07/01/2011 05:58 PM, James Lamanna wrote:
Hi Bogdan,
Unfortunately I've found that it doesn't fix the entire problem.
I have a contact now that is online, that still isn't getting pinged for
some reason.
I think there's something subtle in get_all_mem_contacts in dlist.c.
I haven't tried to see if this problem still manifests itself if the usrloc
mode is DBONLY (its a production server).
But as an example, I have this contact online (from opensipsctl ul show):
AOR:: 22505
Contact:: sip:22505@192.168.1.117:7945 Q=
Expires:: 1401
Callid:: c3bfd2f5-50aff633@192.168.1.117
Cseq:: 63708
User-agent:: Linksys/SPA962-6.1.3(a)-000e08d21b47
Received:: sip:x.x.x.x.:1024
State:: CS_SYNC
Flags:: 0
Cflag:: 192
Socket:: udp:opensips.ip:5060
Methods:: 5183
I've added a print in nathelper.c:
@@ -3648,8 +3650,11 @@
continue;
}
}
- if (curi.proto != PROTO_UDP curi.proto != PROTO_NONE)
+ LM_INFO(pinging contact: %*s %*s\n, path.len, path.s, c.len, c.s);
+ if (curi.proto != PROTO_UDP curi.proto != PROTO_NONE) {
+ LM_ERR(dumping contact: %*s %*s\n, path.len, path.s, c.len, c.s);
continue;
+ }
if (curi.port_no == 0)
curi.port_no = SIP_PORT;
proto = curi.proto;
I see these prints for a while for this contact:
Jun 30 12:30:53 frontend1 /usr/local/sbin/opensips[7087]:
INFO:nathelper:nh_timer: pinging contact: (null) sip:208.90.185.166:7945??z
And then it just stops.
Restarting Opensips doesn't bring it back either.
unfortunately I haven't had time to digest the code in dlist.c to figure out
what is actually going on in there with the 2 indices.
Thanks.
-- James
On Fri, Jul 1, 2011 at 7:29 AM, Bogdan-Andrei Iancu bog...@opensips.org
wrote:
Hi Andrew,
Thanks God for mentioning this - the initial report from James missed me,
and I was not aware of the bug and the fix - I just fixed it right now on
the SVN trunk and 1.6
Thanks and regards,
Bogdan
On 07/01/2011 06:45 AM, Andrew Pogrebennyk wrote:
James,
On 01.07.2011 06:42, James Lamanna wrote:
Hi,
I've noticed after a period of time, Nathelper will stop sending pings
to some contacts.
I've verified that the contact is still registered (it is even in the
location table) but the ping process appears to skip some contacts for
unknown reasons.
maybe see if this fixes the problem for you:
http://www.mail-archive.com/users@lists.opensips.org/msg16200.html
?
Could someone please look into this? I have phones behind NAT that stop
being able to receive calls because firewalls close down the UDP mapping
since this feature is not working properly.
--
Bogdan-Andrei Iancu
OpenSIPS solutions and know-how
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and know-how
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Nathelper ping does not consistently ping all contacts
Bogdan,
I'm really not sure where that garbage is coming from.
It almost seems like some weird artifact from printing to syslog..
I had it print out the length, and I see lines like this:
pinging contact: sip:208.xx.xxx.130:7538??z len: 23
sip:208.xx.xxx.130:7538 is 23 characters long, so the '??z'
shouldn't be printed...
-- James
On Fri, Jul 8, 2011 at 6:12 PM, James Lamanna jlama...@gmail.com wrote:
Hi Bogdan,
I've been monitoring it (I wrote myself a script that checks the AORs
in memory against syslog).
I haven't seen any issues lately.
The trailing garbage is weird as well. In the DB, the contacts look ok.
I haven't tracked down where that is coming from yet.
-- James
On Fri, Jul 8, 2011 at 8:42 AM, Bogdan-Andrei Iancu bog...@opensips.org
wrote:
Hi James,
thanks a lot for the feedback.
The log you added does not show anything wrong - the path fields may be
missing and the so called contact part (returned by usrloc) is either the
received URI (if present), either the contact URI (if not received URI).
What looks scary are the trailing chars for the URIbut the question is
if the bogus contact happens because it get bogus when returned by usrloc
(by get_all_mem_contacts) function or because the received URI was bogusly
saved in ursloc from the beginning via the fix_nated_registered() function
Regards,
Bogdan
On 07/01/2011 05:58 PM, James Lamanna wrote:
Hi Bogdan,
Unfortunately I've found that it doesn't fix the entire problem.
I have a contact now that is online, that still isn't getting pinged for
some reason.
I think there's something subtle in get_all_mem_contacts in dlist.c.
I haven't tried to see if this problem still manifests itself if the usrloc
mode is DBONLY (its a production server).
But as an example, I have this contact online (from opensipsctl ul show):
AOR:: 22505
Contact:: sip:22505@192.168.1.117:7945 Q=
Expires:: 1401
Callid:: c3bfd2f5-50aff633@192.168.1.117
Cseq:: 63708
User-agent:: Linksys/SPA962-6.1.3(a)-000e08d21b47
Received:: sip:x.x.x.x.:1024
State:: CS_SYNC
Flags:: 0
Cflag:: 192
Socket:: udp:opensips.ip:5060
Methods:: 5183
I've added a print in nathelper.c:
@@ -3648,8 +3650,11 @@
continue;
}
}
- if (curi.proto != PROTO_UDP curi.proto != PROTO_NONE)
+ LM_INFO(pinging contact: %*s %*s\n, path.len, path.s, c.len, c.s);
+ if (curi.proto != PROTO_UDP curi.proto != PROTO_NONE) {
+ LM_ERR(dumping contact: %*s %*s\n, path.len, path.s, c.len, c.s);
continue;
+ }
if (curi.port_no == 0)
curi.port_no = SIP_PORT;
proto = curi.proto;
I see these prints for a while for this contact:
Jun 30 12:30:53 frontend1 /usr/local/sbin/opensips[7087]:
INFO:nathelper:nh_timer: pinging contact: (null) sip:208.90.185.166:7945??z
And then it just stops.
Restarting Opensips doesn't bring it back either.
unfortunately I haven't had time to digest the code in dlist.c to figure out
what is actually going on in there with the 2 indices.
Thanks.
-- James
On Fri, Jul 1, 2011 at 7:29 AM, Bogdan-Andrei Iancu bog...@opensips.org
wrote:
Hi Andrew,
Thanks God for mentioning this - the initial report from James missed me,
and I was not aware of the bug and the fix - I just fixed it right now on
the SVN trunk and 1.6
Thanks and regards,
Bogdan
On 07/01/2011 06:45 AM, Andrew Pogrebennyk wrote:
James,
On 01.07.2011 06:42, James Lamanna wrote:
Hi,
I've noticed after a period of time, Nathelper will stop sending pings
to some contacts.
I've verified that the contact is still registered (it is even in the
location table) but the ping process appears to skip some contacts for
unknown reasons.
maybe see if this fixes the problem for you:
http://www.mail-archive.com/users@lists.opensips.org/msg16200.html
?
Could someone please look into this? I have phones behind NAT that stop
being able to receive calls because firewalls close down the UDP mapping
since this feature is not working properly.
--
Bogdan-Andrei Iancu
OpenSIPS solutions and know-how
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and know-how
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] BLF problems with Snom 821
Does anyone have experience getting BLF working properly with a Snom 821? I'm using 1.6.4 and BLF works great with Linksys/Cisco phones, but with Snom 821s I have the problem where the light will stay on, even after the monitored extension has hung up. BLF to the Snom works properly when getting BLF directly from Asterisk. I've posted on the Snom forums about this, but I was wondering if anyone had any more insight. Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] BLF state hanging with Polycom 550
Hi Anca, Unfortunately, that doesn't seem to have corrected the problem. Anything else I might try? Thanks. -- James On Sun, Jul 24, 2011 at 11:57 PM, Anca Vamanu anca.vam...@gmail.com wrote: Hi James, Try setting bla_fix_remote_target parameter to 0 : http://www.opensips.org/html/docs/modules/1.6.x/presence.html#id248928 Regards, Anca Vamanu On Mon, Jul 25, 2011 at 12:52 AM, James Lamanna jlama...@gmail.com wrote: Hi, I'm trying to get BLF working on a Polycom 550 with Opensips 1.6.4 and I find that the BLF light never shuts off when the monitored user hangs up. If you look at the NOTIFYs below, the 2nd one has a different host in the identity tags. xxx.xxx.xxx.7 is the address of the Asterisk PBX 3475 is using to make the call. Could this be the issue? Thanks. -- James Here are 2 NOTIFYs that get sent to the phone: NOTIFY sip:3...@my.ip:5061 SIP/2.0.. Via: SIP/2.0/UDP 208.90.184.11;branch=z9hG4bKfd0f.9b2911c3.0.. To: sip:3466@registrar;tag=6B85955A-87D7D107.. From sip:3475@registrar;tag=a76b7752a9a4c30bb313545e6969938d-4ac6.. CSeq: 12 NOTIFY.. Call-ID: 54fea721-a9bb8f8a-9309f5f7@192.168.1.105.. Content-Length: 610.. User-Agent: OpenSIPS (1.6.4-2-notls (x86_64/linux)).. Max-Forwards: 70.. Event: dialog.. Contact: sip:@xxx.xxx.xxx.11:5060.. Subscription-State: active;expires=3572.. Content-Type: application/dialog-info+xml ?xml version=1.0?. dialog-info xmlns=urn:ietf:params:xml:ns:dialog-info version=11 state=partial entity=3475@registrar dialog id=E444B00A-1DD1-11B2-91A6-FBB370DC369E@192.168.1.136 call-id=E444B00A-1DD1-11B2-91A6-FBB370DC369E@192.168.1.136 direction=initiator stateconfirmed/state remoteidentitysip:3425@registrar/identitytarget uri=sip:3425@registrar//remote localidentitysip:3475@registrar/identitytarget uri=sip:3...@registrar.warp2biz.com//local/dialog/dialog-info. NOTIFY sip:3...@my.ip:5061 SIP/2.0.. Via: SIP/2.0/UDP xxx.xxx.xxx.11;branch=z9hG4bK0e0f.81b81c53.0.. To: sip:3466@registrar;tag=6B85955A-87D7D107.. From: sip:3475@registrar;tag=a76b7752a9a4c30bb313545e6969938d-4ac6.. CSeq: 13 NOTIFY.. Call-ID: 54fea721-a9bb8f8a-9309f5f7@192.168.1.105.. Content-Length: 569.. User-Agent: OpenSIPS (1.6.4-2-notls (x86_64/linux)).. Max-Forwards: 70.. Event: dialog.. Contact: sip:@xxx.xxx.xxx.11:5060.. Subscription-State: active;expires=3568.. Content-Type: application/dialog-info+xml ?xml version=1.0?.dialog-info xmlns=urn:ietf:params:xml:ns:dialog-info version=12 state=partial entity=3475@registrar dialog id=49eeed6563b56fc3011d024d4690a...@xxx.xxx.xxx.7 call-id=49eeed6563b56fc3011d024d4690a...@xxx.xxx.xxx.7 direction=recipient stateterminated/state remoteidentitysip:3...@xxx.xxx.xxx.7/identity target uri=sip:3...@xxx.xxx.xxx.7//remote localidentitysip3...@xxx.xxx.xxx.7:6060/identity target uri=sip:3...@xxx.xxx.xxx.7:6060//local/dialog/dialog-info. ___ 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Problems with SUBSCRIBES from Cisco firmware 7.4.8
Hi everyone, I've noticed that I'm having issues with successive subscribes from Cisco phones with firmware 7.4.8. Here's a SIP trace of a 2nd subscribe (when the first one is about to expire) SUBSCRIBE sip:regdev:5060 SIP/2.0..Via: SIP/2.0/UDP 192.168.2.3:7813;branch=z9hG4bK-9160ffcb..From: 3471 sip:3471@regdev;tag=4e466ee09b66a0fc..To: sip:3473@regdev ;tag=dcf33b41ac7355dd2e87df2f605abeb8-120c..Call-ID: f7e53a3b-adddc...@192.168.2.3..cseq: 1002 SUBSCRIBE..Max-Fo rwards: 70..Contact: 3471 sip:3471@192.168.2.3:7813..Accept: application/dialog-info+xml..Expir es: 60..Event: dialog..User-Agent: Cisco/SPA509G-7.4.8a..Content-Length: 0 SIP/2.0 200 OK..Via: SIP/2.0/UDP 192.168.2.3:7813;branch=z9hG4bK-9160ffcb;rport=7813;received=xx.xx.xx.xx..From: 3471 sip:3471@regdev;tag=4e466ee09b66a0fc..To: sip:3473@regdev;tag=dcf33b41ac7355dd2e87df2f605abeb8-120c.. Call-ID: f7e53a3b-adddc...@192.168.2.3..cseq: 1002 SUBSCRIBE..Expir es: 60..Contact: sip:regdev:5060..Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))..Content-Length: 0 Even though it returns OK, the active_watchers table now no longer has the subscription in it. Also, when sending this SUBSCRIBE to another opensips instance, I get a 481 Subscription does not exist error. Things I've noticed: The RURI is missing a username : I've tried to fix this up by using $tU, but that doesn't seem to help. BLF/Presence has been driving me nuts lately. Is this just broken phone firmware? Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Multiple Presence Servers
Hi, I'd like to know if it is possible to have multiple presence servers. The idea is to distribute SUBSCRIBE messages around so that each presence server is aware of all subscriptions. However, it seems as though there is a problem with the to_tag when doing this since it is used as a matching mechanism. When we have subscription renewals from a phone, it transmits the to_tag of the server it was registered with initially. This server then tries to distribute the SUBSCRIBE to the other servers. However, because each server generated its own to_tag with the initial SUBSCRIBE, each server returns with a 481 Subscription Not Found. Is there any way to work around this issue? Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Building an Opensips cluster with presence - help needed
Hi Anca, Bogdan, and list, I've been banging my head against this for some time now, so I'm wondering what I'm trying to do is possible. My goal is to create an Opensips cluster that provides the following: 1) Registration for phones behind NAT 2) BLF/Presence information (through Event: dialog) All of the actual dialplan/PSTN stuff will be managed by a cluster of Asterisk boxes upstream. The idea is that the servers are all listed in a single DNS A record, and a phone can register to any opensips box at any time and still have all functionality. I'm not using a shared DB approach for a couple of reasons: 1) I'm trying to get rid of single points of failure. 2) Because all the phones are behind NAT, all packets to the phone must be sent from the server that it registered on. I've managed to get all the registration and call handling working fine using t_replicate() on REGISTER requests; Inbound and outbound calls work great! The biggest issue I've run into is getting the BLF/Presence information to propagate properly. My first thought was to have each server keep SUBSCRIBEs locally, but distribute PUBLISH messages from the presence module. Unfortunately this did not work due to failed E-Tag matching. - As far as I understand, the E-Tag is server specific and must match something in the presentity table? - Distributing a PUBLISH generated by 1 server to another server always resulted in a E-Tag, no match found error My second idea was to distribute SUBSCRIBEs, and keep PUBLISH local. This worked great for the first SUBSCRIBE from a phone. However, any renewing of the subscription caused distributed SUBSCRIBEs to fail because each server generates its own to_tag, which, when forwarding the next SUBSCRIBE that has server1's to_tag, would fail to match any other server because they already had a subscription with a different to_tag. My question is, is there a way to solve this? Am I going about this completely the wrong way? Is this an insane idea that will never work? I've kinda hit a wall here, so any help would be appreciated. Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Multiple Presence Servers
Hi Bogdan, The only way I see that scenario working is to forward SUBSCRIBEs messages to the server that a phone is registered on. (If you do it some other way, the presence module will not generate a PUBLISH because it doesn't see a SUBSCRIBE). However, there is a real problem with this when it comes to subscription renewals and if a phone was plugged in before another registered: Imaging the following scenario, phone A wants to monitor phone B. Phone A and B are not registered. Phone A gets plugged in, registers to S1, and sends a SUBSCRIBE for B. Phone B isn't registered so we don't know where to route it. We could do a couple things: 1) Only handle the SUBSCRIBE on S1 2) Broadcast the SUBSCRIBE to all servers (S1...Sn) 3) Reject the SUBSCRIBE Now lets say phone B is plugged in and is not registered on Si (not S1). At this point phone A is sending subscription renewals with a to_tag. Unfortunately, if B is not registered on S1, all subsequent subscription renewals will fail, because the to_tag that Si generates is different than what the phone is sending. The only way to recover from this is to reboot phone A. Am I missing something here? One solution that I've implemented is that any distributed SUBSCRIBE from S1 has its to_tag stripped off. This has the effect of creating a new subscription each time on each of the other servers, which actually seems to work quite well. PUBLISHes are handled by each local server and then forwarded to the correct place by using the recorded route from the SUBSCRIBE. -- James On Mon, Aug 8, 2011 at 12:42 PM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi James, I thing your approach on multi Presence Servers is correct. You cannot simple fork the SUBSCRIBE to all servers, as this will break how presence works. the presence state must stay on a single server, so all PUBLISHs for entity A and all SUBSCRIBES to entity A must go to the same presence server. Regards, Bogdan On 08/05/2011 11:31 AM, James Lamanna wrote: Hi, I'd like to know if it is possible to have multiple presence servers. The idea is to distribute SUBSCRIBE messages around so that each presence server is aware of all subscriptions. However, it seems as though there is a problem with the to_tag when doing this since it is used as a matching mechanism. When we have subscription renewals from a phone, it transmits the to_tag of the server it was registered with initially. This server then tries to distribute the SUBSCRIBE to the other servers. However, because each server generated its own to_tag with the initial SUBSCRIBE, each server returns with a 481 Subscription Not Found. Is there any way to work around this issue? Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS eBootcamp - 19th of September 2011 OpenSIPS solutions and know-how ___ 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] Working around a broken NAT
Hi, Is there a good way to work around a broken NAT? I have a customer who is receiving one-way inbound audio (outbound is fine). Here's what a REGISTER packet looks like: U public.ip:9241 - opensips.ip:5060 REGISTER sip:registrar SIP/2.0..Via: SIP/2.0/UDP public.ip:9241;branch=z9hG4bK-6d65fdc0..From: 0882 sip:0...@registrar.warp2biz.com;tag=98193b5f9af29c75o0..To: 626-628-0882 sip:0882@registrar..Call-ID: 1fc928db-41d9 2...@192.168.1.71..cseq: 50366 REGISTER..Max-Forwards: 70..Contact: 0882 sip:0...@public.ip:9241;expires=3500..User -Agent: Linksys/SPA942-6.1.3(a)-000e083c54b9..Content-Length: 0..Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER..Supporte d: replaces As you can see, all nat_uac_test()s would fail, and nothing is stored in the received line of the location database. Is there another way to work around this, or do I just have to tell them to fix their router? Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Working around a broken NAT
Any ideas with this one? BTW the phones work fine when registered directly to Asterisk, which tells me there must be a way to make this work. -- James On Wed, Aug 24, 2011 at 7:33 AM, James Lamanna jlama...@gmail.com wrote: Hi, Is there a good way to work around a broken NAT? I have a customer who is receiving one-way inbound audio (outbound is fine). Here's what a REGISTER packet looks like: U public.ip:9241 - opensips.ip:5060 REGISTER sip:registrar SIP/2.0..Via: SIP/2.0/UDP public.ip:9241;branch=z9hG4bK-6d65fdc0..From: 0882 sip:0...@registrar.warp2biz.com;tag=98193b5f9af29c75o0..To: 626-628-0882 sip:0882@registrar..Call-ID: 1fc928db-41d9 2...@192.168.1.71..cseq: 50366 REGISTER..Max-Forwards: 70..Contact: 0882 sip:0...@public.ip:9241;expires=3500..User -Agent: Linksys/SPA942-6.1.3(a)-000e083c54b9..Content-Length: 0..Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER..Supporte d: replaces As you can see, all nat_uac_test()s would fail, and nothing is stored in the received line of the location database. Is there another way to work around this, or do I just have to tell them to fix their router? Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Crash: EOF on 12 (v.1.6.4.2)
Hi, I'm experiencing a crash after about 5 minutes on a system (same config works fine on other systems). This is a system running under OpenVZ. Here's the tail end of syslog: Nov 27 18:04:18 opensips2 /usr/local/sbin/opensips[7280]: DBG:tm:matching_3261: RFC3261 transaction matched, tid=6332.a2d6e8d7.0 Nov 27 18:04:18 opensips2 /usr/local/sbin/opensips[7280]: DBG:tm:t_lookup_request: REF_UNSAFE:[0x2b835e4a4f98] after is 1 Nov 27 18:04:18 opensips2 /usr/local/sbin/opensips[7280]: DBG:tm:t_lookup_request: transaction found (T=0x2b835e4a4f98) Nov 27 18:04:18 opensips2 /usr/local/sbin/opensips[7280]: DBG:tm:t_retransmit_reply: nothing to retransmit Nov 27 18:04:18 opensips2 /usr/local/sbin/opensips[7280]: DBG:tm:t_unref: UNREF_UNSAFE: [0x2b835e4a4f98] after is 0 Nov 27 18:04:18 opensips2 /usr/local/sbin/opensips[7280]: DBG:core:destroy_avp_list: destroying list (nil) Nov 27 18:04:18 opensips2 /usr/local/sbin/opensips[7280]: DBG:core:receive_msg: cleaning up Nov 27 18:04:18 opensips2 /usr/local/sbin/opensips[7285]: DBG:core:udp_rcv_loop: probing packet received len = 4 Nov 27 18:04:19 opensips2 /usr/local/sbin/opensips[7286]: DBG:core:udp_rcv_loop: probing packet received len = 4 Nov 27 18:04:19 opensips2 /usr/local/sbin/opensips[7286]: DBG:core:udp_rcv_loop: probing packet received len = 4 Nov 27 18:04:20 opensips2 /usr/local/sbin/opensips[7284]: DBG:core:udp_rcv_loop: probing packet received len = 4 Nov 27 18:04:21 opensips2 /usr/local/sbin/opensips[7285]: DBG:core:udp_rcv_loop: probing packet received len = 4 Nov 27 18:04:22 opensips2 /usr/local/sbin/opensips[7296]: CRITICAL:core:receive_fd: EOF on 12 Nov 27 18:04:22 opensips2 /usr/local/sbin/opensips[7296]: DBG:core:handle_ser_child: dead child 5, pid 7281 (shutting down?) Nov 27 18:04:22 opensips2 /usr/local/sbin/opensips[7296]: DBG:core:io_watch_del: io_watch_del (0x76c500, 12, -1, 0x0) fd_no=21 called Nov 27 18:04:22 opensips2 /usr/local/sbin/opensips[7275]: INFO:core:handle_sigs: child process 7281 exited by a signal 11 Nov 27 18:04:22 opensips2 /usr/local/sbin/opensips[7275]: INFO:core:handle_sigs: core was generated Nov 27 18:04:22 opensips2 /usr/local/sbin/opensips[7275]: INFO:core:handle_sigs: terminating due to SIGCHLD Any ideas? Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Crash: EOF on 12 (v.1.6.4.2)
Here's probably a more telling BT (Debug=3) #0 0x2aba8e563f33 in get_dialog (dialog=0x7fff59e5b5d0, hash_code=value optimized out) at hash.c:480 480 if((p-watcher_uri-len== dialog-watcher_uri-len) (gdb) bt #0 0x2aba8e563f33 in get_dialog (dialog=0x7fff59e5b5d0, hash_code=value optimized out) at hash.c:480 #1 0x2aba8e565108 in update_contact (msg=value optimized out, str1=value optimized out, str2=value optimized out) at hash.c:666 #2 0x00411ccc in do_action (a=0x7c5378, msg=0x7ef758) at action.c:1195 #3 0x0041040e in run_action_list (a=value optimized out, msg=0x7ef758) at action.c:140 #4 0x004145aa in do_action (a=0x7c6cc0, msg=0x7ef758) at action.c:825 #5 0x0041040e in run_action_list (a=value optimized out, msg=0x7ef758) at action.c:140 #6 0x004138a8 in run_actions (a=0x7b5fe0, msg=0x7ef758) at action.c:120 #7 do_action (a=0x7b5fe0, msg=0x7ef758) at action.c:488 #8 0x0041040e in run_action_list (a=value optimized out, msg=0x7ef758) at action.c:140 #9 0x00413c62 in do_action (a=0x7b6190, msg=0x7ef758) at action.c:819 #10 0x0041040e in run_action_list (a=value optimized out, msg=0x7ef758) at action.c:140 #11 0x004145aa in do_action (a=0x7b6268, msg=0x7ef758) at action.c:825 #12 0x0041040e in run_action_list (a=value optimized out, msg=0x7ef758) at action.c:140 #13 0x004145aa in do_action (a=0x7b6f68, msg=0x7ef758) at action.c:825 #14 0x0041040e in run_action_list (a=value optimized out, msg=0x7ef758) at action.c:140 #15 0x00413c62 in do_action (a=0x7b7118, msg=0x7ef758) at action.c:819 #16 0x0041040e in run_action_list (a=value optimized out, msg=0x7ef758) at action.c:140 #17 0x00415886 in run_actions (a=0x7b0d00, msg=0x7ef758) at action.c:120 #18 run_top_route (a=0x7b0d00, msg=0x7ef758) at action.c:181 #19 0x0046f21c in receive_msg ( buf=0x77cbc0 NOTIFY sip:208.90.184.11;lr SIP/2.0\r\nVia: SIP/2.0/UDP 208.90.184.11;branch=z9hG4bKaff5.56547fb7.0\r\nVia: SIP/2.0/UDP 208.90.184.6;rport=5060;received=208.90.184.6;branch=z9hG4bKaff5.20317c76.0\r\nTo: si..., len=713, rcv_info=0x7fff59e5d7b0) at receive.c:162 #20 0x004c2f3c in udp_rcv_loop () at udp_server.c:492 #21 0x0042e785 in main_loop (argc=value optimized out, argv=value optimized out) at main.c:824 #22 main (argc=value optimized out, argv=value optimized out) at main.c:1393 And variables: (gdb) frame 1 #1 0x2aba8e565108 in update_contact (msg=value optimized out, str1=value optimized out, str2=value optimized out) at hash.c:666 666 p= get_dialog(hentity, hash_code); (gdb) print p $1 = value optimized out (gdb) print *p Cannot access memory at address 0x0 (gdb) print *p-pres_uri Cannot access memory at address 0x18 (gdb) print p-pres_uri Cannot access memory at address 0x18 (gdb) print *p-watcher_uri Cannot access memory at address 0x88 (gdb) print p-call_id Cannot access memory at address 0x90 (gdb) print p-to_tag Cannot access memory at address 0xa0 (gdb) print p-from_tag Cannot access memory at address 0xb0 -- James On Tue, Nov 29, 2011 at 2:20 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi James, It seams that the crash is because of a bogus debug message - do you run opensips in full debug mode (debug=6) ? Anyhow, in gdb, please switch to frame #1 and print the following values: p *p *p-pres_uri p-pres_uri *p-watcher_uri p-call_id p-to_tag p-from_tag Thanks and regards, Bogdan On 11/28/2011 09:31 PM, James Lamanna wrote: On Mon, Nov 28, 2011 at 12:00 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi James, The relevant part is: Nov 27 18:04:22 opensips2 /usr/local/sbin/opensips[7275]:INFO:core:handle_sigs: child process 7281 exited by a signal 11 Nov 27 18:04:22 opensips2 /usr/local/sbin/opensips[7275]:INFO:core:handle_sigs: core was generated As a core file was generate, could you extract the backtrace from it ? ( use gdb as gdb path_to_opensips_bin path_to_core_file and run in there bt). HI Bogdan, Here you go: Core was generated by `/usr/local/sbin/opensips -P /var/run/opensips.pid -f /usr/local/etc/opensips/op'. Program terminated with signal 11, Segmentation fault. #0 0x2b79331550c4 in syslog (dialog=0x7fff301988b0, hash_code=value optimized out) at /usr/include/bits/syslog.h:32 32 return __syslog_chk (__pri, __USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ()); (gdb) bt #0 0x2b79331550c4 in syslog (dialog=0x7fff301988b0, hash_code=value optimized out) at /usr/include/bits/syslog.h:32 #1 get_dialog (dialog=0x7fff301988b0, hash_code=value optimized out) at hash.c:471 #2 0x2b7933156108 in update_contact (msg=value optimized out, str1=value optimized out, str2=value optimized out) at hash.c:666 #3 0x00411ccc in do_action (a=0x7c5358, msg=0x7ef7e8) at action.c:1195 #4 0x0041040e
Re: [OpenSIPS-Users] Crash: EOF on 12 (v.1.6.4.2)
Realized I got variables from the wrong frame.
(gdb) print p
$1 = (ua_pres_t *) 0x2aba902bfb00
(gdb) print *p
$2 = {hash_index = 305, local_index = 0, id = {s = 0x2aba902bfc44
DIALOG_PUBLISHb\374+\220\272*, len = 14},
pres_uri = 0x2aba902bfc18, event = 64, expires = 1322593862,
desired_expires = 1322593633, flag = 1024,
db_flag = 0, next = 0x0, ua_flag = 0, etag = {s = 0x2aba9024ccf8
a.1322544815.24201.3244.293:60604.11,
len = 26}, tuple_id = {s = 0x0, len = 0}, waiting_reply = 0,
pending_publ = 0x0, to_uri = {s = 0x0,
len = 0}, watcher_uri = 0x0, call_id = {s = 0x0, len = 0}, to_tag
= {s = 0x0, len = 0}, from_tag = {
s = 0x0, len = 0}, cseq = 0, version = 29, watcher_count = 0,
outbound_proxy = 0x2aba902bfc52,
extra_headers = 0x0, record_route = {s = 0x0, len = 0},
remote_contact = {s = 0x0, len = 0}, contact = {
s = 0x0, len = 0}, cb_param = 0x0}
(gdb) print *p-pres_uri
$3 = {s = 0x2aba902bfc28
sip:17134608801@208.90.184.3DIALOG_PUBLISHb\374+\220\272*, len = 28}
(gdb) print p-pres_uri
$4 = (str *) 0x2aba902bfc18
(gdb) print *p-watcher_uri
Cannot access memory at address 0x0
(gdb) print p-call_id
$5 = {s = 0x0, len = 0}
(gdb) print p-to_tag
$6 = {s = 0x0, len = 0}
(gdb) print p-from_tag
$7 = {s = 0x0, len = 0}
-- James
On Tue, Nov 29, 2011 at 2:16 PM, James Lamanna jlama...@gmail.com wrote:
Here's probably a more telling BT (Debug=3)
#0 0x2aba8e563f33 in get_dialog (dialog=0x7fff59e5b5d0,
hash_code=value optimized out) at hash.c:480
480 if((p-watcher_uri-len==
dialog-watcher_uri-len)
(gdb) bt
#0 0x2aba8e563f33 in get_dialog (dialog=0x7fff59e5b5d0,
hash_code=value optimized out) at hash.c:480
#1 0x2aba8e565108 in update_contact (msg=value optimized out,
str1=value optimized out, str2=value optimized out) at hash.c:666
#2 0x00411ccc in do_action (a=0x7c5378, msg=0x7ef758) at
action.c:1195
#3 0x0041040e in run_action_list (a=value optimized out,
msg=0x7ef758) at action.c:140
#4 0x004145aa in do_action (a=0x7c6cc0, msg=0x7ef758) at action.c:825
#5 0x0041040e in run_action_list (a=value optimized out,
msg=0x7ef758) at action.c:140
#6 0x004138a8 in run_actions (a=0x7b5fe0, msg=0x7ef758) at
action.c:120
#7 do_action (a=0x7b5fe0, msg=0x7ef758) at action.c:488
#8 0x0041040e in run_action_list (a=value optimized out,
msg=0x7ef758) at action.c:140
#9 0x00413c62 in do_action (a=0x7b6190, msg=0x7ef758) at action.c:819
#10 0x0041040e in run_action_list (a=value optimized out,
msg=0x7ef758) at action.c:140
#11 0x004145aa in do_action (a=0x7b6268, msg=0x7ef758) at action.c:825
#12 0x0041040e in run_action_list (a=value optimized out,
msg=0x7ef758) at action.c:140
#13 0x004145aa in do_action (a=0x7b6f68, msg=0x7ef758) at action.c:825
#14 0x0041040e in run_action_list (a=value optimized out,
msg=0x7ef758) at action.c:140
#15 0x00413c62 in do_action (a=0x7b7118, msg=0x7ef758) at action.c:819
#16 0x0041040e in run_action_list (a=value optimized out,
msg=0x7ef758) at action.c:140
#17 0x00415886 in run_actions (a=0x7b0d00, msg=0x7ef758) at
action.c:120
#18 run_top_route (a=0x7b0d00, msg=0x7ef758) at action.c:181
#19 0x0046f21c in receive_msg (
buf=0x77cbc0 NOTIFY sip:208.90.184.11;lr SIP/2.0\r\nVia:
SIP/2.0/UDP 208.90.184.11;branch=z9hG4bKaff5.56547fb7.0\r\nVia:
SIP/2.0/UDP
208.90.184.6;rport=5060;received=208.90.184.6;branch=z9hG4bKaff5.20317c76.0\r\nTo:
si..., len=713, rcv_info=0x7fff59e5d7b0) at receive.c:162
#20 0x004c2f3c in udp_rcv_loop () at udp_server.c:492
#21 0x0042e785 in main_loop (argc=value optimized out,
argv=value optimized out) at main.c:824
#22 main (argc=value optimized out, argv=value optimized out) at
main.c:1393
And variables:
(gdb) frame 1
#1 0x2aba8e565108 in update_contact (msg=value optimized out,
str1=value optimized out, str2=value optimized out) at hash.c:666
666 p= get_dialog(hentity, hash_code);
(gdb) print p
$1 = value optimized out
(gdb) print *p
Cannot access memory at address 0x0
(gdb) print *p-pres_uri
Cannot access memory at address 0x18
(gdb) print p-pres_uri
Cannot access memory at address 0x18
(gdb) print *p-watcher_uri
Cannot access memory at address 0x88
(gdb) print p-call_id
Cannot access memory at address 0x90
(gdb) print p-to_tag
Cannot access memory at address 0xa0
(gdb) print p-from_tag
Cannot access memory at address 0xb0
-- James
On Tue, Nov 29, 2011 at 2:20 AM, Bogdan-Andrei Iancu
bog...@opensips.org wrote:
Hi James,
It seams that the crash is because of a bogus debug message - do you run
opensips in full debug mode (debug=6) ?
Anyhow, in gdb, please switch to frame #1 and print the following values:
p
*p
*p-pres_uri
p-pres_uri
*p-watcher_uri
p-call_id
p-to_tag
p-from_tag
Thanks and regards,
Bogdan
On 11/28
Re: [OpenSIPS-Users] Crash: EOF on 12 (v.1.6.4.2)
Hi Bogdan,
Any ideas here?
Thanks.
-- James
On Tue, Nov 29, 2011 at 3:57 PM, James Lamanna jlama...@gmail.com wrote:
Realized I got variables from the wrong frame.
(gdb) print p
$1 = (ua_pres_t *) 0x2aba902bfb00
(gdb) print *p
$2 = {hash_index = 305, local_index = 0, id = {s = 0x2aba902bfc44
DIALOG_PUBLISHb\374+\220\272*, len = 14},
pres_uri = 0x2aba902bfc18, event = 64, expires = 1322593862,
desired_expires = 1322593633, flag = 1024,
db_flag = 0, next = 0x0, ua_flag = 0, etag = {s = 0x2aba9024ccf8
a.1322544815.24201.3244.293:60604.11,
len = 26}, tuple_id = {s = 0x0, len = 0}, waiting_reply = 0,
pending_publ = 0x0, to_uri = {s = 0x0,
len = 0}, watcher_uri = 0x0, call_id = {s = 0x0, len = 0}, to_tag
= {s = 0x0, len = 0}, from_tag = {
s = 0x0, len = 0}, cseq = 0, version = 29, watcher_count = 0,
outbound_proxy = 0x2aba902bfc52,
extra_headers = 0x0, record_route = {s = 0x0, len = 0},
remote_contact = {s = 0x0, len = 0}, contact = {
s = 0x0, len = 0}, cb_param = 0x0}
(gdb) print *p-pres_uri
$3 = {s = 0x2aba902bfc28
sip:17134608801@208.90.184.3DIALOG_PUBLISHb\374+\220\272*, len = 28}
(gdb) print p-pres_uri
$4 = (str *) 0x2aba902bfc18
(gdb) print *p-watcher_uri
Cannot access memory at address 0x0
(gdb) print p-call_id
$5 = {s = 0x0, len = 0}
(gdb) print p-to_tag
$6 = {s = 0x0, len = 0}
(gdb) print p-from_tag
$7 = {s = 0x0, len = 0}
-- James
On Tue, Nov 29, 2011 at 2:16 PM, James Lamanna jlama...@gmail.com wrote:
Here's probably a more telling BT (Debug=3)
#0 0x2aba8e563f33 in get_dialog (dialog=0x7fff59e5b5d0,
hash_code=value optimized out) at hash.c:480
480 if((p-watcher_uri-len==
dialog-watcher_uri-len)
(gdb) bt
#0 0x2aba8e563f33 in get_dialog (dialog=0x7fff59e5b5d0,
hash_code=value optimized out) at hash.c:480
#1 0x2aba8e565108 in update_contact (msg=value optimized out,
str1=value optimized out, str2=value optimized out) at hash.c:666
#2 0x00411ccc in do_action (a=0x7c5378, msg=0x7ef758) at
action.c:1195
#3 0x0041040e in run_action_list (a=value optimized out,
msg=0x7ef758) at action.c:140
#4 0x004145aa in do_action (a=0x7c6cc0, msg=0x7ef758) at
action.c:825
#5 0x0041040e in run_action_list (a=value optimized out,
msg=0x7ef758) at action.c:140
#6 0x004138a8 in run_actions (a=0x7b5fe0, msg=0x7ef758) at
action.c:120
#7 do_action (a=0x7b5fe0, msg=0x7ef758) at action.c:488
#8 0x0041040e in run_action_list (a=value optimized out,
msg=0x7ef758) at action.c:140
#9 0x00413c62 in do_action (a=0x7b6190, msg=0x7ef758) at
action.c:819
#10 0x0041040e in run_action_list (a=value optimized out,
msg=0x7ef758) at action.c:140
#11 0x004145aa in do_action (a=0x7b6268, msg=0x7ef758) at
action.c:825
#12 0x0041040e in run_action_list (a=value optimized out,
msg=0x7ef758) at action.c:140
#13 0x004145aa in do_action (a=0x7b6f68, msg=0x7ef758) at
action.c:825
#14 0x0041040e in run_action_list (a=value optimized out,
msg=0x7ef758) at action.c:140
#15 0x00413c62 in do_action (a=0x7b7118, msg=0x7ef758) at
action.c:819
#16 0x0041040e in run_action_list (a=value optimized out,
msg=0x7ef758) at action.c:140
#17 0x00415886 in run_actions (a=0x7b0d00, msg=0x7ef758) at
action.c:120
#18 run_top_route (a=0x7b0d00, msg=0x7ef758) at action.c:181
#19 0x0046f21c in receive_msg (
buf=0x77cbc0 NOTIFY sip:208.90.184.11;lr SIP/2.0\r\nVia:
SIP/2.0/UDP 208.90.184.11;branch=z9hG4bKaff5.56547fb7.0\r\nVia:
SIP/2.0/UDP
208.90.184.6;rport=5060;received=208.90.184.6;branch=z9hG4bKaff5.20317c76.0\r\nTo:
si..., len=713, rcv_info=0x7fff59e5d7b0) at receive.c:162
#20 0x004c2f3c in udp_rcv_loop () at udp_server.c:492
#21 0x0042e785 in main_loop (argc=value optimized out,
argv=value optimized out) at main.c:824
#22 main (argc=value optimized out, argv=value optimized out) at
main.c:1393
And variables:
(gdb) frame 1
#1 0x2aba8e565108 in update_contact (msg=value optimized out,
str1=value optimized out, str2=value optimized out) at hash.c:666
666 p= get_dialog(hentity, hash_code);
(gdb) print p
$1 = value optimized out
(gdb) print *p
Cannot access memory at address 0x0
(gdb) print *p-pres_uri
Cannot access memory at address 0x18
(gdb) print p-pres_uri
Cannot access memory at address 0x18
(gdb) print *p-watcher_uri
Cannot access memory at address 0x88
(gdb) print p-call_id
Cannot access memory at address 0x90
(gdb) print p-to_tag
Cannot access memory at address 0xa0
(gdb) print p-from_tag
Cannot access memory at address 0xb0
-- James
On Tue, Nov 29, 2011 at 2:20 AM, Bogdan-Andrei Iancu
bog...@opensips.org wrote:
Hi James,
It seams that the crash is because of a bogus debug message - do you run
opensips in full debug mode (debug=6) ?
Anyhow, in gdb, please switch to frame #1 and print
[OpenSIPS-Users] Using a shared database with UAs behind NAT
Hi, I have 2 opensips servers that I'm trying to use a shared database with. The reason for this is to simplify BLF handling and allow phones to register to either server, increasing redundancy. However, all of my UAs are behind NAT which presents a problem in the following case: Phone P registers to server OS1. Asterisk receives a call for phone P. It routes the call to either OS1 or OS2 (based on DNS or dispatcher). If the call goes to OS1 there are no problems. If the call goes to OS2, OS2 wants to send the call directly to phone P, however it cannot because the NAT hole is not open to OS2. Is there a way upon REGISTER for OS2 to know that it needs to forward the inbound request to OS1 so that it can be transmitted properly through NAT? It seems that path_received would be for this purpose, but I haven't been able to get it to store in the database on the initial REGISTER. Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] SIP Authentication Attacks
Hi, I've noticed lately that a server of mine is getting repeatedly hit by an attacker trying to make international calls. The scary part is that the attacker seems to be able to register correctly on different extensions, even though each extension has a different, random password. I'm not sure how the attacker is getting the passwords or if there's a man-in-the-middle attack going on, but I would like some suggestions on how to increase the security of SIP authentication in opensips. I could enforce security through IP addresses, but I fear that will become quite cumbersome. Thanks. -- James ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] SIP Authentication Attacks
Hi, I know the phones are not on public IPs. Here is a opensips log of an attacker successfully registering (hashes have been scrubbed) Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_newtran: transaction on entrance=(nil) Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:parse_headers: flags= Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:parse_headers: flags=78 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_lookup_request: start searching: hash=22639, isACK=0 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_lookup_request: proceeding to pre-RFC3261 transaction matching Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:t_lookup_request: no transaction found Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:tm:run_reqin_callbacks: trans=0x2b9c44a2a3e0, callback type 1, id 0 entered Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_nonce: comparing [4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b] and [4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b] Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:has_stmt_ctx: ctx found for subscriber Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7ee8c0 (tail=8315728) MC=0x7ee3b0 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement run Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_val2bind: added val (0): len=5; type=254; is_null=0 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in... Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1 columns in result Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2200 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_allocate_columns: allocate 28 bytes for result columns at 0x7f55a8 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f55b0)[0]=[password] Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_allocate_rows: allocate 48 bytes for result rows and values at 0x7fa080 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:db_mysql:db_mysql_str2val: converting STRING [] Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth_db:get_ha1: HA1 string calculated: 7ee7c3 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_response: our result = 7f340e' Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_response: their response = '.7f340e, algorithm=MD5#015#012User-Agent: VaxSIPUserAgent/3.0#015#012Expires: Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:check_response: authorization is OK Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:auth:post_auth: nonce index= 3171 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_columns: freeing result columns at 0x7f55a8 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_rows: freeing 1 rows Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_row: freeing row values at 0x7fa090 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_rows: freeing rows at 0x7fa080 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: DBG:core:db_free_result: freeing result set at 0x7f2200 Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]: Auth attempt for xx...@yy.yy.yy.11 from 74.204.92.217 on port 5060 ret 1 -- James On Thu, Feb 2, 2012 at 12:08 AM, Dovid Bender os-l...@dovid.net wrote: James, We have found with out users that some of them put the phones on public IP’s. If the default password is not changed, no matter how hard the password is they will get in. Also try using characters like “@:^#” in your passwords. Regards, Dovid From: users-boun...@lists.opensips.org [mailto:users-boun...@lists.opensips.org] On Behalf Of aws j Sent: Thursday, February 02, 2012 06:08 To: OpenSIPS users mailling list Subject: Re: [OpenSIPS-Users] SIP Authentication Attacks Dear Mr James Can you attached to me your suspect file to make VoIP forensic on it . thanks Aws Msc VoIP security 2012/2/1 James Lamanna jlama...@gmail.com Hi, I've noticed lately that a server of mine is getting repeatedly hit by an attacker trying
Re: [OpenSIPS-Users] SIP Authentication Attacks
Why do you say the credentials are wrong?
I guess I'm missing something from the log...?
www_authorize is returning 1
Here's the register handling:
if (!t_newtran()) {
xlog(L_ERR, Could not make new transation REGISTER - M=$rm
RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n);
sl_reply_error();
exit;
}
$var(auth_code) = www_authorize(asterisk, subscriber);
xlog(L_INFO,Auth attempt for $fU@$fd from $si on port $Rp ret
$var(auth_code));
if ( $var(auth_code) == -1 || $var(auth_code) == -2 ) {
xlog(L_INFO,Auth error for $fU@$fd from $si cause $var(auth_code));
}
if ( $var(auth_code) 0 ) {
www_challenge(asterisk, 0);
exit;
}
-- James
On Fri, Feb 3, 2012 at 3:23 PM, dotnetdub dotnet...@gmail.com wrote:
On 3 February 2012 22:41, duane.lar...@gmail.com wrote:
What does your whole REGISTER route look like? Maybe you are missing
something in there and it is allowing someone to register even thought the
password is wrong.
Definitely an issue with your script. Somewhere in there you are rejecting
credentials but carrying on anyway...
On , James Lamanna jlama...@gmail.com wrote:
Hi,
I know the phones are not on public IPs.
Here is a opensips log of an attacker successfully registering
(hashes have been scrubbed)
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:tm:t_newtran: transaction on entrance=(nil)
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:parse_headers: flags=
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:parse_headers: flags=78
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:tm:t_lookup_request: start searching: hash=22639, isACK=0
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:tm:t_lookup_request: proceeding to pre-RFC3261 transaction
matching
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:tm:t_lookup_request: no transaction found
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:tm:run_reqin_callbacks: trans=0x2b9c44a2a3e0, callback type 1, id
0 entered
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:auth:check_nonce: comparing
[4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b] and
[4f2c3e2b0c63c2838fdbc4296a91dd7866f0c9a7b89b]
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:has_stmt_ctx: ctx found for subscriber
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_do_prepared_query: conn=0x7ee8c0 (tail=8315728)
MC=0x7ee3b0
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_do_prepared_query: set values for the statement
run
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_val2bind: added val (0): len=5; type=254;
is_null=0
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_do_prepared_query: doing BIND_PARAM in...
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_do_prepared_query: prepared statement has 1
columns in result
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:db_new_result: allocate 48 bytes for result set at 0x7f2200
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:db_allocate_columns: allocate 28 bytes for result columns at
0x7f55a8
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x7f55b0)[0]=[password]
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:db_allocate_rows: allocate 48 bytes for result rows and
values at 0x7fa080
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:db_mysql:db_mysql_str2val: converting STRING []
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:auth_db:get_ha1: HA1 string calculated: 7ee7c3
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:auth:check_response: our result = 7f340e'
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:auth:check_response: their response = '.7f340e,
algorithm=MD5#015#012User-Agent: VaxSIPUserAgent/3.0#015#012Expires:
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:auth:check_response: authorization is OK
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:auth:post_auth: nonce index= 3171
Feb 3 12:05:33 opensips2 /usr/local/sbin/opensips[26313]:
DBG:core:db_free_columns: freeing result
