Hi, On Nov 24, 2011, at 2:48 AM, Brandon W. Yuille wrote:
> 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. > Imagine that instead of a REFER we were talking about an OPTIONS request. Of course it's valid, many devices use if for in-dialog ping and you can't wait to handle it just because there is a reINVITE in progress. I'd say there is nothing special bout the REFER, so it should just be handled. > 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. > Agreed. Regards, -- Saúl Ibarra Corretgé AG Projects _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
