Re: [sipcore] Editorial comments on rfc4244bis-02

On 11/7/2010 7:26 AM, Hadriel Kaplan wrote:
>
> True, I forgot about the forked case... but I don't think that's what they're talking about here, since regardless it's in the reverse direction towards the UAC and follows the SUBSCRIBE's (or REFER's) route set.  Or is the intent to use H-I for requests from the UAS to the UAC as well, in which case why isn't it used in in-dialog requests? (I don't see the point of it, but that's never stopped us before ;)

Sorry - I did just reply narrowly.
You are right - every NOTIFY, even the "dialog initiating" ones are 
requests that are "in dialog" and hence AFAIK don't get H-I in them, nor 
AFAIK can they affect the H-I of the SUBSCRIBE or REFER that caused them.

	Thanks,
	Paul

> -hadriel
>
>
> On Nov 7, 2010, at 1:35 AM, Paul Kyzivat wrote:
>
>> On 11/6/2010 11:48 PM, Hadriel Kaplan wrote:
>>
>>> 5) Section 7.1 says: "...plus NOTIFY requests that initiate a dialog."  Ummm... what type of NOTIFY requests would those be?? (other than proprietary)  Actually, that raises a question - can this appear in proprietary methods?
>>
>> In case of forking, NOTIFY requests can initiate a dialog.
>> And with 3256bis dialogs are *always* initiated by NOTIFY.
>>
>> 	Thanks,
>> 	Paul
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>
>