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 protected]
http://www.ietf.org/mailman/listinfo/bliss
