[asterisk-bugs] [JIRA] Updated: (ASTERISK-20539) When the peer for an outbound call is defined by a round-robin DNS, the response to the SIP 407 challenge goes to a different server than the original SIP INVITE (and from which the 407 came)
Norman Henderson (JIRA)
noreply at issues.asterisk.org
Tue Oct 9 09:19:27 CDT 2012
[ https://issues.asterisk.org/jira/browse/ASTERISK-20539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Norman Henderson updated ASTERISK-20539:
----------------------------------------
Attachment: extract
core set debug 5; sip set debug on
my user, IP, DNS and tel# have been globally altered for security reasons
> When the peer for an outbound call is defined by a round-robin DNS, the response to the SIP 407 challenge goes to a different server than the original SIP INVITE (and from which the 407 came)
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ASTERISK-20539
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-20539
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_sip/General
> Affects Versions: 1.8.11.1
> Environment: Asterisk 1.8.11.1-1digium1~lucid built by pbuilder @ nighthawk on a x86_64 running Linux on 2012-04-24 15:31:40 UTC
> Linux VM-CEML 2.6.32-43-server #97-Ubuntu SMP Wed Sep 5 16:56:41 UTC 2012 x86_64 GNU/Linux - Ubuntu 10.04.4 LTS - fully updated
> FreePBX 2.10.1.2 - fully updated
> Reporter: Norman Henderson
> Attachments: extract
>
>
> outbound.vitelity.net is a round-robin DNS name with several servers. The SIP trunk is defined as:
> [vitel-outfail]
> disallow=all
> username=username
> type=peer
> trustrpid=yes
> tos=ef
> sendrpid=yes
> secret=secret
> qualify=yes
> insecure=port,invite
> host=outbound.vitelity.net
> fromuser=username
> dtmfmode=auto
> canreinvite=no
> allow=g729
> context=from-trunk-sip-vitel-outfail
> See debug file:
> Line 1321: Asterisk sends INVITE to the first address it got from the DNS lookup, 64.2.142.190.
> Line 1360: the provider responds from the same IP with 407 Proxy Authentication Required
> Line 1391ff: Asterisk does a new DNS lookup, gets a different address 64.2.142.188, and sends the digest credentials there.
> The provider says this is non-RFC-compliant (and indeed doesn't make much sense). Their server sends back another 407 from 64.2.142.188 and the cycle repeats a few times before Asterisk gives up.
> There is a mystery in that the system used to work (or perhaps the problem was just more intermittent and blamed on a bad 'net connection). I am not aware of changes to my system and the provider says his didn't change either during the time window this went from working (usually at least) to consistently failing.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list