[pjsip] 3PCC transfer implementation

Benny Prijono bennylp at pjsip.org
Tue Nov 13 23:02:42 EST 2007


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





More information about the pjsip mailing list