RE: [SIP] 3PCC and REFER method

I'd worry about a third-party directing an end-point to establish a call.
In particular, there are interesting billing issues (although one could say
this solves a billing issue).  For example, if the HTTP server sends the "Go
call the controller" message to Terminal A, the network sees a call
origination from Terminal A.  That may, or may not, be the intention of the
service provider.

What precisely is the issue with having the controller issuing the INVITEs
to A and B?

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of
> Javier_Ferreiro_Garcia/UT03329/PLATAFORMAS_DE_SERVICIOS/TSM@tsm.es
> Sent: Friday, December 29, 2000 6:00 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] 3PCC and REFER method
>
>
> Hi
> I would like to open again the issue discussed in
> http://lists.bell-labs.com/pipermail/sip/2000q4/004739.html
>
> >>What happens when there is not an active SIP (INVITE) session
> between the
> >>referer and referee ? Sending an INVITE in this case may have unwanted
> >>effects (like initiating a call). Are you proposing that either a) you
> would
> >>only send the INVITE/BYE if a corresponding SIP (INVITE) sessions exists
> or
> >>b) that REFERS are not allowed outside of a SIP session?
>
> >  What does a REFER outside of a session mean?
>
> and apply this idea to the scenario proposed in
> draft-rosenberg-sip-3pcc-01.txt Figure 1 and specifically the
> example included for Click-to-dial application.
>
> In this alternative scenario for Click-to-dial, the controller, after
> receiving the request via HTTP, do not INVITE both A and B, but
> rather send
> a REFER to A, asking A to INVITE the CONTROLER ITSELF. When the controller
> receives the INVITE SDP A from A, checks in its internal database who is
> supposed to be contacted by A (in this case B) and sends INVITE
> SDP A to B.
> In this case I think the re-INVITE loop could be avoided by  applying this
> scenario which is more similar to a normal INVITE between two parties.
>
> In this alternative scenario the referer (i.e. the controller) and the
> referee (i.e. the web-surfer) are OUTSIDE of a SIP session, but INSIDE an
> HTTP session. It could also be decided the referee to be the IP phone from
> the customer service representative, if the web-surfer IP phone
> either does
> not support REFER or is a PSTN endpoint.
>
> The reason to include as content of Refer-To header not B but the
> controller itself is to let the controller do its job in a more
> general way
> (i.e. imagine click-to-dial + mid-call-announcement)
>
> If the scenario is not the one described for Click-to-dial, but for Mid
> Call AnnouncementCapability, the controller does not either set
> up the call
> to A or send the REFER method to A, but rather receive the INVITE from A
> and act as a "termination and reinitiation point" for control purposes
> (i.e. disconnect and reconnect A to a media server under certain
> conditions) as defined in draft-rosenberg-sip-3pcc-01.txt
[snip]

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip