RE: [SIP] 3PCC and REFER method

[<[e-mail]>]

Thank you for your reply, Eric. Comments below

>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.

IMHO I do not find the billing issue as a cons for using REFER to replace
the scenario of generating two outbound calls from the controller. I cannot
imagine a SIP based network billing policy less flexible than the one
currently offered in the traditional telecom environment -i.e. with IN and
800 numbers. Anyway, in case of dealing with such a restrictive billing
policy, the controller can send the REFER to Terminal B instead, and it
makes sense with the Click-to-dial example, since the web portal will a)
own also the service representative/customer care site b) have a bussiness
relationship with the company that runs the service representative/customer
care site.

The main reason for my suggestion is to avoid the complexities related to
make the controller try to stablish two outbound calls. In the cellular
operator I work for, I just can think on one such a service currently
deployed, that is USSD-to-dial. The cellular prepaid customers when
roaming, and since the charging policy MUST be applied in real time, are
not allowed to perform explicit outbound calls (due to barrings included in
their user profile) since these calls will not be charged in the Home
Prepaid Apliccation Server; so the prepaid user is forced to send a
USSD/SMS message to the Home Prepaid Application Server including the B
number in the body text. The Home Prepaid.. acts as a controller and makes
two outbound calls to terminal B and terminal A. Due to billing constraints
-both A leg and B leg are charged to the caller, A leg is always
international, and B leg is 70% likely to belong to the home country-, the
controller makes the outbound call to B first, and if B is not reachable
(busy, disconnected, network congestion, etc.) notifies A number -tipically
SMS based-. If, and only if the second leg is properly stablished, the call
to A is performed.
This is currently the only way to perform calls for prepaid roamers in many
countries, so they have to deal with really curious scenarios:

a) the A user gets annoied when receiving a failure notification after
20-60 seconds waiting; people are more used to listen busy tones, and tend
to think the service offered is failing, it is clearly a "mediterranean"
psicological attitude :)

b)if the B number is an IVR menu (tipically when you try to reach your own
voice mailbox) since the B leg is the first leg to be stablished, the first
piece of information provided by the IVR menu is lost (imagine losing
"Press 1 to listen your messages, press 2 to change your settings")

c) User A may receive an inbound call while waiting for the controller to
stablish the A leg, i.e. busy; and reject the attempt performed by the
controller. Who should pay for the B leg already stablished? (b. t. w. a
"nice" hacking with the proposed scenario for click-to-dial is to answer a
different SDP to the RE-INVITE at the A leg as warned in
draft-rosenberg-sip-3pcc-01.txt page 12; Amazon customer representative
could be K.O. quite fast after several attacks)

It sounds to me more natural, from the A user point of view, to receive a
REFER -this means the SIP browser will interact with A in order to ask for
permission to make the outbound call- and follow the progress of the call
to B through the controller.

-b.t.w. there is a new approach to solve this prepaid roaming problem based
on Wireless IN (CAMEL) standards but this is not the point discussed here-

Anyway, there must be any other reasons not to use REFER in the 3PCC
scenario rather than billing ... or is it billing and I am wrong?

regards
Javier


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

>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]]On Behalf Of
>> Javier_Ferreiro_Garcia/UT03329/PLATAFORMAS_DE_SERVICIOS/[e-mail]
>> Sent: Friday, December 29, 2000 6:00 AM
>> To: [e-mail]
>> 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
[e-mail]
http://lists.bell-labs.com/mailman/listinfo/sip




_______________________________________________
SIP mailing list
[e-mail]
http://lists.bell-labs.com/mailman/listinfo/sip