Re: [sipcore] draft-ietf-sipcore-keep-04 - Paul's comments on symmetric path

[Christer Holmberg <[e-mail]>]

Hi Paul,

Some proposed new text based on your comment regarding symmetric path. 

-----------------
 
>>>> Section 4.2.2:
>>>>
>>>> IIUC, the keepalive is associated with a flow as defined in 5626. 
>>>> Hence it isn't appropriate to use this negotiation mechanism on a 
>>>> registration that doesn't specify a flow. I don't see that stated anywhere.
>>>>
>>>> (If there was no flow, what would the keepalive state be associated 
>>>> *with*?)
>>>
>>>The second paragraph describes the case when outbound is 
>>>used, and when you do have flows.
>>>
>>>The generic procedure is described in the first paragraph 
>>>of the section, and it does not talk about flows - it talks 
>>>about registrations.
>>
>>I don't see how that works (in the non-outbound case):
>>
>>The purpose of these keepalives is to keep a nat binding open.
>>But that is only useful if the neighboring node then uses 
>>that path to send outbound requests. What is there in the keep draft that even
>>*talks* about that?
>>
>>If the keepalives are sent via TCP, then the neighbor will 
>>have to use that same TCP connection for outbound requests in order to gain any 
>>benefit from the keepalive. If the keepalives are send via UDP, then 
>>the neighbor will have to send requests symmetrically from the 
>>address/port on which the keepalives are received.
> 
>That's a good point.
> 
>I have probably been assuming that the symmetric path usage 
>is part of the keep-alive mechanism itself, defined in 
>outbound, so there is no need to repeat that.
> 
>But, I guess that it is actually part of the outbound 
>mechanism, so we would need to say that it applies also to 
>entities that are willing to send and/or receive keep-alives.
> 
>-----------------
> 
>>If you were to specify that, wouldn't it begin to duplicate outbound?
> 
>It would duplicate that specific requirement of Outbound, yes.
> 
>But, it's still not a duplication of the whole Outbound 
>mechanism. For example, registrar support is still not required.
> 
>And, the keep mechanism can be used between any two SIP entities.

For section 4.3, I suggest the following text:

	"A SIP entity that has negotiated sending of keep-alives associated with a registration (registration flow if Outbound is used) MUST be prepared to receive 
	SIP messages (requests and responses) associated with the registration from the receiver of the keep-alives on the same IP port:address 
	from where the keep-alives are sent. Likewise, a SIP entity that has negotiated sending of keep-alives associated with a dialog 
	MUST be prepared to receive SIP messages associated with the dialog from the receiver of the keep-alives on the same IP port:address from 
	where the keep-alives are sent."

For section 4.4, I suggest the following text:
	
	"A SIP entity that has negotiated receiving of keep-alives associated with a registration (registration flow if Outbound is used) MUST 
	send SIP messages (requests and responses)  associated with the registration towards the sender of the keep-alives using the IP address:port 
	from where the keep-alives where received. Likewise, a SIP entity that has negotiated receiving of keep-alives associated with a dialog MUST 
	send SIP messages associated with the dialog towards the sender of the keep-alives using the IP address:port from where the keep-alives where received."


Regards,

Christer