Subject: RE: [SIP] Removing 409 to conflicting action params

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 10 Feb 2001 00:41:05 -0500

> -----Original Message-----
> From: Neil Deason [mailto:[email-masked]]
> Sent: Friday, February 09, 2001 8:35 AM
> To: Jonathan Rosenberg
> Cc: Robert Sparks; [email-masked]
> Subject: Re: [SIP] Removing 409 to conflicting action params
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > The reason it was there is that if the proxy DOES want to 
> follow it, it
> > becomes meaningless to have some URLS with redirect, and 
> some with proxy.
> > What does the proxy do? 
> 
> I am not asking that Proxy/Registrars be forbidden from
> responding 
> 409 just that they be free to choose not to. Presently a
> registrar 
> MUST respond 409 to conflicting action params. I don't want to 
> be forced to respond 409 when somebody has their mailto URL
> registered 
> with an redirect action and then wants to add a SIP URL which 
> they want requests proxied to.

It is not that simple. If you allow proxies to accept these kinds of things,
that means you allow clients to send them. Once you do that, you must define
concrete processing rules associated with registrations of this type.
Otherwise, a UA now has no way of knowing the
processing a proxy will apply to a set of registered Contacts, or worse,
what the
behavior they're requesting actually is.

As an example, a UA believes it wants a service whereby the proxy server
forwards the request to A, and if it fails, redirects to B. So, it registers
a contact URL with proxy action as high q value, and a separate contact as
redirect action as a lower proxy. It assumes that a proxy server will do
this service as a result. THe proxy might accept this, and provide this
interpretation, or it might accept it, and provide a different
interpretation, or it might reject it. If it rejects it, what does the
client do then? Must it alert the user to redefine the parameters? I
wouldn't want to handle this customer service call.

However, as defined now, the meaning of a set of registered contacts is
CLEAR. If you want more complex behaviors, you send a CPL (and indeed, the
above service is readily representable in a clear and unambigous way using
CPL). By removing this restriction, and as a consequence, allowing clients
to send all kinds of weird stuff, the end result will not be what users
expect. 

-Jonathan R.

> 
> > Does it mean to redirect if the highest q value URL
> > has an action of redirect, even though others say proxy? 
> What if the q
> > values are the same, or none were specified? We came to the 
> conclusion that
> > it could mean any number of more complex behaviors, most of 
> which were more
> > appropriately specified via a CPL than action params.
> >
> > So, I would like to keep this restriction.
> 
> This is a fair point but we could define how a server
> should respond to mixed action params wrt q values if that
> is perceived to be an issue. I think that generally CPL will be 
> available to provide this sort of control where it is really 
> needed and so the whole existence of an action param is fairly 
> unintersting. If present can't it just be treated more as a hint. 
> A SIP server could then choose to try and follow them, use it's 
> own configuration policy or follow alternative user defined 
> processing logic (CPL etc). This gives more flexibility than 
> mandating 409s.
> 
> Cheers,
> Neil.
> -- 
> Ubiquity Software Corporation, UK        http://www.ubiquity.net
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to [email-masked] with
> "subscribe sip-implementors" in the body.
> 

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: "Hisham Khartabil" <[email-masked]>
Date: Tue, 13 Feb 2001 10:22:23 +0200

The example Jonathan gives is for contacts for the same type of request.  As
Robert said, if I want my MESSAGEs to go to a different place than my
INVITEs, it should be allowed.

So, I propose (4 examples below):

REGISTER sip:registrarserver.com SIP/2.0
...
contact: sip:[email-masked];action=proxy;method=MESSAGE
contact: sip:[email-masked];action=redirect;method=MESSAGE

Illegal.

REGISTER sip:registrarserver.com SIP/2.0
...
contact: sip:[email-masked];action=proxy;method=MESSAGE
contact: sip:[email-masked];action=redirect;method=INVITE

Legal.

REGISTER sip:registrarserver.com SIP/2.0
...
contact: sip:[email-masked];action=proxy
contact: sip:[email-masked];action=redirect

Illegal

REGISTER sip:registrarserver.com SIP/2.0
...
contact: sip:[email-masked];action=proxy
contact: sip:[email-masked];action=redirect;method=MESSAGE

Not sure about this one.  Maybe illegal.

I propose this to be in the user preferences and not the base sip.

Regards,

Hisham Khartabil
Hotsip Finland
www.hotsip.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Jonathan Rosenberg
Sent: Saturday, 10 February 2001 7:41 AM
To: Neil Deason; Jonathan Rosenberg
Cc: Robert Sparks; [email-masked]
Subject: RE: [SIP] Removing 409 to conflicting action params

-Jonathan R.

---

---

From: Neil Deason <[email-masked]>
Date: Tue, 13 Feb 2001 09:33:19 +0000

> to send all kinds of weird stuff, the end result will not be what users

I think this example is slightly bogus as we both agree 
this should and will be done by CPL. If anything this example 
shows how redundant action params are. As things stand both 
contacts must have been registered with the same action 
param, either proxy or redirect, and then one of them 
overridden by CPL. 

The point isn't to promote action params + q params as an 
alternative to CPL etc it is more about moving towards 
deprecating action params. What users really care about is 
that requests reach them. Whether they do so via an 
intermediate server redirecting or proxying is of considerably 
less interest. So removing a servers compulsion to 409 contacts 
with a mixture of actions is ihmo user friendly.

I would also argue that there is little clarity in the status
quo as presently the only thing specified is that you cannot 
have a mix of action params. You could register all your 
contacts with an action of proxy but a server's local 
config cause it to redirect. Note q params don't come into 
things as they are already ignored in the basic case. 

To better define things we could say is something 
like ...

Clients MAY use the action parameter within registrations
as a hint to a server as to how requests to their contacts be 
handled. Users that want to control a servers action when routing
requests sent to them should use CPL or SIP-CGI. Servers not 
wishing to accept registrations with differing action parameters 
MAY reject them with a status of 409. 

We could go further defining how servers handle mixed action
params if it really bothers people. I think it is a bit of a non
issue - like whether the de facto local server policy is redirect 
or proxy. I just want requests to find me, for greater control I 
use CPL.

Cheers,
Neil.

---

From: James Undery <[email-masked]>
Date: Tue, 13 Feb 2001 12:52:52 +0000

> contact: sip:[email-masked];action=redirect;method=MESSAGE

And wrong you should be using the "methods" parameter not "method" throughout
but that isn't my main point.

> I propose this to be in the user preferences and not the base sip.

This is the worst of both worlds and inconsistent, and as caller preferences
aren't in the base spec, this can't be in the base spec. The best option I
believe is to change the MUST to a MAY. The q parameter also has no use in the
base spec (section 4.2.6.3) and so can't really be used in arguments for
mandating 409s for conflicting actions in the base spec.

James Undery