[OpenSER-Users] Problem with otg proxy when service provider has two registrars

[Robert Dyck]

Thank you so much for the prompt and thorough replies.

Of the two options you offered I think that configuring my caching DNS server 
looks about the best. There exists a small possibility that the IP address 
could change and not refresh the name server before a request to the 
registrar is launched.

The ideal solution would be convincing Callcentric to not use round robin 
selection.

Thanks again
Rob D

On Sunday 07 October 2007, Christian Schlatter wrote:
> Robert Dyck wrote:
> > I had already tried configuring the UA with the address of one of the
> > servers ( both IP and domain name ) as well as altering the openser
> > config to force the address. The peculiar thing there is that the
> > registrar does not challenge or even respond at all. It would seem that
> > it ignores REGISTER requests that do not have callcentric.com as the
> > domain name and realm.
>
> Yes, that seems to be the case.
>
> > The UA can register with this provider without difficulty when the UA is
> > configured to use STUN and no outgoing proxy. The UA does not do a second
> > DNS lookup. It simply uses the same address for both requests.
>
> Ok, the credentials seem to be fine.
>
> > When the UA receives the challenge does it not use the received nonce to
> > encrypt its credentials? I have to admit my knowledge of that subject is
> > shakey. And would this not have to be delivered to the same server that
> > sent the nonce?
>
> You are right, although the nonce is included in the response to a
> challenge, the registrar obviously has to make sure that it matches the
> one sent in the challenge. Otherwise replay attacks would be easily
> possible.
>
> So the problem boils down to the fact that your SIP provider is using
> round-robin DNS instead of NAPTR/SRV. This causes your openser to send
> the requests to different hosts.
>
> The trace you sent me indicates that you're using a local DNS cache
> server. One option would be to configure this server to not to do
> round-robin for "callcentric.com". E.g. with BIND this can be achieved
> by adding
>
> options {
>    rrset-order {
>      name "callcentric.com" order fixed;
>    };
> }
>
> The callcentric.com DNS record has a TTL of 30 minutes, so the target IP
> address could potentially change every 30 minutes.
>
> Another option would be to hard-code the target IP address for REGISTER
> requests in the openser config, like
>
> if (is_method("REGISTER") && ($rd == "callcentric.com"))
> {
>    t_relay("udp:204.11.192.22:5060");
> }
>
> which has the disadvantage that an IP change for callcentric.com would
> disable the callcentric registration service.
>
>
> /Christian
>
> > On Saturday 06 October 2007, you wrote:
> >> Robert Dyck wrote:
> >>> I am more familiar with ethereal. I hope that is OK. Also I have not
> >>> edited the dumps so I am sending them privately. Attached are brief and
> >>> detailed dumps from ethereal.
> >>
> >> Your SIP provider is using DNS round-robin which is why openser is
> >> forwarding the requests to different IP addresses. This is the first
> >> provider I see that is doing DNS RR, this is rather unusual and not what
> >> is described by the SIP RFCs.
> >>
> >> Nevertheless, I still believe that your problem is related to wrong
> >> credentials. Both provider registrars should accept your REGISTER with
> >> Proxy-Auth header.
> >>
> >> You could also configure your SIP client with 204.11.192.22 instead of
> >> the provider's hostname, this will disable DNS RR and let openser
> >> forward the request always to the same host.
> >>
> >> /Christian
> >>
> >>> On Saturday 06 October 2007, you wrote:
> >>>> Robert Dyck wrote:
> >>>>> The second registrar does not send an error code, it simply issues
> >>>>> its own challenge. Openser is definitely alternating between
> >>>>> registrars. It does not send the credentials to the same registrar
> >>>>> that requested them.
> >>>>>
> >>>>> I could send a trace if it would be helpful.
> >>>>
> >>>> Yes, that would be helpful, I'd also like to have a look at the DNS
> >>>> traffic. Can you do
> >>>>
> >>>> tcpdump -i any -s 1500 -w /tmp/trace.pcap
> >>>>
> >>>> /Christian