From: Jonathan Rosenberg <[EMAIL PROTECTED]>
The issue is really targeting/re-forwarding. The question is, if A
calls B and this is retargeted to C, does it make sense to call
complete on B or on C? C kind of makes sense; but what if C is busy
for a while and during that time, the forwarding rules change and
calls to B no longer forward to C. Now, if A called B back they
would reach B (who was the person they REALLY wanted to call
anyway), but a call completion request would in fact go to C. This
seems wrong to me. One might even argue that call completion and
forwarding are incompatible. Frankly, if our initial solution
basically didn't support it (no Call-Info passed back at all when a
call is forwarded), I think that is arguably a feature. I suspect
experts on feature interaction have looked at this one; would be
curious on the best practices around this in the PSTN.
From: Paul Kyzivat <[EMAIL PROTECTED]>
Some discretion on the part of B and C could make this work better:
If the forwarding is due to NA or BS, then it can be treated as forking,
so that the CC requests go both places. Then whichever gets it first wins.
Conversely, C can notice that the call was forwarded from B, and can
make a policy decision not to support queuing of calls forwarded from B.
From: "Elwell, John" <[EMAIL PROTECTED]>
In PSTN (or at least enterprise equivalents of PSTN) one practice
is to make it depend on the conditions for call forwarding. If it is
call forwarding because of busy or no reply, it makes sense for
CCBS/CCNR to operate on B, rather than C, because there is just as much
chance of B becoming available as C becoming available. And after all, B
is really the person A wants to communicate with. For unconditional call
forwarding (where B is out of the office for a day, say), it might make
sense for CCBS/CCNR to operate on C. However, I don't think we want to
impose rigid rules of this nature on our SIP solution. In some respects
behaviour should be based on the policy of B, but I am not sure how to
realise that.
From: "Alexeitsev, D" <[EMAIL PROTECTED]>
This is the question, that has no ultimative unswer. One view is
that it is easier to control the correlation if the call completion wit
call forwarding is done at the B side. And as you said B is the one A
really wanted. Things get even more complicated bacause of the different
types of call forwarding. Here is one of the PSTN BCPs: [...]
Yes, the distinction of forwarding vs. retargeting vs. etc. is
important in CC. Our assumption is that any sophisticated CC monitor
implementation will have designed proper policies and will edit and
adjust the requests and responses according to that policy.
That is, the messages that are important are: (1) any HERFP responses
to the original INVITE, (2) final failure responses to the original
INVITE, (3) CC SUBSCRIBE requests, and (4) recall INVITE requests. In
each case, the proxy doing the forwarding knows the relationship
between the incoming URI and the outgoing URI and thus can determine
whether the outgoing URI is responsible for CC activities of the
incoming URI, or whether a different outgoing URI should be
substituted. Note that CC SUBSCRIBEs and recall INVITEs can be
detected solely through the 'm' parameter on the request-URI, so even
a memoryless proxy can apply a specific policy.
In Jonathan's case, where INVITEs to B are retargeted to C, there are
two cases: CC requests to B should be handled by C, or CC requests to
B should be handled by some other UAS/monitor D (which may be a
monitor attached to B).
Message CC handled by C CC handled by D
1xx HERFP from C not modified Call-Info: call-completion
URI replaced with D
failure responses not modified Call-Info: call-completion
from C URI replaced with D
CC SUBSCRIBE to B proxy to C proxy to D
recall INVITE to B proxy to C proxy to D
And as Paul notes, other policies are possible, and they can be
implemented on a case-by-case basis by B, C, and/or D.
In the case of an unsophisticated proxy with no specific CC behavior,
all cases are handled as described in "CC handled by C", which is
likely to be acceptable, if not optimal, behavior.
Dale
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
