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

From: "Brett Tate" <[email-masked]>
Date: Tue, 5 Nov 2002 17:18:14 -0500

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Wed, 6 Nov 2002 10:22:55 +0200

redirected to sip...

> -----Original Message-----
> From: ext Adam Roach [mailto:[email-masked]]
> Sent: Tuesday, November 05, 2002 9:40 PM
> To: Khartabil Hisham (NMP/Helsinki); Adam Roach;
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sip-implementors] Questions about Dialogs
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > 
> > May I suggest that we only allow target refresh requests to 
> > have the same method as the request that created the dialog. 
> > i.e.: only a reINVITE can be target refresh requests for a 
> > dialog created by INVITE, only reSUBSCRIBE can be target 
> > refresh requests for a dialog created by SUBSCRIBE.
> > 
> > For a dialog created by INVITE, a SUBSCRIBE does not update 
> > the target. For a dialog created by SUBSCRIBE, an INVITE does 
> > not update the target.
> > 
> > This is the only way to do it to avoid complexity and 
> > confusion. Otherwise you got to start asking about REFER and 
> > other extensions that create dialogs.
> > 
> > I would prefer implementors to be able to build a generic 
> > dialogs module in their stack that doesn't need to know about 
> > methods. I mean what if I send a MESSAGE within a dialog? my 
> > generic dialogs module no longer can be method agnostic 
> > because it has to know that MESSAGE does not refresh a 
> > target, but it has to know that SUBSCRIBE does... too complicated.
> 
> How does your generic dialogs module know not to create a dialog
> when you send a MESSAGE that doesn't correspond to an existing
> dialog?

Its up to the user of the module to know. Like a session module on top of it. I don't want to update my dialogs module for every extension. I'll just build modules on top of it. Anyway, this is too much architecture stuff.

> 
> You already need to keep track of a variety of attributes for
> each method, such as which messages can start a dialog and which
> can't; in other words, you can't have generic handling for
> unknown methods. You must assign them attributes before your
> dialog manager can do anything sensible. 
> 
> Tracking which method initiated a dialog is no more complicated
> than tracking which methods can retarget.
> 
> That said, allowing only the initiating method to retarget can be
> a rather severe restriction. I may have application logic that
> knows that it needs to retarget at some point, and it does
> so by sending an INVITE. However, with your proposal, that
> would fail if the dialog had been created with a SUBSCRIBE*.
> Instead, you'd need the application to keep track of which came
> first and use it for retargeting. Now, that seems messy.
> 
> /a
> 
> * What? How would one plausibly get an INVITE on a dialog
>   created by a SUBSCRIBE, you ask? I'm glad you did. Imagine
>   that I've subscribed to the terminal state of the phone
>   on your desk, because I want to get ahold of you as soon
>   as you get off the phone. When I finally get a NOTIFY to
>   let me know that your terminal has transitioned to a "free"
>   state (i.e. on-hook), I want to send an INVITE. Of course,
>   I want to make sure I only contact that one terminal that
>   just became free. The only way I can reliably do this is
>   by sending an INVITE in the same dialog. There you go.

This example doesn't clarify the need for an INVITE to retarget a dialog initiated with a SUBSCRIBE. Its actually saying that an INVITE needs to use the same target that was established with the SUBSCRIBE.

Regards,
Hisham