I guess there are also issues once the call transfer is completed.
Once the 3pcc transfer is completed, most of the signalling would need to be
end to end (between the endpoints) with the controller passing requests (and
responses) from leg to the other. This requires that there is no local
handling of reinvites,updates etc. Would this not require exposing incoming
requests also to the application? I think a 3pcc call would need a different
state machine for the handling of requests.
Can we not have a pjsip_inv_set_3pcc_mode(inv_session, peerdialog) like
api that can be invoked by the application on a invite session to change how
subsequent requests are handled in the session . The invite session could
define a different invite state handler for 3pcc scenario which the session
uses once the 3pcc mode is set
e.g
void (*thirdpcc_inv_state_handler[])( pjsip_inv_session *inv, pjsip_event
*e) =
{
&thirdpcc_on_inv_state_null,
&thirdpcc_on_inv_state_calling,
&thirdpcc_on_inv_state_incoming,
&thirdpcc_on_inv_state_early,
&thirdpcc_on_inv_state_connecting,
&thirdpcc_on_inv_state_confirmed,
&thirdpcc_on_inv_state_disconnected,
};
This is probably close to writing a 3pcc module. The reason is that I am
not sure we can reuse the existing invite session to support both 3pcc and
normal scenarios in the application.
-Amit
On 11/14/07, Joegen E. Baclor <joegen.baclor at gmail.com> wrote:
>
> 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
> >
> >
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20071116/8e125bfa/attachment.html
