hello again!
I just wanted to give a quick overview of why I have been asking about a
Proxy being able to do a Registrar Query
over the last couple of days, and see if you had any feedback on whether
or not what I am intending to do
was going to be a sensible or indeed workable approach
I have been tasked with looking into implementing SIP in a system with
the following topology:
H11----H12----H13----P1
|
|
|
H21----H22----H23----P2----DNS_Srv
|
|
|
H31----H32----H33----P3
.
.
.
HN1----HN2----HNx----PN
where HNx is a 3rd-pary IP host (e.g. VoIP SIP phone, terminal) on
subnet N
PN is an IP host with a well-known host address on subnet N (there will
be 1 such device per subnet)
- e.g. 192.168.N.1
The most important point to realize about this network, though, is that
even though all
hosts are IP-reachable in a class-B addressing policy, the IP
implementation is not
suitable for a volume of traffic (and certainly not for any kind of QoS
for voice traffic)
BETWEEN the subnets - indeed it is not ethernet between the PN devices
(between hosts on a SINGLE subnet, this is not an issue - e.g. H11 to
H12 - these ARE connected
by standard ethernet).
IN ORDER to bridge voice between, say, H11 and H21, a secondary network
ALREADY exists which interconnects
PN devices
...that is to say that P1, P2, P3, etc. are still able to talk IP
(TCP/UDP) between each other,
but for something like voice traffic, a second mechanism exists which
can interconnect media for these
PN entities.
The assumptions/propositions are:
1) there is a central DNS server with a co-resident SIP Registrar/Proxy
Server
2) this central SIP Registrar would represent a single SIP domain (e.g.
registrar.domain.com)
3) each PN will host an outbound proxy server for all of its HNx
endpoints
I will have to implement this proxy, so I can implement custom logic
on/for it
4) each PN will also host a SIP Gateway to bridge calls between
endpoints on different subnets
(e.g. if H11 were to call H21, the media path would be
H11->P1_GW (SIP over IP), P1_GW -> P2_GW (propietary other-network
voice cxn),
P2_GW -> H21 (SIP over IP)
...indeed each Gateway will also bridge calls into and from the
propietary network
Now since all SIP endpoints are in the same domain, and since I need to
integrate this system with another
system preferably using a homogenous dialling scheme, I thought I could
register all endpoints with a
7-digit username scheme e.g. [EMAIL PROTECTED] (these can be registered
with "Contact:" bindings like
[EMAIL PROTECTED] in the domain SIP Registrar).
My main proposal then, is that since P1 would be configured as the
outbound proxy for H11, H12, ..., H1x -
all SIP INVITE messages will come through it.
Since I have to implement the proxy on PN, I can use this opportunity to
examine the target of the SIP INVITE
and GET THE PROXY TO QUERY THE REGISTRAR for the target of the
invitation
(i.e. to lookup the binding Contact record from the AoR in the "To:"
field) to discover whether
the intended target is
1) on the local subnet (e.g. H12)
2) on another subnet (e.g. H21)
3) unknown to this SIP domain (e.g. any other number not registered with
the registrar)
If 2 or 3, then I could get the proxy to intervene and return a "Moved
Temporarily" response to the caller
with a "Contact:" address referring it to P1 (that is, the local
gateway) -
i.e. if H11 phoned (invited) [EMAIL PROTECTED] (which was on H21), I
could get P1 to (in its own transaction)
query the Registrar for [EMAIL PROTECTED], interpret the Registrar's
response to discover that the target was
in fact on a different subnet, and complete the transaction with H11 by
replying to it with
"Contact: [EMAIL PROTECTED]" URI (with the actual IP address for P1) -
the Gateway at P1 would then be responsible for transiting
(propietarily) the call across to P2 and subsequently,
the Gateway at P2 would be responsible for initiating a 3rd (SIP)
call-leg to H21.
If the intended target was NOT KNOWN by the Registrar, I would still
redirect the caller to the P1 Gateway
and use external name/number-resolution mechanism to discover the target
of the call if it existed in the
propietary network and handle the bridging accordingly.
If the intended target was on the same subnet, I could simply proxy the
INVITE through the centralized
Registrar/Proxy server as per a conventional SIP setup sequence.
I realize there is a lot to read and absorb here, (and I am putting some
faith in my own explanatory skills!)
but I would be terrifically grateful if I can get some feedback
as to what the community thinks of this proposed solution, how (if) it
fits in with the SIP philosophy, and
indeed whether there is a better (or even simpler) solution implementing
SIP in such an environment.
Thanks so much for all your comments and feedback to date and to come.
m
The information contained in this e-mail message is PRIVATE. It may contain
confidential information and may be legally privileged. It is intended for the
exclusive use of the addressee(s). If you are not the intended recipient, you
are hereby notified that any dissemination, distribution or reproduction of
this communication is strictly prohibited. If the intended recipient(s) cannot
be reached or if a transmission problem has occurred, please notify the sender
immediately by return e-mail and destroy all copies of this message.
Thank you.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
