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

[Paul Kyzivat <[e-mail]>]

Christer Holmberg wrote:
> Hi Paul,
> 
> Some proposed new text based on your comment regarding symmetric path. 

I think the statements you have added below seem reasonable as far as 
they go, but they only go half way. They say nothing about what the 
*recipient* of keepalives must do when sending requests. And I have a 
strong suspicion this is pretty far along toward reinventing -outbound-.

I would like to have comments on this from somebody more intimately 
familiar with -outbound- than I am.

	Thanks,
	Paul

> -----------------
>  
>>>>> 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