[Asterisk-Dev] chan_sip: handling "Multiple Choice"

[Bruno Rocha]

I've noticed a strange behavior in chan_sip when receiving a "300 
Multiple choice" response.
I guess Asterisk is unable to handle it correctly.

Example packet captured when using sipdiscount:

SIP/2.0 300 Multiple choice
Via: SIP/2.0/UDP 81.92.197.134:5060;branch=z9hG4bK77998806;rport
From: <sip:myaccount at sip1.sipdiscount.com>;tag=as79594a6a
To: <sip:myaccount at sip1.sipdiscount.com>
Contact: 
sip:194.120.0.211:5060,sip:194.221.62.211:5060,sip:80.239.235.211:5060
Call-ID: 436a96e554d1f8603161875446bed1a3 at mydomain.tld
CSeq: 648 REGISTER
User-Agent: (Very nice Sip Registrar Server)
Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS
Content-Length: 0


Asterisk LOGS: (promiscredir = no)

logger.c:     -- Called sipdiscount/00351123456789
logger.c:     -- Got SIP response 300 "Multiple choice" back from 
194.221.62.211
logger.c:     -- Now forwarding SIP/user-d7c6 to 
'Local/194.221.62.201:5060,sip:194.120.0.201:5060,sip:80.239.235.201:5060 at from-sip-provider' 
(thanks to SIP/sipdiscount-0a9c)
chan_local.c: No such extension/context 
194.221.62.201:5060,sip:194.120.0.201:5060,sip:80.239.235.201:5060 at from-sip-pro 
creating local channel
app_dial.c: Unable to create local channel for call forward to 
'Local/194.221.62.201:5060,sip:194.120.0.201:5060,sip:80.239.235.201:5060 at from-sip-provider' 
(cause = 0)
logger.c:   == Everyone is busy/congested at this time (1:0/0/1)


Asterisk LOGS: (promiscredir = yes)

logger.c:     -- Called sipdiscount/00351123456789
logger.c:     -- Got SIP response 300 "Multiple choice" back from 
80.239.235.201
logger.c:     -- Now forwarding SIP/user-e634 to 
'SIP/194.120.0.211:5060,sip:194.221.62.211:5060,sip:80.239.235.211:5060' 
(thanks to SIP/sipdiscount-797f)
chan_sip.c: Failed to authenticate on INVITE to '"My Name" 
<sip:user at mydomain.tld>;tag=as46ed4275'
logger.c:     -- 
SIP/194.120.0.211:5060,sip:194.221.62.211:5060,sip:80.239.235.211:5060-933e 
is circuit-busy
logger.c:   == Everyone is busy/congested at this time (1:0/1/0)


Is this a known limitation?
Any workaround available?

Regards,

Bruno Rocha