Denis,

Comment below.

John 

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> On Behalf Of Alexeitsev, D
> Sent: 22 February 2008 16:08
> To: [email protected]
> 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.
[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.
> 
> 
> Comments are very welcomed. 
> 
> Greetings 
> Denis Alexeitsev 
> 
> 
_______________________________________________
BLISS mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/bliss

Reply via email to