Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-sip-push-11 - Major issues

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

Hi Ben,

Thanks for you review! In order to avoid super long e-mails, in this reply I will address your Major issues.

Also, Robert Sparks raised more or less the same issues off-line. I was going to bring them to the list, but I'll deal with them in this thread.

> In summary, I don’t think this draft is ready for IETF last call. There are significant issues that I think need further attention 
> from the working group before this can progress. I am returning the draft to the working group, and will change the state to “AD is Watching”.

Major Issues:

---

> 1. The mechanism makes SIP transactions pend for an indeterminate period of time while the push notification is processed, the 
> recipient wakes up and sends a REGISTER request, and the registrar processes that request. This is a problem for non-INVITE transactions, 
> and is not optimal for any transaction. (The issues with doing this to a non-INVITE transaction are best described in RFC 4321.)
>
> At least for the non-INVITE case, has the working group considered a model where the transaction completes and the UAC resends it at
> some point in the future? (For example, a 4XX response with retry-after)

It is true that, in the case of non-INVITEs, the proxy cannot wait that long for the REGISTER.

When I discussed this with Robert, I suggested the following new paragraph to be added to section 5.3.2:

"As describe above, there are cases where the proxy will reject the SIP request and send an error response towards the UAC. While waiting for the notification request to succeed, or the REGISTER request to arrive from the SIP UA, the proxy needs to take into consideration that the transaction associated with the SIP request will eventually time out at the sender (UAC), and the sender will consider the transaction a failure. If the proxy forwards the SIP request towards the SIP UA, the SIP UA accepts the request and the transaction times out at the sender before it receives the successful response, this will cause state misalignment between the endpoints (the sender will consider the transaction a failure, while the receiver will consider the transaction a success). The SIP proxy needs to take this into account when deciding for how long to wait before it considers the transaction associated with the SIP request a failure, to make sure that the error response reaches the sender before the transaction times out."

I have talked to my product people, and the good part is that the push mechanisms is fast enough to not cause any transaction timeout issues (it has been tested with SIP MESSAGE requests).

---

>2. The architectural assumptions are unclear. In particular, the role of the proxy in the SIP network is unclear. In some parts 
>of the draft, it appears the proxy must be co-located with the registrar, but others talk about a proxy that is on the path between 
>the UA and the registrar. Along the same lines, the draft needs to clarify assumptions  about proxy’s role for inbound SIP requests. 
>(For example, the R-URI in an inbound request may or may not match the registered contact depending on whether the request has 
>been retargeted—the R-URI could be an AoR rather than a registered contact.)

The proxy needs to be located between the UA and the proxy that puts the registered contact into the R-URI of the SIP request (the UA's "home proxy"). 

When talking to Robert, I realized that the text in some places wrongly calls that home proxy "registrar". A registrar only handles REGISTER request. It does not replace the R-URI, forward non-REGISTER requests etc.

When it comes to inbound SIP requests (non-REGISTER) there are no push specific procedures for the proxy.

---

>3. The mechanism seems to assume a single contact binding exists at any one time, and that any given REGISTER request
>relates to that binding. How is this expected to work if multiple bindings exist at the same time, perhaps with different
>expiration times? What if the user has multiple clients that are creating bindings, some supporting this mechanism and others not supporting it?

Robert suggested the following modified paragraph in section 5.3.2 to cover that:

   "In case of a 2xx response to the REGISTER request, once the proxy has forwarded
   the REGISTER response towards the UA, if one of the contacts in the REGISTER
   response matches the Request-URI of the SIP request to be forwarded, and if that
   contact has not expired, the proxy can forward the SIP request towards the UA, using
   normal SIP procedures. If none of the contacts of the most recent REGISTER
   2xx response and Request-URI do not match, the proxy MUST reject the
   SIP request with a 404 (Not Found) response."

---

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Tue, 21 Aug 2018 16:52:55 -0500

Hi, sorry for the late response. It’s been a busy couple of weeks. I’ve read version 13 and the various discussion threads, and am commenting with those in mind.

Thanks!

Ben.

> On Aug 8, 2018, at 1:53 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Ben,
> 
> "As describe above, there are cases where the proxy will reject the SIP request and send an error response towards the UAC. While waiting for the notification request to succeed, or the REGISTER request to arrive from the SIP UA, the proxy needs to take into consideration that the transaction associated with the SIP request will eventually time out at the sender (UAC), and the sender will consider the transaction a failure. If the proxy forwards the SIP request towards the SIP UA, the SIP UA accepts the request and the transaction times out at the sender before it receives the successful response, this will cause state misalignment between the endpoints (the sender will consider the transaction a failure, while the receiver will consider the transaction a success). The SIP proxy needs to take this into account when deciding for how long to wait before it considers the transaction associated with the SIP request a failure, to make sure that the error response reaches the sender before the transaction times out.”

I am okay with the the way this is handled in version 13, modulo the fact that I agree with Robert that 480 is a better choice than 404. I wish we could just throw “retry-after” in and expect clients to do the right thing, but we can’t.

> I have talked to my product people, and the good part is that the push mechanisms is fast enough to not cause any transaction timeout issues (it has been tested with SIP MESSAGE requests).

I can only assume that they tested for specific deployments and specific PNSs. I image the PNS latency can vary a lot, depending on the PNS itself, the transient load on the PNS, SIP network conditions, etc. So I’m hesitant to treat such testing as proof that this won’t be a problem in some cases.

> When talking to Robert, I realized that the text in some places wrongly calls that home proxy "registrar". A registrar only handles REGISTER request. It does not replace the R-URI, forward non-REGI…

Version 13 is improved. I think it could use some elaboration about why the proxy needs to be downstream of the “home proxy” for incoming SIP requests. The only reason I am aware of is that the inbound SIP request needs to either have a device contact rather than an AOR in the R-URI, or the proxy needs to have other knowledge of the contact bindings (perhaps it has an out-of-band interface to the location services).

> When it comes to inbound SIP requests (non-REGISTER) there are no push specific procedures for the proxy.

I think we are using “inbound” in opposite ways :-) I meant requests _toward_ the UA that is using the push service.

>   SIP request with a 404 (Not Found) response.”

That’s better, but I don’t think it’s enough. The draft needs to explicitly discuss the implications of multiple clients, and multiple contacts per client.

For example, what happens if I have multiple clients, all using the push service? What if not all are using the push service? What if the proxy is in path for all of them? What if it is only in the path for some of them? Keep in mind that a REGISTER _response_ includes all current bindings, including bindings that may not belong to the UA that sent the REGISTER in response to the push notification.

What happens if a single client has multiple bindings (perhaps one for IPv4 and one for IPv6)? Do both refresh at the same time?

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Aug 2018 06:46:31 +0000

Hi Ben,

>> Also, Robert Sparks raised more or less the same issues off-line. I was
>>going to bring them to the list, but I'll deal with them in this thread.
>> 
>>> In summary, I don¹t think this draft is ready for IETF last call.
>>>There are significant issues that I think need further attention
>>> from the working group before this can progress. I am returning the
>>>draft to the working group, and will change the state to ³AD is
>>>Watching².
>> 
>> Major Issues:
>> 
>> ---
>> 
>>> 1. The mechanism makes SIP transactions pend for an indeterminate
>>>period of time while the push notification is processed, the
>>> recipient wakes up and sends a REGISTER request, and the registrar
>>>processes that request. This is a problem for non-INVITE transactions,
>>> and is not optimal for any transaction. (The issues with doing this to
>>>a non-INVITE transaction are best described in RFC 4321.)
>>> 
>>> At least for the non-INVITE case, has the working group considered a
>>>model where the transaction completes and the UAC resends it at
>> "As describe above, there are cases where the proxy will reject the SIP
>>request and send an error response towards the UAC. While waiting for
>>the notification request to succeed, or the REGISTER request to arrive
>>from the SIP UA, the proxy needs to take into consideration that the
>>transaction associated with the SIP request will eventually time out at
>>the sender (UAC), and the sender will consider the transaction a
>>failure. If the proxy forwards the SIP request towards the SIP UA, the
>>SIP UA accepts the request and the transaction times out at the sender
>>before it receives the successful response, this will cause state
>>misalignment between the endpoints (the sender will consider the
>>transaction a failure, while the receiver will consider the transaction
>>a success). The SIP proxy needs to take this into account when deciding
>>for how long to wait before it considers the transaction associated with
>>the SIP request a failure, to make sure that the error response reaches
>>the sender before the transaction times out.²
>
>I am okay with the the way this is handled in version 13, modulo the fact
>that I agree with Robert that 480 is a better choice than 404. I wish we
>could just throw ³retry-after² in and expect clients to do the right
>thing, but we can¹t.
>
>> 
>> I have talked to my product people, and the good part is that the push
>>mechanisms is fast enough to not cause any transaction timeout issues
>>(it has been tested with SIP MESSAGE requests).
>
>I can only assume that they tested for specific deployments and specific
>PNSs. I image the PNS latency can vary a lot, depending on the PNS
>itself, the transient load on the PNS, SIP network conditions, etc. So
>I¹m hesitant to treat such testing as proof that this won¹t be a problem
>in some cases.

It was not meant as a ³proof² that things will always work - of course
things can go wrong. But, since the issue was raised, I provided input
based on the testing/deployment information I have :)

---

>> 
>>> 2. The architectural assumptions are unclear. In particular, the role
>>>of the proxy in the SIP network is unclear. In some parts
>>> of the draft, it appears the proxy must be co-located with the
>>>registrar, but others talk about a proxy that is on the path between
>>> the UA and the registrar. Along the same lines, the draft needs to
>>>clarify assumptions  about proxy¹s role for inbound SIP requests.
>>> (For example, the R-URI in an inbound request may or may not match the
>>>registered contact depending on whether the request has
>>> been retargeted‹the R-URI could be an AoR rather than a registered
>>>contact.)
>> 
>> The proxy needs to be located between the UA and the proxy that puts
>>the registered contact into the R-URI of the SIP request (the UA's "home
>>proxy").
>> 
>> When talking to Robert, I realized that the text in some places wrongly
>>calls that home proxy "registrar". A registrar only handles REGISTER
>>request. It does not replace the R-URI, forward non-REGISTER requests
>>etc.
>> 
>
>Version 13 is improved. I think it could use some elaboration about why
>the proxy needs to be downstream of the ³home proxy² for incoming SIP
>requests. The only reason I am aware of is that the inbound SIP request
>needs to either have a device contact rather than an AOR in the R-URI, or
>the proxy needs to have other knowledge of the contact bindings (perhaps
>it has an out-of-band interface to the location services).

Correct. I will see whether I can make that more clear.

>I think we are using ³inbound² in opposite ways :-) I meant requests
>_toward_ the UA that is using the push service.

Ok. But, as said above, the assumption is that the R-URI of the request
will contain the contact (hence the reason why the proxy needs to be
downstream of the ³home proxy²).

---

>> 
>>> 3. The mechanism seems to assume a single contact binding exists at
>>>any one time, and that any given REGISTER request
>>> relates to that binding. How is this expected to work if multiple
>>>bindings exist at the same time, perhaps with different
>>> expiration times? What if the user has multiple clients that are
>>>creating bindings, some supporting this mechanism and others not
>>>supporting it?
>> 
>>   SIP request with a 404 (Not Found) response.²
>
>That¹s better, but I don¹t think it¹s enough. The draft needs to
>explicitly discuss the implications of multiple clients, and multiple
>contacts per client.
>
>For example, what happens if I have multiple clients, all using the push
>service? What if not all are using the push service? What if the proxy is
>in path for all of them? What if it is only in the path for some of them?
>Keep in mind that a REGISTER _response_ includes all current bindings,
>including bindings that may not belong to the UA that sent the REGISTER
>in response to the push notification.

Even if a client has registered multiple contacts, the inbound SIP request
will only contain one of the contacts in the R-URI. How the ³home proxy²
decides which contact to place in the R-URI is outside the scope of the
document.

>What happens if a single client has multiple bindings (perhaps one for
>IPv4 and one for IPv6)? Do both refresh at the same time?

Assuming they both use the same push notification subscription, yes. I can
add text which clarifies that.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 22 Aug 2018 17:08:26 -0500

> On Aug 22, 2018, at 1:46 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Ben,
> 

I think we covered this in discussion of version 13.

> Correct. I will see whether I can make that more clear.

Thanks.

> downstream of the ³home proxy²).

Right.

> decides which contact to place in the R-URI is outside the scope of the

So I was thinking in terms of the following scenario:

Imagine I have client A and client B that I use for the same service. The push-proxy is on the registration path for both of them. The push proxy receives an inbound INVITE that has been targeted to client A. Further assume that client A has lost it’s network connection.

The push requests a push notification to client A. At some point before the proxy decides to fail the transaction, client B sends a register request. The _response_ to that request will contain the contacts for both A and B. I _think_ that will cause the push proxy to forward the INVITE towards A, which will fail.  (Maybe that’s okay, as it is pretty much the same as what would happen without push).

But as a variation, imagine the home proxy parallel forked the INVITE to both A and B. The push proxy requests notifications to both clients. Only B sends a REGISTER. How does the push-proxy know which (forked) INVITE to forward? Does it forward both?

What am I missing?

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Aug 2018 10:22:58 +0000

Hi,

...

>>>>> any one time, and that any given REGISTER request relates to that 
>>>>> binding. How is this expected to work if multiple bindings exist at 
>>>>> the same time, perhaps with different expiration times? What if the 
>>>>> user has multiple clients that are creating bindings, some 
>>>>> supporting this mechanism and others not supporting it?
>>>> 
>>>>  "In case of a 2xx response to the REGISTER request, once the proxy 
>>>> has forwarded  the REGISTER response towards the UA, if one of the 
>>>> contacts in the REGISTER  response matches the Request-URI of the 
>>>> SIP request to be forwarded, and if that  contact has not expired, 
>>>> the proxy can forward the SIP request towards the UA, using  normal 
>>>> SIP procedures. If none of the contacts of the most recent REGISTER  
>>> That's better, but I don't think it¹s enough. The draft needs to 
>>> For example, what happens if I have multiple clients, all using the 
>>> push service? What if not all are using the push service? What if the 
>>> proxy is in path for all of them? What if it is only in the path for some of them?
>>> Keep in mind that a REGISTER _response_ includes all current 
>>> bindings, including bindings that may not belong to the UA that sent 
>>> the REGISTER in response to the push notification.
>> 
>> Even if a client has registered multiple contacts, the inbound SIP 
>> request will only contain one of the contacts in the R-URI. How the 
>> "home proxy" decides which contact to place in the R-URI is outside 
>> the scope of the document.
>
> Imagine I have client A and client B that I use for the same service. The push-proxy is on the registration path for both 
> of them. The push proxy receives an inbound INVITE that has been targeted to client A. Further assume that client A has lost it’s 
> network connection.
>
> The push requests a push notification to client A. At some point before the proxy decides to fail the transaction, client B sends 
> a register request. The _response_ to that request will contain the contacts for both A and B. I _think_ that will cause the push 
> proxy to forward the INVITE towards A, which will fail.  (Maybe that’s okay, as it is pretty much the same as what would happen 
> without push).

Correct. The contact of B will not match the R-URI of the inbound INVITE.

> But as a variation, imagine the home proxy parallel forked the INVITE to both A and B. The push proxy requests notifications to 
> both clients. Only B sends a REGISTER. How does the push-proxy know which (forked) INVITE to forward? Does it forward both?

The INVITEs will have different R-URIs, so they will be handled separately from each other. If only B sends a REGISTER, the INVITE addressed to B will be forwarded (assuming the contact of the REGISTER matches the R-URI of the INVITE). The INVITE addressed to A will fail.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Thu, 23 Aug 2018 15:03:23 -0500

> On Aug 23, 2018, at 5:22 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> ...
> 

My confusion was around how the push-proxy knows which one of the INVITEs the REGISTER matches up with. I had read things to say that this was determined by matching one of the contacts in the REGISTER _response_. Since the REGISTER response would contain both contacts, it would match both INVITEs.

But on re-reading, I was reminded of this paragraph in §5.3.2:

" As both the SIP request to be forwarded towards the UA, and the
   binding refresh REGISTER request triggered by the push notification
   request, will convey pn- SIP URI parameters associated with the SIP
   registration, those can be used to match the SIP request with the
   binding refresh REGISTER request (even if the most recent contact and
   the Request-URI of the SIP request do not match).”

Assuming multiple clients for the same user still have different PRIDs , I guess that makes sense. But I think this needs more detail and a stronger (probably normative statement). In particular, since much of the section talks about matching contacts in responses, this match needs to happen against the REGISTER _request_, right? Since the PRID is a URI parameter, would it make sense to say that the REGISTER contact URI and the inbound request R-URI MUST both contain the same push-related parameters?

Thanks,

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Aug 2018 09:35:36 +0000

Hi,

>>>>>>> 3. The mechanism seems to assume a single contact binding exists 
>>>>>>> at any one time, and that any given REGISTER request relates to 
>>>>>>> that binding. How is this expected to work if multiple bindings 
>>>>>>> exist at the same time, perhaps with different expiration times? 
>>>>>>> What if the user has multiple clients that are creating bindings, 
>>>>>>> some supporting this mechanism and others not supporting it?
>>>>>> 
>>>>>> the proxy can forward the SIP request towards the UA, using  
>>>>>> normal SIP procedures. If none of the contacts of the most recent 
>>>>>> REGISTER 2xx response and Request-URI do not match, the proxy MUST 
>>>>>> reject the SIP request with a 404 (Not Found) response.²
>>>>> 
>>>>> explicitly discuss the implications of multiple clients, and 
>>>>> multiple contacts per client.
>>>>> 
>>>>> push service? What if not all are using the push service? What if 
>>>>> the proxy is in path for all of them? What if it is only in the path for some of them?
>>>>> bindings, including bindings that may not belong to the UA that 
>>>>> sent the REGISTER in response to the push notification.
>>>> 
>>> Imagine I have client A and client B that I use for the same service. 
>>> The push-proxy is on the registration path for both of them. The push 
>>> proxy receives an inbound INVITE that has been targeted to client A. Further assume that client A has lost it’s network connection.
>>> 
>>> The push requests a push notification to client A. At some point 
>>> before the proxy decides to fail the transaction, client B sends a 
>>> register request. The _response_ to that request will contain the 
>>> contacts for both A and B. I _think_ that will cause the push proxy to forward the INVITE towards A, 
>>> which will fail.  (Maybe that’s okay, as it is pretty much the same as what would happen without push).
>> 
>>> But as a variation, imagine the home proxy parallel forked the INVITE 
>>> to both A and B. The push proxy requests notifications to both clients. Only B sends a REGISTER. 
>>> How does the push-proxy know which (forked) INVITE to forward? Does it forward both?
>> 
>> The INVITEs will have different R-URIs, so they will be handled separately from each other. If only B sends a 
>> REGISTER, the INVITE addressed to B will be forwarded (assuming the contact of the REGISTER matches the 
>> R-URI of the INVITE). The INVITE addressed to A will fail.
>
> My confusion was around how the push-proxy knows which one of the INVITEs the REGISTER matches up with. I 
> had read things to say that this was determined by matching one of the contacts in the REGISTER _response_. Since 
> the REGISTER response would contain both contacts, it would match both INVITEs.
>
> Assuming multiple clients for the same user still have different PRIDs , I guess that 
> makes sense. But I think this needs more detail and a stronger (probably normative statement). 
> In particular, since much of the section talks about matching contacts in responses, this match 
> needs to happen against the REGISTER _request_, right? Since the PRID is a URI parameter, would 
> it make sense to say that the REGISTER contact URI and the inbound request R-URI MUST both 
> contain the same push-related parameters?

Ok, so the matching is done against the REGISTER request, but unless the proxy is able to authenticate the sender of the REGISTER it still needs to wait for the REGISTER response before it forwards the SIP request. 

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Fri, 24 Aug 2018 14:22:43 -0500

> On Aug 24, 2018, at 4:35 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

I agree that makes sense.

Do you agree that there should be normative requirements to match (at least) the PRID?

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Aug 2018 21:05:52 +0000

Hi,

>>>>>>>>> 3. The mechanism seems to assume a single contact binding 
>>>>>>>>> exists at any one time, and that any given REGISTER request 
>>>>>>>>> relates to that binding. How is this expected to work if 
>>>>>>>>> multiple bindings exist at the same time, perhaps with different expiration times?
>>>>>>>>> What if the user has multiple clients that are creating 
>>>>>>>>> bindings, some supporting this mechanism and others not supporting it?
>>>>>>>> 
>>>>>>>> "In case of a 2xx response to the REGISTER request, once the 
>>>>>>>> proxy has forwarded  the REGISTER response towards the UA, if 
>>>>>>>> one of the contacts in the REGISTER  response matches the 
>>>>>>>> Request-URI of the SIP request to be forwarded, and if that  
>>>>>>>> contact has not expired, the proxy can forward the SIP request 
>>>>>>>> towards the UA, using normal SIP procedures. If none of the 
>>>>>>>> contacts of the most recent REGISTER 2xx response and 
>>>>>>>> Request-URI do not match, the proxy MUST reject the SIP request 
>>>>>>>> with a 404 (Not Found) response.²
>>>>>>> 
>>>>>>> For example, what happens if I have multiple clients, all using 
>>>>>>> the push service? What if not all are using the push service? 
>>>>>>> What if the proxy is in path for all of them? What if it is only in the path for some of them?
>>>>>> request will only contain one of the contacts in the R-URI. How 
>>>>>> the "home proxy" decides which contact to place in the R-URI is 
>>>>>> outside the scope of the document.
>>>>> 
>>>>> The push-proxy is on the registration path for both of them. The 
>>>>> push proxy receives an inbound INVITE that has been targeted to client A. Further assume that client A has lost it’s network connection.
>>>>> 
>>>>> contacts for both A and B. I _think_ that will cause the push proxy 
>>>>> to forward the INVITE towards A, which will fail.  (Maybe that’s okay, as it is pretty much the same as what would happen without push).
>>>> 
>>>>> But as a variation, imagine the home proxy parallel forked the 
>>>>> INVITE to both A and B. The push proxy requests notifications to both clients. Only B sends a REGISTER.
>>>> The INVITEs will have different R-URIs, so they will be handled 
>>>> separately from each other. If only B sends a REGISTER, the INVITE 
>>>> addressed to B will be forwarded (assuming the contact of the REGISTER matches the R-URI of the INVITE). The INVITE addressed to A will fail.
>>> 
>>> My confusion was around how the push-proxy knows which one of the 
>>> INVITEs the REGISTER matches up with. I had read things to say that 
>>> this was determined by matching one of the contacts in the REGISTER _response_. Since the REGISTER response would contain 
>>> both contacts, it would match both INVITEs.
>>> 
>>> Assuming multiple clients for the same user still have different 
>>> PRIDs , I guess that makes sense. But I think this needs more detail and a stronger (probably normative statement).
>>> In particular, since much of the section talks about matching 
>>> contacts in responses, this match needs to happen against the 
>>> REGISTER _request_, right? Since the PRID is a URI parameter, would 
>>> it make sense to say that the REGISTER contact URI and the inbound request R-URI MUST both contain the same push-related parameters?
>> 
>> Ok, so the matching is done against the REGISTER request, but unless the proxy is able to authenticate the sender of the REGISTER 
>> it still needs to wait for the REGISTER response before it forwards the SIP request.
>

The currently assumption is that the whole URI, including the PRID, must match.

(Note that when I talk about 'contact' I refer to the URI that is included in the REGITER/Contact and INVITE/R-URI).

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Fri, 24 Aug 2018 17:05:32 -0500

> On Aug 24, 2018, at 4:05 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

But we are talking about more than just the SIP URI matching rules from 3261, right? (Where a URI without the push parameters will match one that has them)

> (Note that when I talk about 'contact' I refer to the URI that is included in the REGITER/Contact and INVITE/R-URI).

Sure.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 26 Aug 2018 12:02:10 +0000

Hi,

>>>>>>>>>> Request-URI do not match, the proxy MUST reject the SIP 
>>>>>>>>>> request with a 404 (Not Found) response.²
>>>>>>>>> 
>>>>>>>>> That's better, but I don't think it¹s enough. The draft needs 
>>>>>>>>> to explicitly discuss the implications of multiple clients, and 
>>>>>>>> Even if a client has registered multiple contacts, the inbound 
>>>>>>>> SIP request will only contain one of the contacts in the R-URI. 
>>>>>>>> How the "home proxy" decides which contact to place in the R-URI 
>>>>>>>> is outside the scope of the document.
>>>>>>> 
>>>>>>> before the proxy decides to fail the transaction, client B sends 
>>>>>>> a register request. The _response_ to that request will contain 
>>>>>>> the contacts for both A and B. I _think_ that will cause the push 
>>>>>>> proxy to forward the INVITE towards A, which will fail.  (Maybe that’s okay, as it is pretty much the same as what would happen without push).
>>>>>> 
>>>>> this was determined by matching one of the contacts in the REGISTER 
>>>>> _response_. Since the REGISTER response would contain both contacts, it would match both INVITEs.
>>>>> 
>>>>> binding refresh REGISTER request (even if the most recent contact 
>>>>> and the Request-URI of the SIP request do not match).”
>>>>> 
>>>> Ok, so the matching is done against the REGISTER request, but unless 
>>>> the proxy is able to authenticate the sender of the REGISTER it still needs to wait for the REGISTER response before it forwards the SIP request.
>>> 
> But we are talking about more than just the SIP URI matching rules from 3261, right? (Where a URI without 
> the push parameters will match one that has them)

Ok, I hear what you are saying. That's a good catch.

The 3261 rules are used, but in addition the PRID uri parameter also has to match. I guess that should be clarified.

Regards,

Christer