Joegen E. Baclor wrote: > Benny Prijono wrote: >> Hi Anshuman, >> >> this is currently pretty hard to achieve with pjsip, as ACK will be >> sent automatically by the invite session layer upon receiving 2xx >> response. But I like your idea to add the ability to disable this >> automatic ACK sending and enabling application to send it manually, >> so maybe we can elaborate more on this. Can you explain more on why >> did you think this approach is not very extensible? >> > > Although it is most definitely a good idea to have ACK for 200 OK be > handled by the application layer, I do not see its significance in a > B2BUA as mentioned in the original post. It will only be significant if > the implementation is a Proxy. In which case, ACK needs to be processed > hop by hop to assure that every entity in the call path know that the > ultimate endpoint has received the 200 Ok. It would be interesting > to know if there are other reasons. Hi Joegen, thanks for jumping in the discussion. I'm sure you have much much more experience with B2BUA than most of us, so your inputs on this would be great! Regarding 3PCC, I was thinking of the scenarios in 3PCC best practices RFC (http://www.ietf.org/rfc/rfc3725.txt), and I see that in these scenarios we always need to delay the ACK until we have the answer from the other side. I was assuming that although it's a B2BUA, we want the RTP to flow end to end (i.e. the controller doesn't want to proxy the RTP). Or do you have other 3PCC scenarios in mind that doesn't require delaying ACK? thanks, -benny
