On 11/23/2011 07:31 AM, Brez Borland wrote: > On Tue, Nov 22, 2011 at 11:27 PM, Brez Borland<[email protected]> wrote: > >> Hi Mark, >> >> I think that INVITE has to be answered. This is what "RFC3261, Section >> 14.1 UAC Behavior" says: >> >> Note that a UAC MUST NOT initiate a new INVITE transaction within a >> dialog while another INVITE transaction is in progress in >> either direction. >> >> From here I deduct that in Adam's case his INVITE transaction is pending, >> and he cannot act upon the REFER (by initializing another INVITE) while he >> is waiting for that INVITE to finish. >> >> > *apologies, I meant to say re-INVITE in all the above". > > Therefore, the UAS should not issue the REFER in the first place, but > rather complete that re-INVITE, and when no INVITE/re-INVITE are in > progress - send the REFER. > _______________________________________________ >
You can't really have a handle on this. It's a race. The REFER could have been sent prior to the REFERor receiving the INVITE. Although, I know you meant that in your case it is a constant intent, the correct behavior is to still handle REFER and INVITE as separate transactions. You can of course reject the REFER or you can send it a 202/initial-NOTIFY (100 Trying) then base subsequent state changes on the actual result of the INVITE. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
