Am 03.03.2009 9:07 Uhr, schrieb Avasarala Ranjit-A20990:
Consider the scenario
Alice makes call to Bob. So Bob receives the INVITE from Alice. Now if Bob does not want to answer the call from Alice and instead wishes to block Alice, Bob can send a CANCEL with Reason header with protocol value as "block".
Sure Bob could send such a CANCEL, but nothing would happen if all other
SIP network elements have implemented the SIP related RFCs which I know.
As you wrote in your previous mail only the originator of an INVITE
sends a CANCEL to terminate a not yet established call, so Alice in this
scenario.
Bob would/should send simply send a 4xx response to reject the incoming
call.
After reading the mails again I thought maybe your intention was to use
a CANCEL in the following scenario:
a 3PCC application, lets say a conference service, calls Alice at a
given time to initiate the scheduled call. When Alices picks up the
phone the 3PCC application will call Bob (and maybe more participants).
But now Alice is currently in a more important meeting and wants to
block this conference call for 30 minutes.
As the 3PCC acts on behalf of Alice you could think that Alice would
need to send a CANCEL here to prevent that the call gets established.
But this assumption is wrong. Again only the 3PCC application could send
a CANCEL in this scenario. Alice would simply reject the incoming call
with 4xx reponse to block it for some time.
So if you do not come up with some other scenario where the originator
transfers blocking information via a CANCEL I would strongly recommend
to remove the CANCEL from your draft (despite my other concerns from my
first mail).
Greetings
Nils
Similarly say John calls Bob and Bob answers the call and after speaking realizes that John is a telemarketer or someone with whom Bob does not want to speak in future. Then Bob can send BYE and along with send Reason header with protocol value as "block".
So this way a particular caller identity can be blocked either during the ringing or call termination phase.
Regards
Ranjit
-----Original Message-----
From: Sanjay Sinha (sanjsinh) [mailto:sanjsinh@xxxxxxxxx]
Sent: Tuesday, March 03, 2009 1:30 PM
To: Avasarala Ranjit-A20990; Nils Ohlmeier; Victor Pascual Ávila
Cc: sipping@xxxxxxxx
Subject: RE: New Internet Draft for Caller Identity Blocking
-----Original Message-----
From: sipping-bounces@xxxxxxxx
[mailto:sipping-bounces@xxxxxxxx] On Behalf Of Avasarala Ranjit-A20990
Sent: Tuesday, March 03, 2009 12:01 PM
To: Nils Ohlmeier; Victor Pascual Ávila
Cc: sipping@xxxxxxxx
Subject: Re: New Internet Draft for Caller Identity Blocking
Hi Nils
A originator typically the UAC can send CANCEL if it does not want to
accept the call.
Originator typically initiates the call and the recipient accepts the call. How does originator accept it's own call?
Sanjay
So the Reason header with block
option can be sent while rejecting the call. While the Reason
header with block option can be sent in BYE while terminating
the call - i. e blocking after talking.
Regards
Ranjit
-----Original Message-----
From: Nils Ohlmeier [mailto:lists@xxxxxxxxxxxx]
Sent: Tuesday, March 03, 2009 2:33 AM
To: Victor Pascual Ávila
Cc: Avasarala Ranjit-A20990; sipping@xxxxxxxx
Subject: Re: New Internet Draft for Caller Identity Blocking
Hi Victor,
Am 02.03.2009 21:28 Uhr, schrieb Victor Pascual Ávila:
Hi Nils,
thanks for your comments.
On Mon, Mar 2, 2009 at 6:01 PM, Nils
Ohlmeier<lists@xxxxxxxxxxxx> wrote:
you and your draft are talking about allowing the terminating UA to
give some "feedback" for an incoming call. How is this related to
CANCEL at all? Maybe I'm missing here something but a
CANCEL is only
send by the originator if the call was not yet established, right?!
IMHO it might make sense when dealing with B2BUAs (e.g. a
3pcc service).
Please, correct me if I'm wrong.
I assume you mean that a B2BUA could cancel the outgoing call leg. But
a) where does the B2BUA gets suddenly the information from (if
it has the blocking information already it would reject the
incoming call leg, so there is nothing to cancel) and b) how
is this different from a forking proxy (which obviously needs
to cancel the remaining forked call legs if the user has
rejected the call at one of the legs)?
So I have to fealing that I'm still missing here something.
A CANCEL goes from originator to the receiver of a request.
But you want to send the blocking information in the other
direction. Or do you assume that an entity which processes the
blocking information could sit at the terminating side of a call leg?
I fear that I would need an example or call flow to get the
use case for a CANCEL.
Cheers
Nils
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
