Subject: [sipcore] draft-ietf-sipcore-sip-push-04 - Usage for mid-dialog requests

From: Yehoshua Gev <[email-masked]>
Date: Thu, 8 Feb 2018 10:26:47 +0200

Hi,

According to the following paragraph in section 5.3, it is not clear what
should be the proxy behavior if it encounters a pn-* parameters on Req-URI
of mid-dialog requests:

   When the SIP proxy receives (or, in case the proxy is the SIP
   registrar, creates) a SIP request for a new dialog (e.g., a SIP
   INVITE request) or a non-dialog SIP request (e.g., a SIP MESSAGE
   request) aimed for a SIP UA, if the Request-URI of the request
   contains a pn-provider, a pn-prid and a pn-param (if required for the
   specific PNS provider) SIP URI parameter, the proxy triggers a push
   request towards the PNS associated with the PRID.  After that the
   proxy forwards the SIP request towards the UA using normal SIP
   procedures.

I'm also not sure what "non-dialog SIP request" refers to exactly.

Especially that a SIP proxy according to 3261 can be transaction-stateless
or transaction-stateful, but not dialog-stateful, it will usually have the
same behavior for mid- and out-of-dialog requests.

That's said:
- If push notification should be triggered also for mid-dialog requests,
the UA should always include the pn-* parameters in the Contact header, and
not just for REGISTER.
- If push notification should not be triggered for mid-dialog requests,
there should be some mechanism for preventing it. For example, if GRUU is
used, a GRUU Contact sent by the UA for INVITE might be replaced by a proxy
to the Contact of the REGISTER that contains pn-* parameters, and those
will later appear on the Req-URI of mid-dialog requests.

I see now that on a reply to Dale, Christer has written "Mid-dialog
requests will not trigger push", so maybe a simple solution is adding to
the paragraph above another prerequisite of having a To-tag present (how
else will a proxy differentiate between INVITE and re-INVITE?).

Another question regarding a SIP proxy that is not a registrar.
In Section 1, it's written:

   When a SIP UA registers to a Push Notification Service (PNS), ...

   A SIP proxy (e.g., the SIP registrar) will
   store a mapping between the registered contact and the PRID.

Is the mapping necessary at the proxy? Isn't it enough that the parameters
will arrive in the Req-URI?

Thanks,
Yehoshua Gev

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 8 Feb 2018 15:03:07 +0000

Hi Yehoshua,

>According to the following paragraph in section 5.3, it is not clear what should be the proxy behavior if it 
>encounters a pn-* parameters on Req-URI of mid-dialog requests:
>

Requests that do not create, or are sent within, a dialog. 

>Especially that a SIP proxy according to 3261 can be transaction-stateless or transaction-stateful, but 
>not dialog-stateful, it will usually have the same behavior for mid- and out-of-dialog requests.

Well, in order to support SIP Push the proxy will need to maintain enough state in order to be able to do so.

>That's said:
>- If push notification should be triggered also for mid-dialog requests, the UA should always include the pn-* parameters 
>in the Contact header, and not just for REGISTER.
>- If push notification should not be triggered for mid-dialog requests, there should be some mechanism for 
>preventing it. For example, if GRUU is used, a GRUU Contact sent by the UA for INVITE might be replaced 
>by a proxy to the Contact of the REGISTER that contains pn-* parameters, and those will later appear on the 
>Req-URI of mid-dialog requests.
>
>I see now that on a reply to Dale, Christer has written "Mid-dialog requests will not trigger push", so maybe a simple 
>solution is adding to the paragraph above another prerequisite of having a To-tag present (how else will a proxy 
>differentiate between INVITE and re-INVITE?).

I don’t think it within the scope of the push document to describe such things – it’s part of RFC 3261.

>Is the mapping necessary at the proxy? Isn't it enough that the parameters will arrive in the Req-URI?

I’ll think about that, but you are probably right.

Regards,

Christer