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.
>
> >
> > However, this flow could work either way.
> >
> > As for the RTP flow between B and C, it is initially set up so that B
> > can tell C
> > "I'm going to transfer A to you - hold on." Since this is an attend
> > transfer
> > flow, B should maintain sessions with both A and C in the event of a
> > failure.
> Yes but why say "hold-on" to C and then ask C to call A . B could ask A to call
> C.
> > Once B is notified that the transfer has succeeded, a BYE is sent
> > tearing down
> > this session. Note that B could put C on hold before sending the REFER.
> >
> > If you have an alternative flow for this example, lets discuss.
> >
> > Thanks,
> > Alan Johnston
> > WorldCom
> > sip:[EMAIL PROTECTED]
> >
> > [EMAIL PROTECTED] wrote:
> >
> > > Sirs,
> > >
> > > I have questions regarding I-D draft-ietf-sip-service-examples-01.txt.
> > > In the the "attended transfer" why B asks C to call A whereas A has
> > called B.
> > > Could i imagine that after B having in communication with C, B puts C
> > on
> > > hold and asks A to call C?
> > > It could solve some Billing Pbs. A would stay the originator of the
> > call and
> > > could be charged .
> > >
> > > In the same examples: What is the RTP flow kept between B and C for ?
> > >
> > > Thank you for your answers,
> > >
> > > pm
> > > _______________________________________________
> > > Sip-implementors mailing list
> > > [EMAIL PROTECTED]
> > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
> >
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
