Quoting Alan Johnston <[EMAIL PROTECTED]>:
> Patrick,
>
> See my comments below.
>
> Thanks,
> Alan Johnston
> WorldCom
> sip:[EMAIL PROTECTED]
>
> [EMAIL PROTECTED] wrote:
>
> > Quoting Alan Johnston <[EMAIL PROTECTED]>:
> >
> > > Patrick,
> > >
> > > Thanks for your questions on the draft. The flow could be done
> either
> > > way, with
> > > B sending the REFER to either C or A.
> > >
> > > There are two objectives in this flow - that after the REFER is
> sent,
> > > neither A
> > > or C's phone should ring for the resulting INVITE, and that the
> > > recipient of the
> > > INVITE can determine that the resulting session between A and C
> should
> > > replace
> > > the existing session between A and B. I thought that sending the
> REFER
> > > to C and
> > > possibly including a Replaces header in the resulting INVITE from C
> to A
> > > does
> > > this rather cleanly.
> > See remarks below
> > >
> > > As for billing issues, I think this flow matches the existing PSTN
> if
> > > the
> > > transfer occurs behind a PBX. For example, if A calls B, then B
> signals
> > > the PBX
> > > to transfer A to C, the call would be hairpined at the PBX, and the
> B to
> > > C leg
> > > would be billed to B.
> >
> > I am not sure that a PBX works like that.
> >
>
> You are probably thinking of Q.SIG which is not used here in North
> America, which
> may work without hairpinning the call at the PBX. The only other analog
> to REFER
> in the PSTN is a release link trunk, but this assumes that the transfer
> is
> implemented in the network.
>
> If you sent a REFER from B to C, how would you let C know not to ring
> the phone and
> to drop the connection to B? I couldn't see how to do this cleanly,
> which is why
> the REFER goes in the other direction.
Sorry i am lost because it is what you are doing in your examples (send a REFER
from B to C).
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
