Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09

[Paul Kyzivat <[e-mail]>]

On 6/27/13 9:57 AM, Michael Procter wrote:
> On 26 June 2013 16:13, Paul Kyzivat <[e-mail]> wrote:
>> The real issue is: how can a websocket server ever decide that it *doesn't*
>> need to R-R?
>
> The websocket server shouldn't R-R a request if it is a non-dialog-establishing
> request (e.g. REGISTER, PUBLISH) or an in-dialog non-target-refresh request
> (e.g. INFO).  It is probably fair to say that INVITEs should be, but
> that specific
> case is already covered by RFC5626, as Iñaki has pointed out.

You miss my point. The cases you describe above are cases where it never 
makes sense to R-R. The only place the question is relevant is on dialog 
establishing requests.

The simple answer would be that websocket proxy handling a dialog 
establishing request should *always* R-R. But there has been an 
assertion that there may be some sip-websocket UACs that are also 
capable of being sip-websocket servers. In that case, it would be 
desirable for the proxy to *not* R-R, so that it won't be in the 
signaling path for the entire dialog. But how would the proxy know that 
it is safe to not R-R?

One thing that comes to mind for me is that the UAC could decide whether 
or not to tag its contact URI with ";gr". If it were so tagged, then 
that says it is globally routable, so it would be safe for the proxy to 
bypass the R-R. If the contact isn't a gruu, then the proxy would decide 
that it must R-R.

I think Iñaki said he was on vacation for a couple of weeks, so we may 
not hear from him on this soon.

	Thanks,
	Paul