Subject: [cuss] Comments on draft-ietf-cuss-sip-uui-reqs-03

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 12 Jul 2011 14:58:08 -0400

The introduction discusses "the application" as being associated with
both the UAS and UAC.  I would describe it as "the applications", with
one "application" associated with the UAS and one "application"
associated with the UAC.  This is largely a matter of terminology, but
the choice carries a philosophical bias, as calling both bits of code
one application is a mindset which assumes tight administrative
coordination between them, whereas calling each one an application
seperately suggests they are administratively decoupled.

Given the expectation of a "protocol discriminator" (REQ-11), both
approaches may already be covered by the draft.

The message flow in section 2.4 is not quite correct, as it has a
NOTIFY from Originator to Referrer reporting a 100 Trying that was
received from Terminator, before Originator sends its INVITE to
Terminator.  The correct version is:

              Originator           Referrer             Terminator
                   |                    |                    |
                   |  REFER (UUI) F1    |                    |
                   |<-------------------|                    |
                   |  202 Accepted F2   |                    |
                   |------------------->|                    |
                   |  INVITE (UUI) F5   |                    |
                   |---------------------------------------->|
                   |  100 Trying                             |
                   |<----------------------------------------|
                   | NOTIFY (100 Trying) F3                  |
                   |------------------->|                    |
                   |         200 OK F4  |                    |
                   |<-------------------|                    |
                   |  200 OK F6                              |
                   |<----------------------------------------|
                   |  ACK F7                                 |
                   |---------------------------------------->|
                   | NOTIFY (200 OK) F8 |                    |
                   |------------------->|                    |
                   |        200 OK F9   |                    |
                   |<-------------------|                    |

Or we could omit the 100 and the NOTIFY of 100 for brevicy, as they
are not interesting in this situation.

Do we expect to support UUI in failure responses?  Those are not
listed in REQ-1, but they might be useful in interworking or even
pure-SIP applications.

REQ-5 says that the mechanism will not require dereferencing a URI,
though it might be informative to state that a particular sending
application might use the UUI to carry a URI, which the receiving
application would dereference.

REQ-6 says that UUI can be used for DSS1 information elements, QSIG
information elements, or ISUP parameters.  Does the UUI mechanism
automatically tag which of these cases obtains?  Would that be needed
in fairly open-network gateway-to-gateway interworking situations?  Or
does the protocol discriminator ensure that these issues don't cause
practical problems?

And is there the intention to define within the solution the details
of these interworking cases?

Another architectural question is whether there is an expectation that
the sender and receiver will always be tightly coordinated, part of a
"walled garden", or whether we expect "public" resources to use the
mechanism.

Dale

---

From: Alan Johnston <[email-masked]>
Date: Wed, 20 Jul 2011 10:21:02 -0500

Dale,

Thanks for your comments on the draft.  See my replies below.

- Alan -

> approaches may already be covered by the draft.

I think we need to support both cases.  In some cases, there might be
very loose coordination between the software on the pair of UAs.  In
other cases, I suspect there will be very tight coupling.  But I'd be
interested in other's opinions on this.

>              Originator           Referrer             Terminator

I'll fix it.

> listed in REQ-1, but they might be useful in interworking or even

The problem with failure responses is that they are hop-by-hop rather
than end-to-end.  I don't think we could guarantee delivery of UUI in
a 4xx, 5xx, or 6xx response.  Does anyone have any thoughts on use
cases for this?

> application would dereference.

I don't think this would be an appropriate use of this mechanism.  For
a URI, you would use the Call-Info header field instead of the UUI
mechanism.

> does the protocol discriminator ensure that these issues don't cause

I don't believe there are any issues on the SIP side - the PSTN
gateway will know what PSTN protocol is used on the other side and
will map accordingly.

> of these interworking cases?

We are chartered to specify an ISDN interworking usage, so yes.

> "walled garden", or whether we expect "public" resources to use the

We should be able to support both approaches, but the current uses are
within a trust domain.  As such, this should be the primary use case,
in my opinion.

>
> Dale
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 20 Jul 2011 15:13:26 -0400

> From: Alan Johnston [[email-masked]]
> 
> > On Tue, Jul 12, 2011 at 1:58 PM, Worley, Dale R (Dale) wrote:
> >

An interesting point.  In the pure-SIP world, there is no guarantee
that any particular failure response makes it back to the UAC.  OTOH,
in PSTN-like situations where there is no forking, one can expect the
sole failure response to get back to the UAC.

The important question, I think, is whether in PSTN usage the callee
can send UUI back to the caller when failing a call.  Interworking
with that feature could be important and difficult to implement, so we
need to know if it is a requirement.

> a URI, you would use the Call-Info header field instead of the UUI

Good point, although you can never tell what the application might
send in the UUI.

> gateway will know what PSTN protocol is used on the other side and
[...]
> within a trust domain.  As such, this should be the primary use case,

As long as both ends are within a coordinated domain, then there is no
need to worry about tagging DSS1 vs. QSIG vs. ISUP parameters.

Dale