Subject: [Sipping] to move 605 forward (FW: [BLISS] I-Ds concerning problems with response codes)

From: Mohammad Vakil <[email-masked]>
Date: Sun, 11 Mar 2007 12:16:03 -0700

Just wanted to make sure that this doesn't fall thru the cracks (also wanted to make sure we deal with 303 and 605 separately).

I'm looking for next steps for this draft.

http://home.comcast.net/~sriramkp/Drafts/draft-rajesh-sipping-605-01.txt

There were a few comments around it in bliss wg from Dale and Francois pasted below. I'm trying to move this discussion to proper working group.

Thanks,
-Mohammad

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Tuesday, March 06, 2007 10:18 AM
To: [email-masked]; [email-masked]
Subject: RE: [BLISS] I-Ds concerning problems with response codes

Hi Dale, you did a good job. I think we are going somewhere.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, March 06, 2007 08:52
> To: [email-masked]
> Subject: Re: [BLISS] I-Ds concerning problems with response codes
>
> 4. Start discussion on how to provide a properly scoped "non-local
>    decline" response.  (draft-rajesh-sipping-605-01 is an approach to
>    this issue.)

Yes, I like this draft too.

It basically does the following:
- 603 == "my" reading of RFC 3261, i.e., "Decline fork"
- 605 == "your" reading of RFC 3261, i.e., "Decline really everywhere"

_______________________________________________
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

---

From: [email-masked]
Date: Tue, 13 Mar 2007 11:12:22 -0500

From: Mohammad Vakil <[email-masked]>
   I'm looking for next steps for this draft.

   There were a few comments around it in bliss wg from Dale and
   Francois pasted below. I'm trying to move this discussion to proper
   working group.

I think that this draft is not quite what we need, because it decides
the scope of cancelling of a 603 based on the forking pattern alone.
But I think that additional information is needed to determine the
proper scope, because it is a sociological issue, and the SIP forking
pattern alone does not contain the information that is needed.

For instance, I may normally set my office phone to
forward-on-no-answer to my mobile phone.  I would want a 603 from my
office phone to prevent the call from being cent to my mobile as
well.  But since the forking between the two is serial, this
definition of 603 would not prevent that.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Mar 2007 13:14:58 -0400

I just thought a little more about this. I think maybe we don't need a 
new status. Instead, what we need is new behavior in proxies for the 
handling of 6xx.

If a proxy receives a 6xx from a downstream node, I think it needs to 
make a policy decision about whether whether that downstream node can be 
trusted to make a global response for the R-URI that was in the request 
when it was received by the proxy.

- If so, the proxy can act on it (cease forking if it was doing so) and 
it can also pass it back unchanged.

- If not, then the proxy should replace the response with something 
else. It could be the response from some other fork. Or it could simply 
replace it with a comparable 4xx or 5xx response and pass that on.

If the proxy did not translate the R-URI, and didn't fork, then it 
should presumably just pass the response on.

I'm still scratching my head about what to do with a proxy that is 
following Jonathan's loose routing proposal.

	Paul

---

From: Mohammad Vakil <[email-masked]>
Date: Tue, 13 Mar 2007 10:05:09 -0700

Hi Dale,

inline

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 13, 2007 9:12 AM
To: [email-masked]
Subject: Re: [Sipping] to move 605 forward (FW: [BLISS] I-Ds concerning problems with response codes)

[MV] making sure I understand this case, would you want a 603 from office phone to forward the call on your mobile or not for "forward-on-no-answer"? If you want to prevent any more forwarding you use 605 and if you want forwarding, draft recommends 603. Essentially, this draft is clarifying the serial forking behavior, which is not covered in 3261. When to allow and when not to allow. 603 allows serial forking, whereas 605 doesn't.

Thanks,
-Mohammad

Dale

---

From: Mohammad Vakil <[email-masked]>
Date: Tue, 13 Mar 2007 17:58:16 -0700

Paul,

I'm not sure, I followed your proposal about a policy decision in the proxies without a new response code. How does it address the two scenarios presented in this draft?

- a trusted downstream node wants to continue on to serially forking the request to alternate set of contacts
- a trusted downstream node wants to stop all forking, period! (neither parallel nor serial)

Thanks,
-Mohammad

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, March 13, 2007 10:15 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] to move 605 forward (FW: [BLISS] I-Ds concerning problems with response codes)

        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Mar 2007 10:07:54 -0400

> - a trusted downstream node wants to stop all forking, period! (neither parallel nor serial)

It probably doesn't cover all the cases.

What it does is formalize the notion that the scope of the 6xx's ability 
to stop things is limited based on trust and responsibilty. It covers 
some interesting cases:

- If the call to my AOR is sent to my phone (based on registration), 
then a 6xx from it can cancel all other attempts for the AOR

- if the call to my AOR-1 is forwarded to another AOR-2 (based on some 
forwarding policy in the proxy) and then to some phone registered to 
that, then a 6xx could stop other forks from AOR-2, but would be turned 
into a 4xx and not stop other forking by AOR-1.

But it doesn't cover the case where a proxy wants to give a trusted 
delegate multiple options about what to do next. Trying to cover that 
with different status codes seems problematic - I think there could be 
numerous options that are hard to enumerate that way.

Allowing callerprefs in responses would be one possibility. But it may 
not be good enough. Its not well suited to talking about the canceling 
of currently outstanding invitations. And it also isn't so good about 
retargeting that is driven by policy rather than registration.

	Paul

---

From: [email-masked]
Date: Wed, 14 Mar 2007 17:15:43 -0500

From: Paul Kyzivat <[email-masked]>

IMHO, correctly implementing this requires knowing where the trust
boundaries are, but those boundaries are not determinable from the SIP
forking structure alone.

We've seen various requests for this sort of thing from customers, but
few of them seem to be very important.  At the least, a good
implementation would be difficult, as the desired behavior space is
quite large.  (Right now, SIP only provides success, failure, and
global failure responses.)  Some systems implement this by having the
UA initiate redirections.  But this can easily lead to bad
consequences -- with SIP, it's almost always better to have the proxy
control the redirection.

Dale

---

From: [email-masked]
Date: Wed, 14 Mar 2007 17:26:50 -0500

- a trusted downstream node wants to continue on to serially
     forking the request to alternate set of contacts
   - a trusted downstream node wants to stop all forking, period!
     (neither parallel nor serial)

The word "trusted" is dangerous here - *who* trusts *which* node?

Note that a call may proceed through multiple proxies that do multiple
forks, and a UA may be trusted by some of the proxies but not others.

(Actally, it is more complicated than that -- a UA may be trusted to
modify routing for a particular URI that is expanded by a particular
proxy, but it may not be trusted in regard to the forking for another
URI on the same proxy.)

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Mar 2007 19:16:56 -0400

> proxy, but it may not be trusted in regard to the forking for another

Exactly. That was the point of my earlier suggestion.

For instance, assume AORs X and Y.

- X has contacts x1 and x2 registered.
   It also has policy that says if none of
   registered contacts answer then try forwarding
   to Y. If that fails, then send to x-vm.

- Y has contacts y1 and y2 registered.

A call comes to X and is forked to x1 and x2. If x1 returns a 6xx, then 
X may be willing to trust and cancel the leg to x2. But it will be a 
policy decision whether that should cause the tries for Y and x-vm to ba 
abandoned. Assume not.

So then the call is forwarded to Y, and is forked to y1 and y2. If y1 
returns a 6xx then Y has to decide how much to trust that. Maybe it 
trusts it enough to cancel the leg to y2. So the 6xx response is 
returned to X.

Again, its a policy decision for X whether to trust Y's judgment about 
abandoning other alternatives - namely x-vm. In this case it may well 
decide that it should still try x-vm.

	Paul