[asterisk-bugs] [JIRA] Commented: (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)

[Michael L. Young (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198203#comment-198203 ] 

Michael L. Young commented on ASTERISK-20539:
---------------------------------------------

Can you try to reproduce with a recent version of Asterisk 1.8.x?  1.8.17 is the latest version and in looking through the ChangeLog, I see some bug fixes around this area of the code.  Worth a shot since your bug might already have been fixed.

> 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