Henning Schulzrinne wrote:
> > As a general observation it seemed to me the bakeoff was more useful for
> > testing User Agents than Proxies. Probably because it is easier to test UAs
> > through basic call setup scenarios whilst testing a proxy generally requires
> > setting up >1 proxies plus many UAs. This was a shame because to debug the
> > protocol further I feel we really need to run scenarios involving networks of
> > SIP servers. Perhaps at the next bakeoff we can try and prearrange implementors
> > roles in scenarios so that people turn up better prepared to setup and go. It
> > might also help if we just ran one reliable UA in the proxy oriented tests.
>
> This is a good idea. I suspect that many UAs will now implement the main
> missing pieces (tel, re-INVITE) so that we should have more choices. I
> wonder if setting up a separate proxy area in the bake-off hall would be
> useful, as I found it difficult to coordinate folks across 4000 sq ft.
I think a separate scenarios setup zone would help. Perhaps if the players were
prearranged they could be situated nearer each other from the outset. I know it
wasn't easy for us being some distance from the others.
> > In the meantime I am setting up our proxy server to be accessible over the
> > Internet. I know some other people have already done this and others are
> > planning to. Would anyone be interested in discussing building a network of
> > these public servers?
> >
>
> Not sure what a "network" would do, but it would be very nice to have a
> few more where people can register and test. If set up appropriately,
> two-proxy setups should be easy to run. Since a SIP network cannot run
> on proxies alone, we need some auto-answer SIP agents that would allow
> to test forking-related scenarios.
If the owners of public SIP servers could agree that when they receive requests for
certain domains they will route them to another public SIP server it makes scenarios
easier to set up. In time use of DNS SRV records will hopefully solve this. In the
meantime consider testing the spiral case. If columbia's proxy can be configured to
always route Request URIs for users at ubiquity.net to ubiquity's proxy then I can
register the a SIP URL of [EMAIL PROTECTED] to have a contact of
[EMAIL PROTECTED] with columbia's proxy. Then an INVITE from one of our
UAs via our proxy to [EMAIL PROTECTED] would get sent to columbia's proxy,
which would then rewrite the Request URI as [EMAIL PROTECTED] and send
back to the ubiquity proxy.
One of difficulties encountered trying to set up the advanced proxy scenarios at the
bakeoff was that there seemed to be lot of messing around with REGISTERs trying to
get proxies to know about each other. I think the problem may have been that some
proxy implementations needed to resolve Request-URIs to be able to route requests.
This meant to get them to send to us in a chain of proxies they were essentially
registering our proxy's host IP address as a Contact for the SIP URL being invited.
In our proxy if we receive a request where the Request-URI is not in our domain we go
through an fairly exhaustive procedure of trying to find out where best to send it.
One of these stages is to look at a configurable list of other known proxies. For
example when we tested with columbia we could easily configure our proxy to send on
any requests for users in columbia.edu to Columbia's proxy. This is something others
may want to consider doing as it made setting up complex scenarios using many proxies
much easier. Of course it would be even better if next time we could have DNS SRV and
separate subdomains.
Cheers,
Neil.
--
Ubiquity Software Corporation http://www.ubiquity.net
