[pjsip] 3PCC transfer implementation

Joegen E. Baclor joegen.baclor at gmail.com
Wed Nov 14 06:51:26 EST 2007

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

More information about the pjsip mailing list