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

Robert Dyck rob.dyck at telus.net
Mon Oct 8 00:25:32 CEST 2007


On Sunday 07 October 2007, Christian Schlatter wrote:
> While there is are no NAPTR records for callcentric.com, there are SRV
> records:
>
> ;; ANSWER SECTION:
> _sip._udp.callcentric.com. 331  IN      SRV     10 5 5080
> alpha1.callcentric.com.
> _sip._udp.callcentric.com. 331  IN      SRV     10 5 5080
> alpha2.callcentric.com.
> _sip._udp.callcentric.com. 331  IN      SRV     10 5 5060
> alpha1.callcentric.com.
> _sip._udp.callcentric.com. 331  IN      SRV     10 5 5060
> alpha2.callcentric.com.
>
Using openser config to force alphaX.callcentric.com had the same effect as 
using a hard coded IP address, namely no response.

> Your trace doesn't show any DNS SRV queries. What version of openser are
> you using? Versions before 1.1 didn't support NAPTR/SRV queries.

I am using a rather old version of openser. My configuration was inspired by 
the Milkfish project. They have a patched version of nathelper that allows 
one to specify the address when mangling CONTACT. It does in fact support SRV 
queries. I think it is version 1.0. While exploring the code I discovered 
that if the UA explicitly sends to a port, openser will not use SRV. In the 
trace I sent the UA specifies a port. If the UA does not specify a port the 
version of openser that I am using will do SRV queries.

Do recent versions of openser allow fix_nated_contact("a.b.c.d")?

>
> Instead of hard-coding the outbound proxy to the callcentric proxy IP
> address, you could instead use either 'alpha1.callcentric.com' or
> 'alpha2.callcentric.com'.
>
> /Christian
>
> 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.
> >
> > 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.
> >
> > 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?
> >
> > 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






More information about the Users mailing list