Subject: [Sip] "unify" draft: problem with upstream 407

From: Rohan Mahy <[email-masked]>
Date: Fri, 18 Jan 2002 08:02:38 -0800 (PST)

Hi,

I noticed another issue with the proposed HERFP solution in the unify
draft with respect to upstream 407s.

suppose UA A sends to Proxy 1 which forks to b@domain1 and c@domain2

to get to c@domain2 the request is routed through a non-forking proxy
(Proxy 2) which sends a 407.  How is this response handled?

- it doesn't seem that proxy 2 could send a 155 since it probably isn't
capable of receiving a COMET and forwarding an INVITE (breaks idempotency)

- proxy 2 could send a 407, which proxy 1 packages in a 155, UA A sends a
COMET, proxy 1 sends a new INVITE (same CSeq new branch)...

Looking carefully at the status codes, the proposed HERFP solution works
perfectly with 1xx, 2xx, and 6xx responses because it doesn't change any
behavior there.  It works fine with 3xx if recursion is turned on.  It
works fine for 5xx with the possible exception of 513 (presumably you
could strip some crud and try to send a smaller message, but that is not
a great loss).  The 4xx responses seem to fall into 3 categories:

1) there is no recourse if the branch fails, so retrying is irrelevant:
400, 403, 404, 408, 410, 414, 421, 481, 482, 483, 486, 487, 405?, 406?,
480?

2) if the branch fails, you could use a 155 and expect recourse with a
COMET:  401, 402, 488, and possibly 415?

3) if the branch fails it is unlikely that you can fix the problem with a
COMET, but you could (at least theoretically) fix the problem with a new
INVITE:   407, 420, 484 (no great loss when forking), 485, and 413?

comments? suggestions? proposals?

thanks,
-rohan

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Jan 2002 10:52:31 -0500

> (Proxy 2) which sends a 407.  How is this response handled?

Yeah, this case isn't well covered by the proposal.

I will note that I think this case is highly unlikely. Generally, the 
proxies that challenge are the ones that have a relationship with the 
caller. Calls fork generally because the called party has multiple 
locations, and therefore, the forking is in the domain of the called 
party. I cannot think of a real example where a 407 would actually come 
after a call was forked to reach the called party.

> COMET, proxy 1 sends a new INVITE (same CSeq new branch)...

This might work. I had actually thought of that for the UA case as well, 
to handle the scenario where the UAS doesn't support 155. Not sure its 
really a case we need to worry about though, as above.

> 1) there is no recourse if the branch fails, so retrying is irrelevant:

I think 421 might work for HERFP, you can resubmit with Supported. 406 
might work as well with HERFP. I don't think 480 would work.

> COMET:  401, 402, 488, and possibly 415?

Yes, 415 and 420 too.

415 was one of the original motivators for this problem. We'll need it 
for the transition from SDP to SDPng. Lets say a UAC sends an INVITE 
with SDPng, and that forks to two UAS, one that supports it, and the 
other, that doesnt. This is a case of HERFP where 415 will be sent.

> INVITE:   407, 420, 484 (no great loss when forking), 485, and 413?

I think 420 could be fixed with a COMET; the processing would 
effectively proceed as if it was the COMET that were the INVITE. Things 
that otherwise will change the destination, like 485 and 413, cannot be 
fixed with COMET. 484 is the same.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com