3 Jan
2004
3 Jan
'04
2:43 p.m.
Jim,
thanks for your complete and detailed report. I reviewed it -- the script seems to me
sane and I am confused by the behaviour as well. Particularly, I would expect the
SER-to-SER CANCEL to cancel g+billybob branch, since the g+joebob branch is already
completed by the 408 (SER-to-SER). However, the CANCEL is sent on the same branch
which already received the 408. (see the messages in question bellow)
I would have to replay the scenario to make sure where the troubles come from.
Unfortunately, I don't know when that is going to happen -- I will be out of
office most of January. Perhaps someone else on the mailing list?
few minor details follow inline.
-jiri
U 2003/12/27 17:18:31.185029 192.168.0.5:5060 -> 192.168.0.5:5060
SIP/2.0 408 Request Timeout.
Via: SIP/2.0/UDP 192.168.0.5;branch=z9hG4bK6869.efd2f965.0.
Via: SIP/2.0/UDP
192.168.0.10:8358;rport=8358;branch=z9hG4bKAD98AD29E54F408E9643EA64D099B032.
From: Jim <sip:jimb@jsbc.cc>;tag=8700923.
To: <sip:5504@jsbc.cc>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-b87c.
Call-ID: 65104FD1-89A2-417D-988C-4C821795021B(a)192.168.0.10.
CSeq: 1844 INVITE.
Server: Sip EXpress router (0.8.11 (i386/linux)).
Content-Length: 0.
Warning: 392 192.168.0.5:5060 "Noisy feedback tells: pid=21674
req_src_ip=192.168.0.5 req_src_port=5060 in_uri=sip:g+joebob@jsbc.cc
out_uri=sip:joebob@192.168.0.2:8286 via_cnt==0".
.
#
U 2003/12/27 17:18:31.185099 192.168.0.5:5060 -> 192.168.0.2:8286
CANCEL sip:joebob@192.168.0.2:8286 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.5;branch=z9hG4bK6869.ffd2f965.0.
From: Jim <sip:jimb@jsbc.cc>;tag=8700923.
Call-ID: 65104FD1-89A2-417D-988C-4C821795021B(a)192.168.0.10.
To: <sip:5504@jsbc.cc>.
CSeq: 1844 CANCEL.
User-Agent: Sip EXpress router(0.8.11 (i386/linux)).
Content-Length: 0.
.
#
U 2003/12/27 17:18:31.185139 192.168.0.5:5060 -> 192.168.0.5:5060
CANCEL sip:g+joebob@jsbc.cc SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.5;branch=z9hG4bK6869.efd2f965.0.
From: Jim <sip:jimb@jsbc.cc>;tag=8700923.
Call-ID: 65104FD1-89A2-417D-988C-4C821795021B(a)192.168.0.10.
To: <sip:5504@jsbc.cc>.
CSeq: 1844 CANCEL.
User-Agent: Sip EXpress router(0.8.11 (i386/linux)).
Content-Length: 0.
.
At 12:25 AM 1/1/2004, Jim Burwell wrote:
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.
Till here, I agree -- use forking to addresses-of-record to fan "frontdesk" to a
bunch
of people, and make sure that calls to the final receipients do not crank voicemail if
intended for frontdesk.
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).
I think an easy way is to look at To header field and NOT initiate voicemail if
URI in this header field is on a list of group addresses. To do so, maintain group
addresses in "grp" table and check against it using the 'is_user_in'
action from
group module. I guess g+ works fine too, though my esthetic preference is use of
group membership checks.
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!)
config file nit:
if(uri=~"^sip:g+.*") { .... '+' has a special meaning for regular
expression
matching; use backslash
-jiri