Subject: [sipcore] please review and comment on draft-penar-ietf-sipcore

From: Russ Penar <[email-masked]>
Date: Fri, 12 Jun 2020 21:54:48 +0000

Hi All,
Please take a look at my proposed draft regarding a 1xx message letting caller know their call is rated poorly/ambiguously.
One early feedback is 184 may be too close to progress messages associated with ringback, and I'd love to get more perspectives.
https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/
Best regards,
Russ

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 13 Jun 2020 16:06:19 -0400

Hi. I did a high level review of this document. The following are the 
key points I identified. I didn't investigate a lot of the details 
didn't comment on nits since that can all wait until the overall 
mechanism is workable.

* Section 3 says:

    This section uses the term "intermediary" to mean the entity that
    acts as a SIP UAS on behalf of the user in the network as opposed to
    the user's UAS (usually, but not necessarily, their phone).  The
    intermediary could be a back-to-back user agent (B2BUA) or a SIP
    Proxy.

This section has the terminology scrambled. If the intermediary is a 
true proxy then it is not acting as a UAS. Perhaps you mean:

    This section uses the term "intermediary" to mean the entity that
    acts on behalf of the user in the network as opposed to
    the user's UAS (usually, but not necessarily, their phone).  The
    intermediary could be a back-to-back user agent (B2BUA) or a SIP
    Proxy.

* Section 3.1:

If the intermediary issues 184 as a response code, then it is *not* a 
"failure response code" - it doesn't indicate failure.

* Section 3.4 says:

    We address this situation by having the first network element that
    conforms with this specification play an announcement for negatively
    rated call attempts.
...
    Because the ultimate disposition of the call attempt MAY be a
    100-class response (assuming call goes unanswered due to negative
    rating), the network element conveying the announcement in
    the legacy direction MUST use the 183 Session Progress response to
    establish the media session.  The 183 to provide the announcement
    SHOULD be performed prior to forwarding 180 ringing.  While playing
    the announcement, the intermediary MUST suppress additional 180 and
    183 progress messages.

There is no guarantee that the call will fail. If the call has a chance 
to succeed then these actions may negatively affect that success.

For instance, the callee may have important early media to convey after 
establishing media connections using either 183 or 180. Delaying those 
while playing the announcement may have negative consequences.

And what is to happen if the UAS returns a 2xx response? You must 
address that. Presumably you want to get out of the way and let the call 
succeed.

Also, you don't address what is to happen in the case that forking 
happens, either serial or parallel. That will certainly complicate 
things and needs to be addressed.

I suggest that it would be better to delay the announcement until it is 
known that the call has failed. At that point you can delay the failure 
response, negotiate a new media channel for the announcement, and play it.

Another thing to consider: what to do if the entity responsible for 
playing the announcement is not able to do so using the media offered in 
the INVITE? (E.g., the call is video only and there is no mechanism for 
announcing in video.)

* Section 3.5:

It seems you are assuming that the announcement must be made via media 
in the session requested by the INVITE. There might be other, 
preferable, alternatives. For instance it may be possible to send a text 
to the caller using whatever texting mechanism supported by the UAC. 
This is likely known to the element doing the announcement.

	Thanks,
	Paul

---

From: Russ Penar <[email-masked]>
Date: Sat, 13 Jun 2020 22:00:49 +0000

Hi Paul,  Thanks for the feedback, this is great!

As a general process question, do folks normally work out new/proposed language in email before publishing the next iteration for review?
Just looking for best practice and what works best for the WG. 

*Section 3 - fair, I thought UAS made sense because it could be handling processing for the user.  The spirit is exactly as the adjusted language states so I'm OK making the change if intent is clear.  

*Section 3.1 - Oops, yes, will fix! 

*Section 3.4 - The more I think about this, the less I think we should involve any announcement at all. Given there's really no failure in this scenario (if there were, a 607 or 608 would be used), call either is not answered or goes to voice mail.  I just need to provide a signal back hinting as to why the call went unanswered. 

So maybe, as you alluded to wrt text mechanism, it's enough for the provider and the last IP endpoint (e.g. analog gateway) see the message and the user is informed either through debug or some out of band mechanism (e.g. As part of my user invoice, I get to see a list of my call ratings at all the networks I called)?

*And what is to happen if the UAS returns a 2xx response?  - 2xx does not impact the scenario once we remove any chance of announcement, either voicemail or caller picks up "scam likely" call.

*Also, you don't address what is to happen in the case that forking happens, either serial or parallel.  - Another good point, I will call out this class of scenario, thinking I'd use simul-ring as an example.  I will add the language, but high level I don't think the call flow changes here beyond UAC gets feedback on call-rating from each endpoint/network it targets.  

*Section 3.5 - Fair, see my reply to 3.4 as to why this may be moot and please let me know your thoughts. 

Best regards,
Russ

-----Original Message-----
From: sipcore <[email-masked]> On Behalf Of Paul Kyzivat
Sent: Saturday, June 13, 2020 1:06 PM
To: [email-masked]
Subject: [EXTERNAL] Re: [sipcore] please review and comment on draft-penar-ietf-sipcore

Hi. I did a high level review of this document. The following are the key points I identified. I didn't investigate a lot of the details didn't comment on nits since that can all wait until the overall mechanism is workable.

* Section 3 says:

This section has the terminology scrambled. If the intermediary is a true proxy then it is not acting as a UAS. Perhaps you mean:

* Section 3.1:

If the intermediary issues 184 as a response code, then it is *not* a "failure response code" - it doesn't indicate failure.

* Section 3.4 says:

....

There is no guarantee that the call will fail. If the call has a chance to succeed then these actions may negatively affect that success.

For instance, the callee may have important early media to convey after establishing media connections using either 183 or 180. Delaying those while playing the announcement may have negative consequences.

And what is to happen if the UAS returns a 2xx response? You must address that. Presumably you want to get out of the way and let the call succeed.

Also, you don't address what is to happen in the case that forking happens, either serial or parallel. That will certainly complicate things and needs to be addressed.

I suggest that it would be better to delay the announcement until it is known that the call has failed. At that point you can delay the failure response, negotiate a new media channel for the announcement, and play it.

Another thing to consider: what to do if the entity responsible for playing the announcement is not able to do so using the media offered in the INVITE? (E.g., the call is video only and there is no mechanism for announcing in video.)

* Section 3.5:

It seems you are assuming that the announcement must be made via media in the session requested by the INVITE. There might be other, preferable, alternatives. For instance it may be possible to send a text to the caller using whatever texting mechanism supported by the UAC. 
This is likely known to the element doing the announcement.

	Thanks,
	Paul

_______________________________________________
sipcore mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&amp;data=02%7C01%7Crussp%40microsoft.com%7C0986d8b847e34635fb0408d80fd544fd%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637276755949190049&amp;sdata=d7QRycFviYGL6qC8s7ttbZLj9teu4%2BdA1L721s4i6JY%3D&amp;reserved=0

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Jun 2020 10:15:31 -0400

...
> *Section 3.4 - The more I think about this, the less I think we should involve any announcement at all. Given there's really no failure in this scenario (if there were, a 607 or 608 would be used),…

If you are rethinking that, then I think it is appropriate to step back 
and have a high level discussion of what the problem is, and then how 
best to remedy that.

	Thanks,
	Paul

---

From: Maxim Sobolev <[email-masked]>
Date: Mon, 15 Jun 2020 08:09:15 -0700

For what it's worth, I think the proposed solution is too heavyweight.
Allocating a new status code just for this particular task seems like an
overkill. Simple header included into 18x provisional response should do
the trick in 99% of practical cases. Let's not forget that in a presence of
PRACK provisional responses need end-to-end confirmation and RFC
specifically prohibits UAS from issuing a next response until the previous
one has been acknowledged (or PRACK times out).

Otherwise I would say we need a general new status response code class,
where this would be just one of many possible uses. I'd also say < 180 code
is more suitable, since such a check would logically be done before
"alerting" starts.

-Max

On Fri., Jun. 12, 2020, 2:55 p.m. Russ Penar, <russp=
[email-masked]> wrote:

> Hi All,
>
> Please take a look at my proposed draft regarding a 1xx message letting
> caller know their call is rated poorly/ambiguously.
>
> One early feedback is 184 may be too close to progress messages associated
> with ringback, and I’d love to get more perspectives.
>
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Russ Penar <[email-masked]>
Date: Mon, 15 Jun 2020 15:20:39 +0000

Thank you Max!

Understood on heavyweight, but believe it may be necessary to provide a call rating signal (as known from the network) separate from alerting messages, and I’m wary of re-using Trying.  I’m open to the idea of a new code class if that makes the most sense to the group.

Completely agree on the <180, that was early feedback from Shreyas and corrected in the better named/formatted draft proposal per feedback from Brian, https://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/

I’m meeting this week to discuss opportunity to join forces with others in the WG and perhaps consolidate the working proposal, but believe discussion on current ‘..ratingprovided’ draft is helpful, thanks again!

From: Maxim Sobolev <[email-masked]>
Sent: Monday, June 15, 2020 8:09 AM
To: Russ Penar <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [sipcore] please review and comment on draft-penar-ietf-sipcore

For what it's worth, I think the proposed solution is too heavyweight. Allocating a new status code just for this particular task seems like an overkill. Simple header included into 18x provisional response should do the trick in 99% of practical cases. Let's not forget that in a presence of PRACK provisional responses need end-to-end confirmation and RFC specifically prohibits UAS from issuing a next response until the previous one has been acknowledged (or PRACK times out).

Otherwise I would say we need a general new status response code class, where this would be just one of many possible uses. I'd also say < 180 code is more suitable, since such a check would logically be done before "alerting" starts.

-Max

On Fri., Jun. 12, 2020, 2:55 p.m. Russ Penar, <russp=[email-masked]<mailto:[email-masked]>> wrote:
Hi All,
Please take a look at my proposed draft regarding a 1xx message letting caller know their call is rated poorly/ambiguously.
One early feedback is 184 may be too close to progress messages associated with ringback, and I’d love to get more perspectives.
https://datatracker.ietf.org/doc/draft-penar-ietf-sipcore/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-penar-ietf-sipcore%2F&data=02%7C01%7Crussp%40microsoft.com%7Cbf1fdd335f4644bd4f0f08d8113e381f%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637278306218013092&sdata=BEffM6Wl7YDYbmeGL%2FmuCWFfklWFSJkbSYrVqQFTp2M%3D&reserved=0>
Best regards,
Russ
_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&data=02%7C01%7Crussp%40microsoft.com%7Cbf1fdd335f4644bd4f0f08d8113e381f%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637278306218013092&sdata=CPv5gphcMpR3pcisfHNdvZjAa4sE7Z6mvRH2mRt9vF0%3D&reserved=0>

---

From: Russ Penar <[email-masked]>
Date: Mon, 15 Jun 2020 15:25:43 +0000

Makes sense, thanks Paul.  
I'm meeting with a couple folks from the WG to have such a discussion this week.
Max's suggestion of a new code class is interesting. 

Best regards,
Russ

-----Original Message-----
From: Paul Kyzivat <[email-masked]> 
Sent: Monday, June 15, 2020 7:16 AM
To: Russ Penar <[email-masked]>; [email-masked]
Subject: Re: [EXTERNAL] Re: [sipcore] please review and comment on draft-penar-ietf-sipcore

...
> *Section 3.4 - The more I think about this, the less I think we should involve any announcement at all. Given there's really no failure in this scenario (if there were, a 607 or 608 would be used),…

If you are rethinking that, then I think it is appropriate to step back and have a high level discussion of what the problem is, and then how best to remedy that.

	Thanks,
	Paul

---

From: Maxim Sobolev <[email-masked]>
Date: Mon, 15 Jun 2020 09:11:30 -0700

Thanks for understanding, Russ! I look forward to seeing the updated draft.
WRT re-using "100 Trying" I think that is not going to fly, since in most
cases, except very simple one (i.e. stateless proxy) 100 Trying is
hop-by-hop, not end-to-end.

-Max

On Mon, Jun 15, 2020 at 8:20 AM Russ Penar <[email-masked]> wrote:

> Thank you Max!
>
>
>
> Understood on heavyweight, but believe it may be necessary to provide a
> call rating signal (as known from the network) separate from alerting
> messages, and I’m wary of re-using Trying.  I’m open to the idea of a new
> code class if that makes the most sense to the group.
>
>
>
> Completely agree on the <180, that was early feedback from Shreyas and
> corrected in the better named/formatted draft proposal per feedback from
> Brian,
> https://datatracker.ietf.org/doc/draft-penar-sipcore-ratingprovided/
>
>
>
> I’m meeting this week to discuss opportunity to join forces with others in
> the WG and perhaps consolidate the working proposal, but believe discussion
> on current ‘..ratingprovided’ draft is helpful, thanks again!
>
>
>
> *From:* Maxim Sobolev <[email-masked]>
> *Sent:* Monday, June 15, 2020 8:09 AM
> *To:* Russ Penar <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* [EXTERNAL] Re: [sipcore] please review and comment on
> draft-penar-ietf-sipcore
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-penar-ietf-sipcore%2F&data=02%7C01%7Crussp%40microsoft.com%7Cbf1fdd335f4644bd4f0f08d8113e381f%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637278306218013092&sdata=BEffM6Wl7YDYbmeGL%2FmuCWFfklWFSJkbSYrVqQFTp2M%3D&reserved=0>
>
> Best regards,
>
> Russ
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsipcore&data=02%7C01%7Crussp%40microsoft.com%7Cbf1fdd335f4644bd4f0f08d8113e381f%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637278306218013092&sdata=CPv5gphcMpR3pcisfHNdvZjAa4sE7Z6mvRH2mRt9vF0%3D&reserved=0>
>
>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 15 Jun 2020 21:24:03 -0400

Maxim Sobolev <[email-masked]> writes:
> [...] Simple header included into 18x provisional response should do
> the trick in 99% of practical cases. [...]

One alternative would be to attach this information to 183 Session
Progress.  183 resembles 180, but it carries no semantics about
alerting:

   21.1.5 183 Session Progress

   The 183 (Session Progress) response is used to convey information
   about the progress of the call that is not otherwise classified.  The
   Reason-Phrase, header fields, or message body MAY be used to convey
   more details about the call progress.

Dale

---

From: Maxim Sobolev <[email-masked]>
Date: Mon, 15 Jun 2020 18:30:14 -0700

That actually a great idea Dale, I was thinking along the same lines
yesterday but dismissed the idea as too extravagant. Nobody prevents
multiparty body to carry on both "Rating" and media description! On the
implementation side of things, handling multiparty in 183 would be way less
expensive proposition, compared to adding new class of status codes. IMHO.

-Max

---

From: Russ Penar <[email-masked]>
Date: Tue, 16 Jun 2020 02:04:46 +0000

Interesting, the network will know the call-rating and is able to deliver it prior to 180.  Is timing a problem in that case?
-russp

From: Maxim Sobolev <[email-masked]>
Sent: Monday, June 15, 2020 6:30 PM
To: Dale R. Worley <[email-masked]>
Cc: Russ Penar <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [sipcore] please review and comment on draft-penar-ietf-sipcore

That actually a great idea Dale, I was thinking along the same lines yesterday but dismissed the idea as too extravagant. Nobody prevents multiparty body to carry on both "Rating" and media description! On the implementation side of things, handling multiparty in 183 would be way less expensive proposition, compared to adding new class of status codes. IMHO.

-Max

On Mon.., Jun. 15, 2020, 6:24 p.m. Dale R. Worley, <[email-masked]<mailto:[email-masked]>> wrote:

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 16 Jun 2020 22:36:22 -0400

> expensive proposition, compared to adding new class of status codes. IMHO.

In regard to multipart bodies, I would worry that some UAs would not
look within them to find the SDP.

But it seems intrinsic to your use case that the rating will be
generated before a session description is -- the rating will be
generated before the INVITE is allowed to reach a UA.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 27 Jun 2020 06:10:35 +0000

Hi,

>> multiparty body to carry on both "Rating" and media description! On 
>> the implementation side of things, handling multiparty in 183 would be 
>> way less expensive proposition, compared to adding new class of status codes. IMHO.
>
> In regard to multipart bodies, I would worry that some UAs would not look within them to find the SDP.
>
> But it seems intrinsic to your use case that the rating will be generated before a session description is -- the rating will be generated before the INVITE is allowed to reach a UA.

Correct. If the 183 is generated by the called party proxy, it may not have to include SDP.

Regards,

Christer