[Serusers] Do these SIP dumps look right ("group" locations entry) ?

[Jim Burwell]

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 at samedomain" style addresses instead of "sip:user at 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 at 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 at jsbc.cc                              ICQ UIN:  1695089     |
+---------------------------------------------------------------------------+
|  Reply problems ?  Turn off the "sign" function in email prog.  Blame MS. |
+---------------------------------------------------------------------------+

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cfg+dumps.zip
Type: application/x-zip-compressed
Size: 6542 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20031231/37566d55/attachment.bin>