hi,
i have some accounts to sip provider, but i dont know
how to setup ser 8.12 to masquarde local accounts and domain
to external account with domain.
like this
oper:test@local.net -> 12331223:123@deltafour.com
test:test@local.net -> 12331223:123@deltafour.com
vase:test@local.net -> 454331223:123@deltafour.com
it is possible ?
thnks
At 11:35 AM 12/31/2003, Matthew Moyle-Croft wrote:
>> I'm not sure, but maybe when a b2bua module is made ser could act as a
>> UAC and register with other proxies.
>
>I think this is quite important - running a SIP gateway for residential use
>is going to be more and more common. I'd really like to see this bit happen
>so that a Linux Gateway can be setup (maybe a modified version of one of the
>firewall/mail server distribution ones) so that anyone can get a basic
>machine, drop it on the network, plug some phones in and get in/out dial
>working quickly.
I understand your point though I am not sure that multiplexing identity is
a god thing to do.
-jiri
Hello,
Does anyone have any idea on how to config ser.cfg to do load balancing and priority routing?
1. load balancing
Two PSTN Gateways (A and B) could terminate the same destination numbers. How to do load balancing (just route calls to them randomly)?
2. priority routing
Two PSTN Gateways (A and B) could terminate the same destination numbers. SER always try A first. If A couldn't terminate the call (offline, no circuit ...), then it will try B. In other words, Gateway A always has a higher priority than B. How to do it?
Thanks a lot.
Regards,
Bob
Hi,
I was having some problems with calls to what I call "group" locations
entries. These are entries where users enter their own SIP address for
a particular location entry. The desired behavior is that when someone
calls this "group" user, multiple other users phones will ring, and if
not answered, voice mail will be called for the original "group" callee
user. This doesn't seem difficult, but turns out to be a little tricky
if the users enter the more logical, flexible, and user friendly
"sip:user@samedomain" style addresses instead of "sip:user@ip:port".
Obviously, requiring possibly non technical end users to enter the
IP:port of all their phones for these group users is unacceptable.
Using these domain style "indirect" entries is far nicer, since SER
ultimately simply looks up all the users' registered phones in the
locations table transparently.
Using "sip:user@samedomain" style locations destinations causes these
calls to fork back through SER a second time (spiraling back through
SER) for each destination. This is where I ran into a problem as far as
voice mail was concerned. When each branch of this call (each separate
destination in the destination set) was forked back through SER, if the
particular user in any given branch was a member of the voice mail
group, a voice mail timeout would be set for each, ultimately resulting
in a separate call to the voice mail system for each user, for the same
call! This caused mass confusion in SER and the voice mail system,
resulting in a failed voice mail call, for obvious reasons.
The solution was to make sure that in this special case, that only the
original "group" user gets queued for a voice mail timeout, and any
other branches spiraling back through SER did not cause voice mail to be
set up. Unfortunately, there's no easy way that I could figure out to
test for this condition in ser.cfg, since these forked branches look
just like normal calls to these users (which would be proper to set up a
voice mail timeout for). The solution I came up with was to require
users to use a special prefix, "g+", when entering their SIP URIs into
the group locations entries, marking them for special treatment. The
ser.cfg then simply looks for URIs that have the prefix "g+", and if
present, makes sure that no voice mail failure_route is set up for these
branches. Right before the locations lookup is done, the "g+" prefix is
stripped off, and the branch proceeds to call the users phone(s)
normally. Pretty simple, user friendly, and requires no special
external script, etc, to be called. Viola! It worked. But with some
misgivings.
This solution actually worked in all my testing. However, I'm troubled
by some of the SIP dumps of these calls I've examined. Particularly, I
noted how for whatever reason, there seems to be multiple
repeated/redundant "408 time out" messages sent back and forth between
SER and the phones. Also, for whatever reason, the caller's phone sends
repeated ACKs, which get routed to the voice mail system, even after it
has answered and is already talking to the VM system.
Do these traces look right ? Am I just being paranoid ? Please advise!
(ser.cfg and traces attached as ZIP file. Sorry! It would be too big
for the list otherwise!)
- Jim
--
+---------------------------------------------------------------------------+
| Jim Burwell - Sr. Systems/Network/Security Engineer, JSBC |
+---------------------------------------------------------------------------+
| "I never let my schooling get in the way of my education." - Mark Twain |
| "UNIX was never designed to keep people from doing stupid things, because |
| that policy would also keep them from doing clever things." - Doug Gwyn |
| "Cool is only three letters away from Fool" - Mike Muir, Suicyco |
| "..Government in its best state is but a necessary evil; in its worst |
| state an intolerable one.." - Thomas Paine, "Common Sense" (1776) |
+---------------------------------------------------------------------------+
| Email: jimb(a)jsbc.cc ICQ UIN: 1695089 |
+---------------------------------------------------------------------------+
| Reply problems ? Turn off the "sign" function in email prog. Blame MS. |
+---------------------------------------------------------------------------+
Hi all,
I am testing with SER 0.8.11 and I see the following problem:
I have record-route enabled. The mysterious behaviour is the following:
SER adds a Record-Route header to an INVITE-Request which does not only
consist of the host-portion of the proxy but also of a user-name.
As a consequence (I assume) loose_route does not work on such a
Route-header.
Below I have documented the received and forwarded Request of SER.
Does anybody have an idea what might be wrong?
Help very much appreciated.
Franz
The INVITE received by SER:
INVITE sip:snom@sip.fehome SIP/2.0
Via: SIP/2.0/UDP
192.168.0.1:5060;rport;branch=z9hG4bK97357ABBD8044AC5A3F32B0D76D4DCF6
From: wpc <sip:wpc@sip.fehome>;tag=2950742891
To: <sip:snom@sip.fehome>
Contact: <sip:wpc@192.168.0.1:5060>
Call-ID: 4A927B68-574F-423F-9BDB-ECEAC88CD4BC(a)192.168.0.1
CSeq: 56548 INVITE
Max-Forwards: 70
Content-Type: application/sdp
User-Agent: X-Lite build 1088
Content-Length: 288
...(SDP-part not shown)
The INVITE forwarded by SER after lookup (with record-route enabled):
INVITE sip:snom@192.168.0.60:5060;transport=udp;line=1 SIP/2.0
Record-Route: <sip:snom@192.168.0.78;ftag=2950742891;lr=on>
Via: SIP/2.0/UDP 192.168.0.78;branch=z9hG4bKe8f2.44610675.0
Via: SIP/2.0/UDP
192.168.0.1:5060;rport=5060;branch=z9hG4bK97357ABBD8044AC5A3F32B0D76D4DCF6
From: wpc <sip:wpc@sip.fehome>;tag=2950742891
To: <sip:snom@sip.fehome>
Contact: <sip:wpc@192.168.0.1:5060>
Call-ID: 4A927B68-574F-423F-9BDB-ECEAC88CD4BC(a)192.168.0.1
CSeq: 56548 INVITE
Max-Forwards: 69
Content-Type: application/sdp
User-Agent: X-Lite build 1088
Content-Length: 288
...(SDP-part not shown)
you can, the penalty of permanent relay use is bandwidth consumption and
voice latency.
-jiri
At 12:12 AM 12/31/2003, radan wrote:
>Hi !!
>Can I use rtpproxy with all types of NAT
>(full cone, restricted cone, port restricted cone
>and symmetric) ?
>
>Regards
>Andrzej
>
>_______________________________________________
>Serusers mailing list
>serusers(a)lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
Hi,
Like to check does anyone know how to specifically know that SER is being
configure properly, is there anyway to test. I am running on Linux 9.0,
cannot use the command ngrep and sipsak to do any diagnostics. Please kindly
advice.
Regards,
Shirley
That's a bug in the Messenger 5.0 - only Microsoft can fix it.
Dhiraj
-----Original Message-----
From: serusers-bounces(a)iptel.org on behalf of Andy Singh
Sent: Wed 31/12/2003 22:42
To: 'serusers(a)iptel.org'
Cc:
Subject: [Serusers] Messenger 5.0 problem
