[reSIProcate] DUM Behaviour after sending a REFER

[Scott Godin]

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

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20050421/b65c317e/attachment.htm>