Re: [reSIProcate-users] Any way to kill a DUM subscription in case of deregistration?

["Brody, Chris - Acision" <chris.brody@xxxxxxxxxxx>]

Thanks for the help-the regevent mechanism looks much cleaner and is more consistent with the example call flow in RFC 3680, section 6.

 

---

From: Adam Roach [mailto:adam@xxxxxxxxxxx]
Sent: 22 April 2009 20:01
To: Brody, Chris - Acision
Cc: 'resiprocate-users@xxxxxxxxxxxxxxx'
Subject: Re: [reSIProcate-users] Any way to kill a DUM subscription in case of deregistration?

 

Brody, Chris - Acision wrote:

My confusion deepens. You originally said you were subscribing "to the

reg event." The body of a reg event subscription (RFC 3680) contains a

body of type "application/reginfo+xml". You say the NOTIFY contains

PIDF, which would imply this is a presence subscription (RFC 3856).

These are very different things. Which are you trying to do?

/a

Sorry, I should have referred to the reginfo ("application/reginfo+xml"). In fact, we send the SUBSCRIBE without a body. In the past, we had only done this for a special 3GPP flag but will be using more information in the future.

Okay. With the reg event package, the notifier is generally the registrar, not the UE -- this is certainly the case in a 3GPP network. The only diagram that really makes sense that remotely resembles what you've sent looks like this:


       Client               S-CSCF         Application Server
          |(1) REGISTER        |                    |
          |(Expires: 3600)     |                    |
          |------------------->|(2) REGISTER        |
          |                    |(Expires: 3600)     |
          |                    |------------------->|
          |                    |(3) 200 OK          |
          |                    |<-------------------|
          |(4) 200 OK          |                    |
          |<-------------------|                    |
          |                    |(5) SUBSCRIBE       |
          |                    |<-------------------|
          |                    |(6) 202             |
          |                    |------------------->|
          |                    |(7) NOTIFY          |
          |                    |------------------->|
          |                    |(8) 200 OK          |
          |                    |<-------------------|


Note that steps (2) & (3) are actually a very old R4 mechanism that has since been replaced by regevent. There is no release of the 3GPP IMS network that uses both the "3rd party registration" mechanism and the regevent subscription mechanism. In other words, I would expect *either* (2)-(3) happen, *or* (5)-(8) to happen -- not both.

/a

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.