Subject: [Sipping] Low-Level Control in sipping-refer-extensions-01

From: "Eric Burger" <[email-masked]>
Date: Sun, 29 Feb 2004 14:49:54 -0500

I was going along with the concept that REFER extensions worked at a higher level than MGCP or H.248.1.  However, I don't see that as being the case *when the REFER-Issuer is in control of the REFER-Recipient's state machine*.

IMHO, once we are in the realm of deciding to 1xx, 2xx, or 4xx a transaction at a UAS, we really are running the UAS' state machine.  At that point, the UAS no longer is a UAS.  It is just a signaling interface to the network.

What happens if, for example, in an application you refer a first refer-recipient to a second refer-recipient.  The second refer-recipient answers (now well beyond 100 Trying, but 200 OK), and the refer-issuer forces 486?  That is allowed in the draft, but doesn't sound good.  The meta issue is, how does the refer-issuer turn off the refer-target's state machine?  I would offer that if one really needs that level of signaling control, one is better off using a device control protocol.

Doesn't the proposal in the document mean we end up with non-determininistic signaling in the network?  Is that at all desired?

This also adds a security issue: what if the refer-issuer says, "send REFER(503) or REFER(600)"?  That could take the UAS out of consideration at the proxy, which may not be desired.  Nice denial of service attack -- even better then REFER(Explode Phone).

One of the goals stated in the draft (Requirement on 'Richness of retrieved information') is to expose lots of information about the dialog.  However, this does expose privacy issues that the refer-target may have, e.g., disability caller-preferences, etc.

Nits:
Third bullet of list in section 4.1:  How about:
"Additional application documents MAY introduce more complicated behavior logic and MARY require a multipart MIME body in order to implement this logic.  In these cases, the Content-Type header cannot provide ..."
Fourth bullet:
s/maintain the subscription till/maintain the subscription until/

Second to last paragraph of section 4.2:
s/please, refer/please refer/

Second paragraph of section 5 and last paragraph of section 7 has a smart quote (apostrophe) in "doesn't".

Example uses tradewind.com, not example.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP