Subject: [BLISS] Recall INVITE identification

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 22 Feb 2008 17:07:40 +0100

Hi

Problem description.

On the receipt of the ready for recall notification the caller send the
recall INVITE to the callee. The CC monitor shall be able to recognise
that the incoming INVITE is the recall. Otherwise the INVITE will be
rejected. 

The CC monitor shall also be able to recognise the relationship between
the SUBSCRIBE request for the CC monitoring and the initial INVITE.

3 methods have been discussed for the purpose of recall identification:

A) Recall INVITE and SUBSCRIBE for CC monitoring shall have the same
Call-Id as the initial INVITE.	
	Advantage:	This method works in the open SIP space.
	Disadvantage: 	The method does not work in the distributed
gateway environment where a recall INVITE can be generated by the
different gateway, 			as the one that send the initial
invite.

B) Recall INVITE and SUBSCRIBE for CC monitoring shall have the
constructed hash of the caller and callee's E.164 number as the
Request-URI 'id' parameter.
	Advantage: 	This method overcomes the gateway problem as the
caller and callee address information stays the same for initial and
recall call 			even if the relevant INVITEs were
generated by different gateways. The anonymity of the caller is
preserved by using the hash over 			his number.
Works in the open SIP environment.
	Disadvantage:	Additional complexity of implementing the hash
function, especially relevant for the gateways. Every INVITE has to have
the 'id'.

C) Recall INVITE and SUBSCRIBE for CC monitoring  shall have the
concatenation of the caller and callee's E.164 number, in the 'id'
parameter without hash (simplified B solution). 
	Advantage:	For systems, that want to avoid the complexity
of hashing.
	Disadvantage:	Works only in trusted environments, as the
caller identity is revealed in the 'id' parameter. 

All three methods to identify the recall INVITE and SUBSCRIBE for CC
monitoring can be used by the CC monitor in parallel. The decision to
use a particular method can be done by the CC monitor by analysing the
trust relationship with the caller domain.

Comments are very welcomed.

Greetings
Denis Alexeitsev
_______________________________________________
BLISS mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/bliss

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 22 Feb 2008 17:35:06 +0000

Denis,

Comment below.

John 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Alexeitsev, D
> Sent: 22 February 2008 16:08
> To: [email-masked]
> Subject: [BLISS] Recall INVITE identification
> 
> Hi 
> 
> Problem description. 
> 
> On the receipt of the ready for recall notification the 
> caller send the recall INVITE to the callee. The CC monitor 
> shall be able to recognise that the incoming INVITE is the 
> recall. Otherwise the INVITE will be rejected. 
> 
> The CC monitor shall also be able to recognise the 
> relationship between the SUBSCRIBE request for the CC 
> monitoring and the initial INVITE.
> 
> A) Recall INVITE and SUBSCRIBE for CC monitoring shall have 
> the same Call-Id as the initial INVITE.     
>         Disadvantage:   The method does not work in the 
> distributed gateway environment where a recall INVITE can be 
> generated by the different gateway,                        as 
> the one that send the initial invite.
[JRE] This will not work if there is an intermediate B2BUA that does not
maintain call-ID between the upstream side and the downstream side.

> 
> B) Recall INVITE and SUBSCRIBE for CC monitoring shall have 
> the constructed hash of the caller and callee's E.164 number 
> as the Request-URI 'id' parameter.
> 
>         Advantage:      This method overcomes the gateway 
> problem as the caller and callee address information stays 
> the same for initial and recall call                       
> even if the relevant INVITEs were generated by different 
> gateways. The anonymity of the caller is preserved by using 
> the hash over                      his number.  Works in the 
> open SIP environment.
> 
>         Disadvantage:   Additional complexity of implementing 
> the hash function, especially relevant for the gateways. 
> Every INVITE has to have the 'id'.
> 
> 
> C) Recall INVITE and SUBSCRIBE for CC monitoring  shall have 
> the concatenation of the caller and callee's E.164 number, in 
> the 'id' parameter without hash (simplified B solution). 
> 
>         Advantage:      For systems, that want to avoid the 
> complexity of hashing. 
>         Disadvantage:   Works only in trusted environments, 
> as the caller identity is revealed in the 'id' parameter. 
> 
> All three methods to identify the recall INVITE and SUBSCRIBE 
> for CC monitoring can be used by the CC monitor in parallel. 
> The decision to use a particular method can be done by the CC 
> monitor by analysing the trust relationship with the caller domain.
> 
>

---

From: "Steve Langstaff" <[email-masked]>
Date: Mon, 25 Feb 2008 01:46:48 -0800

Excuse my ignorance (I have not been following this discussion closely),
but in methods B and C, what if the caller and/or callee do not have an
E.164 number?

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alexeitsev, D
	Sent: 22 February 2008 16:08
	To: [email-masked]
	Subject: [BLISS] Recall INVITE identification

	Hi 

	Problem description. 

	On the receipt of the ready for recall notification the caller
send the recall INVITE to the callee. The CC monitor shall be able to
recognise that the incoming INVITE is the recall. Otherwise the INVITE
will be rejected. 

	The CC monitor shall also be able to recognise the relationship
between the SUBSCRIBE request for the CC monitoring and the initial
INVITE.

	3 methods have been discussed for the purpose of recall
identification: 

	A) Recall INVITE and SUBSCRIBE for CC monitoring shall have the
same Call-Id as the initial INVITE.     
	        Advantage:      This method works in the open SIP space.

	        Disadvantage:   The method does not work in the
distributed gateway environment where a recall INVITE can be generated
by the different gateway,                        as the one that send
the initial invite.

	        Advantage:      This method overcomes the gateway
problem as the caller and callee address information stays the same for
initial and recall call                       even if the relevant
INVITEs were generated by different gateways. The anonymity of the
caller is preserved by using the hash over                      his
number.  Works in the open SIP environment.

	        Disadvantage:   Additional complexity of implementing
the hash function, especially relevant for the gateways. Every INVITE
has to have the 'id'.

	        Advantage:      For systems, that want to avoid the
complexity of hashing. 
	        Disadvantage:   Works only in trusted environments, as
the caller identity is revealed in the 'id' parameter. 

	All three methods to identify the recall INVITE and SUBSCRIBE
for CC monitoring can be used by the CC monitor in parallel. The
decision to use a particular method can be done by the CC monitor by
analysing the trust relationship with the caller domain.

	Greetings 
	Denis Alexeitsev