Alex Balashov schrieb:
Perhaps I can put the issue more succinctly:
Say I have a user that has two DIDs - the ones in my signature,
6789540670 and 6789540671.
If I actually have a user (evariste1, say) register from two pieces of
CPE with a contact of 6789540670@IP, then, yes, I agree, there should be
two branches generated.
The problem I have is with the scenario where endpoint A registers as
evariste1@my_sip_domain with a contact of 6789540670 and endpoint B
registers as evariste1@my_sip_domain with a contact of 6789540671.
I wonder how you manage to do this without Asterisk. AFAIK Asterisk is
the only SIP client which allows you to specify the userpart of the contact.
I think this is the design problem. If you do not want branching then
you should not have multiple contacts for the same AoR.
IIRC there was an extension to SIP registration in the SIPConnect
specification of the SIP forum how to register multiple DIDs. Maybe this
can give you some more ideas how to solve the problem.
http://www.sipforum.org/component/option,com_docman/task,cat_view/gid,43/It…
regards
klaus
When the registrar/usrloc lookup() evariste1, they're going to get both
contacts, and branch the call to both contacts -- regardless of which
number is the one that was actually dialed from the PSTN.
So, what I'm trying to do with my branch routes is have it look at the
To URI user part ($tU) and compare it with the lookup()'d RURI user
part. If they match up, send it on, otherwise drop() the branch.
The problem, as I mentioned, is that there are far too many possible
registration and end-user UA scenarios. What if they only want to
register once/their equipment only allows one registration? What if
they want to receive some DIDs on one "line" and some DIDs on another
"line?" What if, in the former scenario, they want one registration but
need to do DNIS-based routing, which in Asterisk is currently entirely
broken? The problem is that if I register with a contact of 6789540670
without any checks, I'm going to get calls for 6789540671 as well (as
indicated in To:) with a RURI user part of 6789540670 as well, because,
well, that's what the contact is. Can't have that happen.
-- Alex