Benny Prijono wrote: > 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). > Ooops, yeah i've missed that as a valid reason why the app layer needs a handle on the ACK. However, for a 3PCC call transfer where the offer is already known based on the previously established session, there is no need to send a blank invite in this case. The 3PCC app may just send the active SDP in whichever leg is being transfered. Once a new codec is negotiated from the 200 OK, the 3pcc layer can just send a reinvite to the transferred call to notify it about the new codec, address and port chosen by the new leg. Although, this approach is somehow dangerous since the reInvited UA may decide to change the port in the answer different to what was previously offered. I yet have to see a UA that behaves this way but since it's not controlled by any specs, we can't really complain if one person decided to do it that way. In addition to the dangers of 3PCC call transfer is that some user agents ignore RTP packets whose ssrc has changed. I have seen implementation that throws away rtp packets with different ssrc than what it was previous receiving. This justifies proxying media for such cases since the media proxy can always send the same ssrc to a particular leg even if the source of the packet has already changed. > Or do you have other 3PCC scenarios in mind that doesn't require > delaying ACK? > In fact there is. One can send an INVITE with a held media which is case II (just pulled it from mem) as i remember it from the specs. There are a lot of implementation that do not support late media (blank invites). One good reason why we may consider staying away from case I. In a perfect world, however, case I is best practice in my opinion and will produce the most desired results. I guess that leaves you no choice but the expose ACK to the application layer ;-) > thanks, > -benny > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > >
