I thought he said the REFER was in response to his reINVITE, not the other way around:
"I am seeing a scenario for an established call in which an outbound reINVITE is being done, the far end is sending a TRYING and then a REFER immediately." As I said before this seems to be wrong, especially since the far side has received it replied back with a 100 Trying, then sends a REFER request. The far side should complete the reINVITE with a final response, then send the REFER. I think Brez's response to this sums it up. In any event, you could just simply handle the REFER. Looking at my own implementation having never thought about this scenario, it will just handle the REFER and forget that it ever sent the reINVITE if the REFER succeeds before the final response to the reINVITE is received. In other words, I would think your implementation shouldn't be doing anything final anyway until the final response to that reINVITE is received. Brandon On 11/23/2011 07:10 AM, Saul Ibarra Corretge wrote: > Hi, > > >> 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. >> > I'd say it's perfectly valid. Nobody forces you to generate an INVITE in > response to a REFER immediately. So I'd reply with 202 to that REFER, send > back a NOTIFY with a 100 Trying sipfrag payload and wait for the reINVITE > transaction to finish before proceeding. > > > Regards, > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
