[reSIProcate] DUM Behaviour after sending a REFER

[Scott Godin <slgodin@xxxxxxxxxxxx>]

Current DUM behavior/callbacks after sending a REFER is:

1. If non-2xx response is received for refer, generate onReferRejected.
2. If first Notify from peer - does not terminate the Client Subscription - generate onReferAccepted.
3. If first Notify from peer - ends the Client Subscription - generate onTerminated(ClientSubscription...) and onReferRejected.

 

Note:  Not all endpoints send a Notify 100 if they choose to accept a refer.

 

I think we are potentially not handling the following scenario correctly: 

First Notify from peer contains SipFrag/200 and state=terminated.  We will end up calling onReferRejected.

 

Some other strange behavior is the difference in callbacks in the following 2 scenarios:

Note:  Scenario 2 does not contain a Notify SipFrag/100.

Scenario 1:

1. DUM sends Refer to bad destination/URI.
2. peer sends 2xx for Refer
3. peer sends Notify SipFrag/100 - Dum 200's Notify. - onReferAccepted is called.
4. peer sends Notify SipFrag/404 - Dum 200's Notify - onTerminated(ClientSub..) is called

 

Scenario 2:

1. DUM sends Refer to bad destination/URI.
2. peer sends 2xx for Refer
3. peer sends Notify SipFrag/404 - Dum 200's Notify - onTerminated(ClientSub..) is called and onReferRejected is called.

 

Thoughts?  Should we require that the peer send a Notify/100 to have consistent behavior?

 

To add consistency and fix the problem mentioned, we could call onReferAccepted on the first Notify, regardless of the content of the Notify.  onReferRejected would only be called if a non 2xx response is received for the Refer request itself.  This would mean that both scenario 1 and 2 have the same callbacks (onReferAccepted and onTerminated(ClientSub..)).

 

Scott