> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:asterisk-users- > [EMAIL PROTECTED] On Behalf Of Jared Smith > Sent: Thursday, June 07, 2007 10:26 AM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] DUNDi and reinvites... > > On 6/7/07, Douglas Garstang <[EMAIL PROTECTED]> wrote: > > If I am using DUNDi for redundancy in a cluster, when Phone1 makes a > call to > > Phone2, both Asterisk A and B will be in the RTP stream: > > Correct so far... although once the call is made, it's no longer a > DUNDi question, and is simply a signalling question. (In other words, > DUNDi is used for Phone 1 to figure out how to connect to Phone 2, but > after it's figured that out, it's a normal SIP or IAX call between > Asterisk A and Asterisk B.)
Hi Jared. Understood. > > > Is there a way configure re-invites in this situation so that either > > Asterisk A or B drops out of the call, and there's only one Asterisk box > > between Phone1 and Phone2? Like this... > > Yes, as long as the protocols are all the same. If Phone1 is talking > SIP to Asterisk A and Asterisk A is talking IAX to Asterisk B and > Asterisk B is talking SIP to Phone 2, then it won't happen. But > assuming everything is using the same transport, they'll happen. In > fact, if re-invites are enabled on both Asterisk servers, and the two > phones can communicate directly, you can re-invite *both* Asterisk > servers out of the middle of the call. I figured the protocols would have to be the same. The phones are SIP based, so I tried to get DUNDi to work with SIP. That's where I hit snags. The INVITE coming from Asterisk 1 has the original phone's From: address, because it's much easier for Asterisk 2 to accept calls from Asterisk 1 based on the IP address. However, because the INVITE still has the original phones FROM: tag, Asterisk matches it against it's own copy of Phone 1's sip entry, rather than the entry for Asterisk 1, and then sends a 407 proxy Auth message back to the Asterisk 1, who doesn't know what to with it. Another, much uglier approach, is to change the From Address that Asterisk 1 sends the INVITE with. However, then we'd need to add extra SIP headers to the INVITE going out from Asterisk 1. Asterisk two would authenticate against those and pluck out the extra SIP headers to get the original caller id. I also tried setting the username/secret on Asterisk 1 for it's trunk to Asterisk 2, thinking that the From: and the auth credentials would be different, but Asterisk threw a fit when the From: did not match the digest id. What's wrong with that? Doug _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users