Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis-03

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Jul 2010 16:15:53 -0400

Mary,

(Doing my pre-meeting reading. I haven't looked at this for a *long* time.)

I have a question about handling the addition of H-I to responses as 
described in 5.2 and especially in 6.3.3 bullet 6, for parallel forked 
requests:

Often in a parallel forking case a final response will be forwarded 
without yet having seen responses from all the other active branches.
If so, of necessity there is only going to be partial info, or 
inaccurate info.

Figure 1 shows some consolidation, but it leaves out a bunch of detail a 
about how it is done. It notes that the path not taken is canceled and 
an HI entry with a 487 reason. But it won't necessarily wait for the 487 
response, and may not get it.

There is also a possibility that more than one 200 response will be 
received, and again its unclear what is to be done in that case. This 
case can be aggravated if the request contained 
Request-Disposition:nocancel and the proxy honored that.

Also, I see no real addressing of non-INVITE transactions. Of particular 
note is SUBSCRIBE, for which multiple forks can be quite important. For 
it, there will not be multiple 200 responses, but there may still be 
NOTIFYs for multiple branches, each creating a dialog.

Section 6.1 (cosmetic):

instead of:

    hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT)
    mp-param = "mp" EQUAL 1*DIGIT *("." 1*DIGIT)

how about:

    hi-index-value = 1*DIGIT *("." 1*DIGIT)
    hi-index = "index" EQUAL hi-index-value
    mp-param = "mp" EQUAL hi-index-value

	Thanks,
	Paul

---

From: Shida Schubert <[email-masked]>
Date: Sun, 25 Jul 2010 16:39:51 +0200

Paul;

 Thanks for your review, comments inline..

On Jul 21, 2010, at 10:15 PM, Paul Kyzivat wrote:

> I have a question about handling the addition of H-I to responses as described in 5.2 and especially in 6.3.3 bullet 6, for parallel forked requests:
> 
> Often in a parallel forking case a final response will be forwarded without yet having seen responses from all the other active branches.
> If so, of necessity there is only going to be partial info, or inaccurate info.
> 
> Figure 1 shows some consolidation, but it leaves out a bunch of detail a about how it is done. It notes that the path not taken is canceled and an HI entry with a 487 reason. But it won't necessarily wait for the 487 response, and may not get it.
> 

 I think the draft used to have example showing that proxy 
would include all the responses from paralleled fork 
brunches in H-I before it forwarded the request further. 

 I think it was changed into the way it is because when 
a proxy forwards a request based on a response from a 
single brunch, it is that response that triggered the request, 
not the consolidated response, so having the partial information 
is actually what you want. 

> There is also a possibility that more than one 200 response will be received, and again its unclear what is to be done in that case. This case can be aggravated if the request contained Request-Disposition:nocancel and the proxy honored that.

 Are you talking about what is to be included in the 200 responses?
If so each of the 200 response will likely to have different set of 
hi-entries with some being the same (up to where the request forked). 

> 
> Also, I see no real addressing of non-INVITE transactions. Of particular note is SUBSCRIBE, for which multiple forks can be quite important. For it, there will not be multiple 200 responses, but there may still be NOTIFYs for multiple branches, each creating a dialog.

 I don't see the relevance of NOTIFY in relation to SUBSCRIBE when it 
comes to H-I. 

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