Re: [BLISS] thoughts on draft-ietf-bliss-call-completion - URIs and routing

[[e-mail]]

   From: Jonathan Rosenberg <[e-mail]>

Let me describe the information flow in CC, in the ideal case:

- caller sends original INVITE to callee
- callee returns failure response containing Call-Info header
  containing CC subscription URI
- caller subscribes to CC subscription URI
- callee sends NOTIFY containing recall URI
- caller sends INVITE to recall URI

(Note that "NOTIFY containing recall URI" is a fairly recent addition.
I've also omitted use of a suspend/resume server URI.)

In both the CC subscription and the recall, the caller is allowed to
use the original INVITE request URI if it does not receive or cannot
remember the URI provided by the callee.  In the CC subscription case,
the caller is required to also fork the SUBSCRIBE to the original
request URI, in hope of reaching other UASs than the one that
generated the failure response that was returned to the UAC.  In both
cases, the caller adds an "m" parameter to the request URI to mark the
request as a CC request, and also to carry the CCBS vs. CCNR datum.

With that background behind us:

   Also, I would NOT assume that SUBSCRIBE and INVITE to the same URI are 
   routed identically; this is not even true in theory as proxies are 
   allowed to do method-based routing. Indeed, typically SUBSCRIBE are 
   routed to appropriate servers based on event packages.

True.  But we expect that method-based routing will be applied to
requests only when they enter the administrative domain of the request
URI, that is, differing routing will only be done as part of
implementing the requested services.  We expect that "mailing list"
forwarding, whose only purpose is to allow one URI to be an alias for
other URIs, will not be method-sensitive.

   I think the callback INVITE needs to be to a different SIP URI. I 
   suspect it will need different treatment on both sides; i.e., that call 
   should not go to voicemail (I suspect).

In the ideal case, the CC subscription NOTIFY provides a callback URI,
which the callee could use to obtain any treatment of the recall
INVITE that it prefers.  However, gateways may not be able to remember
the callback URI, and so using the original request URI is the
fallback.  In any case, the 'm' parameter on the recall request URI
will tag the INVITE as a recall.

   Using the philosophy embraced in:
   http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-identification-02.txt
   a service URI is absolutely the right thing to differentiate here.

I don't understand what you mean by "service URI" here.  That term is
used only once in the I-D that you reference, and only in regard to
presence.

   I do not understand the usage or need for the 'm' and 'monitor'
   attributes. Monitor shows up as a URI param, in fact. Not at all
   sure why that is needed.

The 'monitor' URI parameter is an arbitrary element of the examples.

The 'm' URI parameter is used to (1) mark the CC SUBSCRIBE as such,
(2) mark the recall INVITE as such, and (3) to carry the CCBS vs. CCNR
datum.

The original definition of the 'm' parameter was in a design where the
URI was always in a Call-Info header with "purpose=call-completion",
so its name was chosen for brevity, representing "mode".  The current
design has that parameter standing on its own in request-URIs, so we
may want a longer name.

As I described above, the 'm' parameter is useful to mark CC
SUBSCRIBEs and INVITEs even when the caller can't remember a URI
provided by the callee.

The 'm' parameter is used to carry the CCBS vs. CCNR status.  This
information is not mandatory, but for callees that do not have rich,
unambiguous presence information, knowing whether the caller perceived
a busy condition or a no-answer condition may be helpful in deciding
whether the callee may be available for recall.  It is also helpful in
the SS7-to-SIP-to-SS7 double-gateway situation, preventing loss of
information between the caller SS7 and the callee SS7.  This
encourages use of SIP as a transit network between SS7 systems.

Dale
_______________________________________________
BLISS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/bliss