Subject: [sipcore] Draft new version: SIP Push-12

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Aug 2018 06:49:22 +0000

Hi,

I have submitted a new version (-12) of SIP Push, based on the comments from Ben and Robert.

Some comments have not yet been addressed in the new version, because I am still waiting for Ben to reply.

Regards,

Christer

---

From: Robert Sparks <[email-masked]>
Date: Tue, 14 Aug 2018 10:49:12 -0500

Thanks for this Christer.

I think the draft needs to say even more about the issues related to a 
delay in processing non-INVITE transactions.

I've created a pull-request with suggested text at 
<https://github.com/cdh4u/draft-sip-push/pull/19>.

RjS

On 8/14/18 1:49 AM, Christer Holmberg wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Roman Shpount <[email-masked]>
Date: Tue, 14 Aug 2018 12:15:56 -0400

Robert and Christer,

I have a question: Does anybody plan to use SIP Push with non-INVITE
non-dialog translations? Should this just be left for the future work,
possibly along the lines suggested by Robert with immediate retry-after
response?

Regards,

_____________
Roman Shpount

On Tue, Aug 14, 2018 at 11:49 AM, Robert Sparks <[email-masked]>
wrote:

> <https://github.com/cdh4u/draft-sip-push/pull/19>
> sipcore mailing [email-masked]://www.ietf.org/mailman/listinfo/sipcore
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Aug 2018 16:32:01 +0000

Hi,

>Robert and Christer,
>
>I have a question: Does anybody plan to use SIP Push with non-INVITE non-dialog >translations? Should this just be left for the future work, possibly along the lines >suggested by Robert with immediate retry-after response?

SIP Push is used with SIP MESSAGE. But, at least according to the implementing/testing/deployment people I have been talking to transaction timeouts have not been an issue.

Regards,

Christer

_____________
Roman Shpount

On Tue, Aug 14, 2018 at 11:49 AM, Robert Sparks <[email-masked]<mailto:[email-masked]>> wrote:

I think the draft needs to say even more about the issues related to a delay in processing non-INVITE transactions.

I've created a pull-request with suggested text at <https://github.com/cdh4u/draft-sip-push/pull/19><https://github.com/cdh4u/draft-sip-push/pull/19>.

RjS

Regards,

Christer

sipcore mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: Robert Sparks <[email-masked]>
Date: Tue, 14 Aug 2018 12:33:58 -0500

On 8/14/18 11:32 AM, Christer Holmberg wrote:
> *>*Robert and Christer,
> non-dialog >translations? Should this just be left for the future 
> work, possibly along the lines >suggested by Robert with immediate 
> retry-after response?
>
> SIP Push is used with SIP MESSAGE. But, at least according to the 
> implementing/testing/deployment people I have been talking to 
> transaction timeouts have not been an issue.
>
Keep NOTIFY in mind...
>     I think the draft needs to say even more about the issues related
>     to a delay in processing non-INVITE transactions.
>
>         Some comments have not yet been addressed in the new version,
>         because I am still waiting for Ben to reply.
>
>         Regards,
>
>         Christer
>
>         [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Aug 2018 18:04:56 +0000

Hi,

NOTIFY is not a problem either.

Regards,

Christer

From: Robert Sparks [mailto:[email-masked]]
Sent: 14 August 2018 20:34
To: Christer Holmberg <[email-masked]>; Roman Shpount <[email-masked]>
Cc: [email-masked]
Subject: Re: [sipcore] Draft new version: SIP Push-12

Regards,

Christer

_____________
Roman Shpount

RjS

Regards,

Christer

sipcore mailing list

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Aug 2018 18:20:28 +0000

Hi,

The pull request looks good.

Regarding the "future work" where the proxy requests a re-transmit of the SIP request, I would have no problem to make than an option already now.

I.e. something like "MUST reject the request and MAY (based on local policy) insert a Retry-After header field".

After all, the current text doesn't forbid Retry-After anyway, so we could as well spell it out :)

Regards,

Christer

From: Robert Sparks [mailto:[email-masked]]
Sent: 14 August 2018 18:49
To: Christer Holmberg <[email-masked]>; [email-masked]
Subject: Re: [sipcore] Draft new version: SIP Push-12

RjS

Regards,

Christer

sipcore mailing list

---

From: Robert Sparks <[email-masked]>
Date: Tue, 14 Aug 2018 14:01:06 -0500

Well, if we went down that route, I think we should consider a new 
response code with an explicit semantic.

RFC3261's treatment of Retry-After in the places it uses it leave it to 
the UA to retry at its discretion, and the implication in a lot of the 
places it's used imply there's a human involved in choosing whether to 
retry (I point particularly to "Retry-After: 120 (I'm in a meeting)". 
There are other places (section 14.2) that imply automatic retries, but 
it's not explicit.

I'm uncertain how consistent existing UAs are at retrying a request on a 
bare 400 or 500 with Retry-After (this would be good to know because if 
we _do_ define a new response code, until those UAs are updated, they'll 
do what they do with the bare 4xx or 5xx depending on what code we select).

RjS

On 8/14/18 1:20 PM, Christer Holmberg wrote:
> Regarding the “future work” where the proxy requests a re-transmit of 
> the SIP request, I would have no problem to make than an option 
> already now.
>
> I.e. something like “MUST reject the request and MAY (based on local 
> policy) insert a Retry-After header field”.
>
> After all, the current text doesn’t forbid Retry-After anyway, so we 
> could as well spell it out :)
>
> Regards,
>
> Christer
>
> *From:*Robert Sparks [mailto:[email-masked]]
> *Sent:* 14 August 2018 18:49
> *To:* Christer Holmberg <[email-masked]>; [email-masked]
> *Subject:* Re: [sipcore] Draft new version: SIP Push-12
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Aug 2018 19:33:18 +0000

>Well, if we went down that route, I think we should consider a new response code with an explicit semantic.
>
>RFC3261's treatment of Retry-After in the places it uses it leave it to the UA to retry at its discretion, and the implication in a lot of the places it's used imply there's a human >involved in choosing whether to retry (I point particularly to "Retry-After: 120 (I'm in a meeting)". There are other places (section 14.2) that imply automatic retries, but it's >not explicit.
>I'm uncertain how consistent existing UAs are at retrying a request on a bare 400 or 500 with Retry-After (this would be good to know because if we _do_ define a new >response code, until those UAs are updated, they'll do what they do with the bare 4xx or 5xx depending on what code we select).

True, and there is no way we can impact those endpoints. But, again, timeouts don't seem to be a problem (at least based on the information I have), so if we think this require more studies it could be "future work".

Having said that, we could still define an explicit response code, e.g., 557 (Push Notification Timeout), and use that instead of 404 (Not Found), if people think it would be useful.

Regards,

Christer

 

 
Regards,
 
Christer

Thanks for this Christer.
I think the draft needs to say even more about the issues related to a delay in processing non-INVITE transactions.
I've created a pull-request with suggested text at <https://github.com/cdh4u/draft-sip-push/pull/19>.
RjS
On 8/14/18 1:49 AM, Christer Holmberg wrote:
Hi,

 
Regards,
 
Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 14 Aug 2018 16:10:32 -0400

On Tue, Aug 14, 2018 at 3:33 PM, Christer Holmberg <
[email-masked]> wrote:

> places it's used imply there's a human >involved in choosing whether to
> retry (I point particularly to "Retry-After: 120 (I'm in a meeting)". There
> are other places (section 14.2) that imply automatic retries, but it's >not
> explicit.
> bare 400 or 500 with Retry-After (this would be good to know because if we
> _do_ define a new >response code, until those UAs are updated, they'll do
> what they do with the bare 4xx or 5xx depending on what code we select).
>
> True, and there is no way we can impact those endpoints. But, again,
> timeouts don't seem to be a problem (at least based on the information I
> have), so if we think this require more studies it could be "future work".
>
> Having said that, we could still define an explicit response code, e.g.,
> 557 (Push Notification Timeout), and use that instead of 404 (Not Found),
> if people think it would be useful.
>
> Regards,
>

I agree that 5XX error code is more appropriate here then 404 Not Found.
Even if we do not define a new error code, we should use "504 Server
Time-out"

Regards,
_____________
Roman Shpount

---

From: Robert Sparks <[email-masked]>
Date: Tue, 14 Aug 2018 15:17:59 -0500

On 8/14/18 3:10 PM, Roman Shpount wrote:
> On Tue, Aug 14, 2018 at 3:33 PM, Christer Holmberg 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     >RFC3261's treatment of Retry-After in the places it uses it leave
>     it to the UA to retry at its discretion, and the implication in a
>     lot of the places it's used imply there's a human >involved in
>     choosing whether to retry (I point particularly to "Retry-After:
>     120 (I'm in a meeting)". There are other places (section 14.2)
>     that imply automatic retries, but it's >not explicit.
>     >I'm uncertain how consistent existing UAs are at retrying a
>     request on a bare 400 or 500 with Retry-After (this would be good
>     to know because if we _do_ define a new >response code, until
>     those UAs are updated, they'll do what they do with the bare 4xx
>     or 5xx depending on what code we select).
>
>     True, and there is no way we can impact those endpoints. But,
>     again, timeouts don't seem to be a problem (at least based on the
>     information I have), so if we think this require more studies it
>     could be "future work".
>
>     Having said that, we could still define an explicit response code,
>     e.g., 557 (Push Notification Timeout), and use that instead of 404
>     (Not Found), if people think it would be useful.
>
>     Regards,
>
>
> I agree that 5XX error code is more appropriate here then 404 Not 
> Found. Even if we do not define a new error code, we should use "504 
> Server Time-out"
Eh - I'm less convinced of a 5xx. A 404 is not good in any case - that 
will terminate dialogs (think NOTIFY).

At a high level, this really is a request failure (4xx) not a server 
failure (5xx). If we were to reuse an existing code and hope for the 
best with respect to implementations actually retrying, I think 480 
Temporarily Unavailable is the best in the set.

RjS

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Aug 2018 06:30:53 +0000

Hi,

>>>> RFC3261's treatment of Retry-After in the places it uses it leave it
>>>>to the UA to retry at its discretion, and the implication in a lot of
>>>>the places it's used imply there's a human
>>>> involved in choosing whether to retry (I point particularly to
>>>>"Retry-After: 120 (I'm in a meeting)". There are other places (section
>>>>14.2) that imply automatic retries, but it¹s
>>>> not explicit.
>>>>
>>>> I'm uncertain how consistent existing UAs are at retrying a request
>>>>on a bare 400 or 500 with Retry-After (this would be good to know
>>>>because if we _do_ define a new
>>>> response code, until those UAs are updated, they'll do what they do
>>>>with the bare 4xx or 5xx depending on what code we select).
>>>
>>>timeouts don't seem to be a problem (at least based on the information
>>>I have), so if we think this require more studies it could be "future
>>>work".
>>>
>>>e.g., 557 (Push Notification Timeout), and use that instead of 404 (Not
>>>Found), if people think it would be useful.
>>
>failure (5xx). If we were to reuse an existing code and hope for the best
>with respect to implementations actually
> retrying, I think 480 Temporarily Unavailable is the best in the set.

I am ok with 480.

So, do we keep the pull request as it is, and only change 404 to 480 for
the case when the proxy does not receive a REGISTER and rejects the
request?

Redgards,

Christer

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Wed, 15 Aug 2018 10:45:22 +0000

FWIW, our experience has been retry-after is very rarely honored.

Sent from my iPad

> On Aug 15, 2018, at 1:31 AM, Christer Holmberg <[email-masked]> wrote:
> 
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> Hi,
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&amp;data=02%7C01%7Cpierce.gorman%40sprint.com%7C8e96bab0bfcb4583dc7d08d60278aec7%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636699114686893483&amp;sdata=7ZdJPrdy%2FWz7Oa0%2Fdf5ZqMWFqM%2BcwuXKbW1atfonUv8%3D&amp;reserved=0