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