Olle, You're right. I missed one thing when I concluded that this was an INVITE glare condition, which is that when the UAC and UAS dialogs are matched they're compared with respect to their LOCAL and REMOTE tags as opposed to the To and From tags. The LOCAL and REMOTE tags will get filled either with To or From tag depending on whether you're looking at the dialog from the UAC or from the UAS. So, in this case you'll have two dialogs in Asterisk and they'll have the same Call-Id but their tags will be swapped.
Do you think Asterisk dialog matching is coded to handle this? While we've not seen a trace yet, it'd seem like we're missing something because we're sending back a 491. Raj On Dec 23, 2007 2:21 AM, Johansson Olle E <[EMAIL PROTECTED]> wrote: > > 23 dec 2007 kl. 01.45 skrev Raj Jain: > > > You can not do this. You can not have an INVITE that Asterisk > > originated enter back into Asterisk. Technically this is not a loop, > > but this is an INVITE glare and the way Asterisk is reacting is > > correct. > > > > You'll need to change the Call-Id of the INVITE that goes into > > Asterisk (a proxy can not do that so you'll need a B2BUA), or else > > you can do something like what Olle suggested. > > I don't really agree here Raj. Of course you can send an INVITE to an > URI hosted by the proxy and the location table points back to one or > several URI's in the same Asterisk server. > > /O > > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
_______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
