[Sip] RE: [Sip-implementors] Questions about Dialogs

["Brett Tate" <brett@broadsoft.com>]

Moving the thread to the SIP list to ensure
that this is correct understanding
and direction of the sip specifications.

The thread deals with calls and subscriptions
which sharing the same dialog.

It covers 4 main topics:
A) Which events and responses can retarget a
   dialog by supplying a new Contact?
   Current answer: INVITE, UPDATE, SUBSCRIBE,
   NOTIFY, their 2xx responses, and INVITE
   101-199 responses.

B) What is the best way to resolve retargeting
   race conditions?
   Current answer: assume no retries occurred
   and always use last received.

C) Does a received 481 trigger the releasing
   of call and all subscriptions on the dialog?
   Current answer: yes.

D) Can a call be established on a dialog which 
   currently only has subscriptions?
   Current answer: yes.

The rest of this email is in response to
one of the emails on sip-implementors.

-------

> > 1a) It makes the presence of a To-tag no
> >     longer sufficient enough to distinguish 
> >     an invite from re-invite.
> 
> In my experience, that's never really been 
> all that useful.  

It is useful for proxies and B2BUA's.

> You always have session state 
> for ongoing sessions; you can use its absence 
> or presence to determine whether an INVITE
> is a re-INVITE.

After a restart, the dialog state cannot be
trusted by proxy or B2BUA.  A B2BUA sending 
a re-invite to audit the dialog might be
interpreted as a new call at the UAS.  This
would especially be true if the UAS allows
subscriptions to be remembered or revived 
after a restart.

Another aspect is the following:
A subscribes B.
A calls B on the dialog.
A sends BYE and receives INVITE prior 
to BYE's 200 response.  Should A assume
this was re-invite or a call back?  Because
of udp retries the wrong decision might
be made by the UAS or proxy.

Another aspect is the following:
A subscribes B.
A calls B on the dialog.
A sends BYE. 
B or proxy sends a failure response.
B sends INVITE to A.
Should A and proxies treat this as
an invite or re-invite?
 
> > 1b) How does a 481 response to an INVITE 
> >     over a subscription dialog effect the 
> >     subscription dialog?
> 
> Consistency dictates that it would remove 
> the subscription. This should be clarified. 
> I've opened a bug.

I guess the sending of a 481 to a NOTIFY,
also triggers a release of a call
and cancellation of all subscriptions 
(both directions) on the dialog.

> > Should a 2xx invite response Contact take 
> > precedence over a just received SUBSCRIBE?
> 
> Depends on which you receive last.

Received last does not guarantee sent last.
 
> > How do we know which was actually sent
> > first by the called party?
> 
> Should a 2xx INVITE response Contact take 
> precedence over a just received INVITE?
> How do we know which was actually sent
> first by the called party?
> It's the same question.

It isn't the same question since a
dialog only supports 1 outstanding 
INVITE; otherwise a 491 is triggered.

However the UPDATE without sdp might 
have the same problem.

> > Without timestamping all requests and 
> > responses, one solution for all 
> > these race conditions is to immediately 
> > try multiple locations to resolve the 
> > ambiguity.
> 
> Or you could just refrain from retargeting
> ever few milliseconds like you're hopped up on
> PCP. :)

I agree.  However I'm not sure how all 
devices intend to retarget during mobility,
fault, and load triggered situations.

> To be fair, there are some corner cases that
> can pop up. As I point out above with the
> INVITE/INVITE response problem above, though,
> these dialog handling problems are problems
> with the base spec, not the extensions. We should
> probably have a discussion about this particular
> race condition on the SIP list.
 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip