Proxy Authentication can fail if there are multiple SRV records about baresip HOT 12 CLOSED

your suggestion makes sense, we shall have a look shortly ..

what is used on the server side btw?

from baresip.

I'm using callcentric.com - I don't know what server software they're using
(likely some customized UAS). I can work around the issue by picking two of
the SRV records and using them as "outbound" and "outbound2" in the
accounts file (i.e. forcing all requests to go there); however, that loses
the benefit of dynamic SRV lookups.

On Sun, May 31, 2015 at 11:55 AM Alfred [email protected] wrote:

your suggestion makes sense, we shall have a look shortly ..

what is used on the server side btw?

—
Reply to this email directly or view it on GitHub
#39 (comment).

from baresip.

baresip works for me all the time, on my home network.

if I query the DNS name the DNS response is always sorted in the same order:

$ host -t srv _sip._udp.callcentric.com
_sip._udp.callcentric.com has SRV record 20 0 5080 alpha13.callcentric.com.
_sip._udp.callcentric.com has SRV record 20 0 5080 alpha19.callcentric.com.
_sip._udp.callcentric.com has SRV record 20 0 5080 alpha9.callcentric.com.
_sip._udp.callcentric.com has SRV record 20 0 5080 alpha17.callcentric.com.
_sip._udp.callcentric.com has SRV record 20 0 5080 alpha1.callcentric.com.
_sip._udp.callcentric.com has SRV record 20 0 5080 alpha18.callcentric.com.
_sip._udp.callcentric.com has SRV record 20 0 5080 alpha15.callcentric.com.

but if I run the same command from a different network (e.g. 3G, Internet cafe)
then the order is always random and different.

A quick work around is to save the IP-address from the 401/407 response and
use that IP-address as a SIP route for the 2nd REGISTER. I have a local patch
that works, will send it out a bit later..

from baresip.

hey Andy,

could you please test this patch:

https://github.com/alfredh/patches/blob/master/re-sip-dialog-set-route.patch

the patch is against libre (latest version).

when the first 401/407 response arrives, libre SIP stack will then save the source address
on the dialog object, and re-use it as route for further outgoing SIP requests.

if we want to adopt this as a permanent solution I am not sure, but it would be nice
to test the patch first on your host/network/provider and check if things are improved :)

/alfred

from baresip.

Even on my home network, the records are returned in an unpredictable
order. (Also, some services such as
http://mxtoolbox.com/SuperTool.aspx?action=srv%3a_sip._udp.callcentric.com&run=toolpage#
show the records in a different order each time the lookup is done).

The patch is working fine. I tried making a few calls after applying the
patch, and can see from the network traces that the second INVITE does
indeed get send to the same server, and the proxy auth succeeds. Excellent!

from baresip.

Thanks for the testing, Andy!

Now I just need to review the patch again, and do some more testing.

from baresip.

Having a configuration option for letting keeping an authenticated request to the same server that challenged could be beneficial. I don't believe Asterisk has a way to share nonces between servers, like Kamailio can do, so such a config option may help users with Asterisk clusters. Making it the default would not be a good thing.

from baresip.

Why is making it the default not a good thing? Even the Kamailio documentation states:

If you use multiple servers in your installation, and would like to authenticate on the second server against the nonce generated at the first one its necessary to explicitly set the secret to the same value on all servers. However, as the use of a shared (and fixed) secret as nonce is insecure, it is much better is to stay with the default. Any clients should send the authenticated request to the server that issued the challenge.

from baresip.

here is a SIP trace from baresip registering with callcentric.com (vanilla code, no patches).
This DNS-Server was used to force rotation of SRV entries:

dns_server 87.215.30.26:53

#
U 10.0.0.2:33527 -> 204.11.192.169:5080
REGISTER sip:callcentric.com SIP/2.0.
Via: SIP/2.0/UDP 10.0.0.2:33527;branch=z9hG4bKfb4b2d8a2b069ee3;rport.
Contact: <sip:[email protected]:33527>;expires=3698;+sip.instance="<urn:uuid:39b3cc1f-263e-4f9c-b73e-669157069eb9>".
Max-Forwards: 70.
To: <sip:[email protected]>.
From: <sip:[email protected]>;tag=d55f870f97d2fd6a.
Call-ID: 05c4635e73ef71f9.
CSeq: 3059 REGISTER.
User-Agent: baresip v0.4.18 (x86_64/linux).
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE.
Content-Length: 0.
.

#
U 204.11.192.169:5080 -> 10.0.0.2:33527
SIP/2.0 407 Proxy Authentication Required.
v: SIP/2.0/UDP 10.0.0.2:33527;branch=z9hG4bKfb4b2d8a2b069ee3;rport=34587;received=91.64.97.108.
f: <sip:[email protected]>;tag=d55f870f97d2fd6a.
t: <sip:[email protected]>.
i: 05c4635e73ef71f9.
CSeq: 3059 REGISTER.
Proxy-Authenticate: Digest realm="callcentric.com", domain="sip:callcentric.com", nonce="8f9844b6dc61cd3bec7a626af9350048", opaque="", stale=TRUE, algorithm=MD5.
l: 0.
.

#
U 10.0.0.2:33527 -> 204.11.192.163:5080
REGISTER sip:callcentric.com SIP/2.0.
Via: SIP/2.0/UDP 10.0.0.2:33527;branch=z9hG4bK6472a80eed6635e4;rport.
Contact: <sip:[email protected]:33527>;expires=3698;+sip.instance="<urn:uuid:39b3cc1f-263e-4f9c-b73e-669157069eb9>".
Max-Forwards: 70.
Proxy-Authorization: Digest username="17772830447", realm="callcentric.com", nonce="8f9844b6dc61cd3bec7a626af9350048", uri="sip:callcentric.com", response="6264700cfbf8396aab8dfcd72b984064".
To: <sip:[email protected]>.
From: <sip:[email protected]>;tag=d55f870f97d2fd6a.
Call-ID: 05c4635e73ef71f9.
CSeq: 3060 REGISTER.
User-Agent: baresip v0.4.18 (x86_64/linux).
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE.
Content-Length: 0.
.

#
U 204.11.192.163:5080 -> 10.0.0.2:33527
SIP/2.0 407 Proxy Authentication Required.
v: SIP/2.0/UDP 10.0.0.2:33527;branch=z9hG4bK6472a80eed6635e4;rport=34587;received=91.64.97.108.
f: <sip:[email protected]>;tag=d55f870f97d2fd6a.
t: <sip:[email protected]>.
i: 05c4635e73ef71f9.
CSeq: 3060 REGISTER.
Proxy-Authenticate: Digest realm="callcentric.com", domain="sip:callcentric.com", nonce="d4167e2e1f53025a4a27d5903774c6a9", opaque="", stale=TRUE, algorithm=MD5.
l: 0.

from baresip.

I spoke with a Senior technical staff at Callcentric a few days ago, and discussed their
setup. He told me that all SIP-Servers are using different secret/nonce values and that
a SIP client talking to callcentric.com must "lock" to the first SIP-server instance that
replies with 401/407.

I am trying to get to the bottom of this. There is also a nice debate on the Kamailio list:

http://lists.sip-router.org/pipermail/sr-users/2016-April/092506.html

from baresip.

Hello @AndyJRobinson

We have just released a new version of libre (version 0.4.17) which includes
a fix for multiple DNS records. SIP domains with multiple DNS records are sorted
by a key which is calculated from a hash of the SIP from uri. All requests
incl. REGISTER and INVITE should be sent to the same SIP-server instance.

Could you please test if this working with Call-Centric:

1. install libre http://www.creytiv.com/pub/re-0.4.17.tar.gz
2. install baresip from github (master@HEAD).

thanks for any feedback

from baresip.

I have verified that latest baresip and libre v0.4.17 works with Call-Centric,
both register and invite. If someone has any problems, feel free to re-open this bug
or to create another one :)

from baresip.