Subject: [Sip] SIP INFO

From: Eric Burger <[email-masked]>
Date: Sun, 22 Mar 2009 10:59:01 -0700

In the hopes of making the discussion as short as possible in SIPPING:

This is what we have consensus on the list:
1. Change all occurrences of "dialog mumble" with "dialog parameters"

2. Fix Table 1 to remove archaic references to 2543

3. Clarify language for overlapping INFOs and the "nil" package

Open issues:
We all agree on what the text says for the INVITE, UPDATE, and ACK  
methods, as well as the 101-299 (stuff counts) and 300-699 (something  
is broken, so it does not matter) response codes.

It is probably sensible to exclude 100 from Recv-Info processing.   
Work for you?

What about PRACK/PRACK 2xx?  My vote is they count like everything  
else.  What about you?

Likewise, what about REFER/REFER 2xx?  My vote here is INFO packages  
would be nonsensical during a refer, but perhaps you have a use case?   
If so, they work like everything else.

The current text is pretty adamant that a missing Recv-Info means you  
do not (want to) understand Info Packages.  If you start with a Recv- 
Info and you later drop the Recv-Info header, all bets are off.  Are  
you happy with that?  Since we do have Recv-Info: nil, we do have the  
opportunity to say we only change the Info Package set if a Recv-Info  
header is present.  What do you think?

Responses to the list now will hopefully make the discussion go swiftly.

Likewise, if I have missed something, please bring it up now, NOT at  
the meeting.  Recall this draft has finished WGLC.

See you in SF, if you will be in SF; on Jabber if you will be remote;  
or via e-mail if you will be asynchronous.

---

From: Brett Tate <[email-masked]>
Date: Mon, 23 Mar 2009 06:19:57 -0700

> We all agree on what the text says for the INVITE, UPDATE, 
> and ACK methods, as well as the 101-299 (stuff counts) and 
> 300-699 (something is broken, so it does not matter) 
> response codes.

In case it matters, ACK can't be authenticated and introduces more race conditions.

RFC 3261 did not define Supported and Allow to be optional within an ACK.  I mention it in case there were similar race condition and authentication concerns associated with using ACK to indicate/update what is supported and allowed.

> It is probably sensible to exclude 100 from Recv-Info processing.

Yes.

> What about PRACK/PRACK 2xx?  My vote is they count like everything

Because of race conditions, I prefer the header not be allowed.  However my concerns would be partially alleviated if not required to include Recv-Info to avoid disabling support.

It has been awhile since I read RFC 3262 in depth.  If UAS sends INVITE 2xx while awaiting PRACK, should it return PRACK 481 or PRACK 200 upon receipt of PRACK?  If acceptable to return PRACK 200 during the race condition, should the PRACK's Recv-Info be ignored if received before or after ACK?  If it returns PRACK 200 and UAS receives PRACK 200 after INVITE 200, should the UAC ignore PRACK 200's Recv-Info?

> If so, they work like everything else.

I have no preference, especially if not required to include Recv-Info to avoid disabling support.

> you happy with that?  

No.  It requires uselessly adding the header everywhere.  It increases race condition complications.

It shouldn't be more mandatory everywhere than Supported and Allow.  I'm not opposed to making it mandatory within INVITE, re-INVITE, and their 2xx; it should at least be optional within UPDATE.  Concerning other locations, I'm not opposed to it being optional although it introduces more potential for race conditions.

> Since we do have Recv-Info: nil, we do have the opportunity to 
> say we only change the Info Package set if a Recv-Info header 
> is present.  What do you think?

I like the suggested modification.

If retarget to a device not supporting the RFC, the modification potentially raises the need for a Supported option-tag unless Recv-Info remains mandatory (to avoid disabling) within a few locations.  However B2BUAs can still work around the issue if the working group doesn't want to define an option-tag for the RFC.

> the meeting.  Recall this draft has finished WGLC.

What was the outcome of INFO 489 response MUST trigger release of call discussion?

Thanks,
Brett

---

From: Eric Burger <[email-masked]>
Date: Mon, 23 Mar 2009 06:29:12 -0700

> What was the outcome of INFO 489 response MUST trigger release of  

Whoops - that was slide 2...

•Get a 489, can all still be fine?
	•Option 1: Tear down dialog
		Something is hopelessly broken, give up

	•Option 2: ignore it
		–We say INFO does not change dialog state,
                   and a 489 tearing down dialog changes state
		–But, handling 489 differently for INFO makes INFO “special”
		–But what if I said “package X is OK” in an INVITE, but there is
                   glare between you sending an INFO from package X  
and my
                  dropping X in my ACK?

Thoughts?

---

From: Brett Tate <[email-masked]>
Date: Mon, 23 Mar 2009 06:57:55 -0700

Because of race/glare conditions, I prefer INFO 489 not MUST or SHOULD trigger the release of the call.  Concerning calls, I see little difference between impacts of 489 and 405/501/420.  Thus I prefer option 2.

Option 2 appears reasonably consistent with notes 3 and 12 within RFC 5057 section 5.1.

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Monday, March 23, 2009 9:29 AM
> To: Brett Tate
> Cc: SIP IETF
> Subject: Re: [Sip] SIP INFO
> 
> *Get a 489, can all still be fine?
> 	*Option 1: Tear down dialog
> 	*Option 2: ignore it
> 		-We say INFO does not change dialog state,
> 		-But, handling 489 differently for INFO makes INFO "special"
> 		-But what if I said "package X is OK" in an INVITE, but there
> is

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Mar 2009 10:30:21 -0400

> If so, they work like everything else.

REFER initiates subscription establishment, if not already within a 
dialog. But INFO belongs with INVITE dialog-usages, not subscriptions. 
So the INFO negotiation makes no sense in out-of-dialog REFERs.

If the REFER is within an existing dialog that has an INVITE dialog 
usage, it is still (IIUC) technically not within the invite dialog 
usage. So it shouldn't be used for negotiating INFO packages.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Mon, 23 Mar 2009 08:18:47 -0700

> If the REFER is within an existing dialog that has an INVITE 
> dialog usage, it is still (IIUC) technically not within the 
> invite dialog usage. So it shouldn't be used for negotiating 
> INFO packages.

Paul: Thanks for raising the issues.

Everyone: Is REFER within dialog part of INVITE usage, SUBSCRIPTION usage, or neither?

I'm asking mainly because of REFER 481 impacts; however the answer also has potential implications concerning draft-ietf-sip-info-events.  RFC 5057 appears to imply that it is part of the subscription usage; however I'm not positive if my interpretation and/or RFC 5057 is correct.

If REFER isn't considered part of the INVITE usage, how should REFER 481 be interpreted?  More specifically, should receiver of REFER 481 send BYE?

Thanks,
Brett

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 23 Mar 2009 20:07:14 -0400

On Mon, 2009-03-23 at 08:18 -0700, Brett Tate wrote:
> I'm asking mainly because of REFER 481 impacts; however the answer
> also has potential implications concerning draft-ietf-sip-info-events.
> RFC 5057 appears to imply that it is part of the subscription usage;
> however I'm not positive if my interpretation and/or RFC 5057 is
> correct.
> 
> If REFER isn't considered part of the INVITE usage, how should REFER
> 481 be interpreted?  More specifically, should receiver of REFER 481
> send BYE?

I would argue that the REFER is part of the INVITE usage, because REFER
in that context is intimately related to the INVITE usage -- it is
intended to transfer the INVITE usage/dialog transferred to a different
destination.

And it seems quite safe that if the REFER receives a 481 response, the
INVITE usage must not be functional any more, since the far end of that
usage has denied that it can act on the REFER.

Now it's possible that the REFER, if it is successful, is the first
transaction of the subscription usage.  But I don't think that has any
paradoxical consequences, as by hypothesis, the REFER succeeded.

Dale

---

From: Robert Sparks <[email-masked]>
Date: Mon, 23 Mar 2009 18:09:21 -0700

From a usage point of view, it is far more useful to model REFER as  
if it were a SUBSCRIBE request.
It creates a subscribe usage if it succeeds.
The impact it has on the invite usage if it fails is the same as if a  
FOO request failed (which depends on the failure).

RjS

On Mar 23, 2009, at 5:07 PM, Dale Worley wrote:

> _______________________________________________
> Sip mailing list  https://www.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: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Mar 2009 21:32:33 -0400

> intended to transfer the INVITE usage/dialog transferred to a different

Well, I guess there is that implied association. (Part of the "do what 
*I* had in mind" approach that REFER has.) Since this was never spelled 
out, it could also be simply "while this isn't part of an INVITE usage, 
if there happens to be an INVITE usage, please refer that one."

I guess the question is: would it be valid to send a REFER within an 
existing dialog that had no INVITE usage? If it were valid, presumably 
it would have the same meaning as sending one outside a dialog, except 
that the resulting subscription would share the dialog. I expect that is 
a usage it would be difficult to find in the wild.

Ah, but now I want to reconsider. Remember that REFER can take a method 
name. So, rather than referring an INVITE, I could be referring MESSAGE, 
OPTIONS, BYE, or maybe (????) SUBSCRIBE. In some of those cases, the 
association to the INVITE usage is probably meaningless. (Of course its 
meaningful for BYE.)

> usage has denied that it can act on the REFER.

IIRC, 5057 decided that each dialog usage must get its own 481 before it 
goes away. I don't think there are any cases where a single 481 response 
can make multiple usages go away.

So the important question is whether the REFER is part of the INVITE 
usage and so its 481 takes down the INVITE usage or not. That gets 
especially interesting if  the dialog already had both an INVITE usage 
and a SUBSCRIBE usage. Does it make sense that the refer take down the 
INVITE usage and leave up the SUBSCRIBE usage?

> paradoxical consequences, as by hypothesis, the REFER succeeded.

Yeah, its already so weird, why not a little more weird?

Also, I think it has recently been clarified that the 200 of a SUBSCRIBE 
should not be considered to create a dialog - that its the NOTIFY that 
creates the dialog. If so, then I suppose the same should be true of REFER.

Bottom line: I can live with it either way, but think it should be 
documented one way or the other.

	Thanks,
	Paul

---

From: aayush bhatnagar <[email-masked]>
Date: Tue, 24 Mar 2009 04:00:04 +0030

REFER if placed within the scope of the existing dialog usage of
INVITE will reuse its dialog usage, and create an implicit
subscription for the refer event package at the recipient. However, if
the recipient chooses to reject the in dialog REFER request, the
communication established by the INVITE should not be affected. Such a
rejection scenario implies that the call transfer failed..however the
existing active call should not be torn down.

REFER if sent outside the scope of any exisiting dialog will behave as
a dialog creating request and will establish a subscription at the
recipient as described above. This subscription is only used to notify
the status of the sip session referral to the originator and is
seperate from any other subscribe usage that may have existed at the
recipient.

As far as accessing the referred resource is concerned...using the
method parameter, it depends upon the business logic of the recipient
of the REFER request. You may send a REFER to a conferencing server
with a method INVITE to invite a user to join a conference. A method
parameter with the value BYE would imply removal from the conference
by the server and so on.

I dont think you can include a SUBSCRIBE in the method parameter of
the REFER request. You have no way of telling the event package usage
of the subscription to the recipient, as the event header cannot be
included in the REFER request. Moreover, you can never be sure whether
the subscription usage is even applicable to the recipient or whether
the recipient even supports it.

aayush

---

From: "Doken, Serhad" <[email-masked]>
Date: Tue, 24 Mar 2009 00:17:09 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Monday, March 23, 2009 6:33 PM
> To: Dale Worley
> Cc: SIP IETF; Brett Tate
> Subject: Re: [Sip] Is REFER within dialog part of INVITE or
> subscription usage? (was RE: SIP INFO)
> 
> 
> 
> Dale Worley wrote:

Yes, I think so.

> a usage it would be difficult to find in the wild.

Consider a third party control application that forces an endpoint to register :

REFER sip:phone.doken.com SIP/2.0
Refer-To: <sip:[email-masked];method=REGISTER>

that triggers a REG to the registrar as :

REGISTER sip:[email-masked] SIP/2.0

---

From: "Doken, Serhad" <[email-masked]>
Date: Tue, 24 Mar 2009 00:31:47 -0700

> aayush bhatnagar
> Sent: Monday, March 23, 2009 8:30 PM
> To: Paul Kyzivat
> Cc: SIP IETF; Brett Tate

One can send a out of dialog, norefersub REFER and no dialog is established at the recipient. Only an implicit subscription is created and a NTFY may be sent or not sent at all.

> of the subscription to the recipient, as the event header cannot be

It should be possible to do Refer-To: sip:[email-masked];method=SUBSCRIBE?Event=presence asking REFER receiver to send me a SUBSCRIBE in order to find out about my presence.

---

From: aayush bhatnagar <[email-masked]>
Date: Tue, 24 Mar 2009 13:49:00 +0530

>One can send a out of dialog, norefersub REFER and no dialog is established
at the recipient. >Only an implicit subscription is created and a NTFY may
be sent or not sent at all.
you are right.

>It should be possible to do Refer-To: sip:[email-masked]<[email-masked]>;method=SUBSCRIBE?>Event=presence
asking REFER receiver to send me a SUBSCRIBE in order to find out about >my
presence.

In case the receiver is a server in the network, it must implement the role
of a PNA. If its an endpoint, it will subscribe only after approval of the
human user, else respond back with 400. I am not sure how many presence
clients support forced subscriptions like this.

On Tue, Mar 24, 2009 at 1:01 PM, Doken, Serhad <[email-masked]> wrote:

> One can send a out of dialog, norefersub REFER and no dialog is established
> at the recipient. Only an implicit subscription is created and a NTFY may be
> sent or not sent at all.
>
> >
> It should be possible to do Refer-To: sip:[email-masked]<[email-masked]>;method=SUBSCRIBE?Event=presence
> asking REFER receiver to send me a SUBSCRIBE in order to find out about my
> presence.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Mar 2009 10:34:32 -0400

What you say below is stated as *fact*. But the reason we are having 
this discussion is because its not entirely clear what the proper 
interpretation should be. So I will take your statements as being your 
*opinion* on the subject. Your opinion would be of more value if you 
gave the justifications for it.

More inline.

> parameter with the value BYE would imply removal from the conference

It has been observed before, that REFER is very weak in defining clearly 
what actions a particular REFER should elicit. Because it is unclear, 
your are right that some discretion on the part of the recipient is 
required. However that's a bad thing if the sender and receiver of the 
REFER don't agree on what the action should be.

If I send a REFER to a conference focus, I probably expect it send an 
invite to the URI I supply and include the resulting session as another 
participant in the conference. If the focus decided instead that I just 
wanted it play a message to the recipient and then hang up, then I would 
be displeased.

But that is a digression. My point in bringing up the method was that 
the method potentially may have nothing to do with the INVITE usage even 
when the REFER is sent within a dialog that has an INVITE usage. That is 
an argument for saying that the REFER is not part of the INVITE usage.

> the recipient even supports it.

There was already a reply to this.

I think it is certainly possible to see how you could provide enough 
info to enable the recipient to generate a valid SUBSCRIBE request. It 
is indeed harder to imagine how you could expect the recipient to 
extract any value from the resulting subscription. But that is part of 
the magic of REFER that remains unresolved.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Mar 2009 10:43:25 -0400

> REGISTER sip:[email-masked] SIP/2.0

You are suggesting that first this 3pcc application sends a SUBSCRIBE to 
this UA, establishing a dialog. Then it sends a REFER within the dialog, 
asking the UA REGISTER? That then would presumably result in a 
subscription to the refer event package sharing the dialog with the 
prior subscription. I guess this is *possible*, though I don't know 
*why* it would be done. What would the initial SUBSCRIBE be to, and how 
would it be established before the UA has registered?

Are you aware of such usage in the wild?

(Its incidental to this discussion, but REGISTER presents unique 
challenges because of the way addressing works for it. Contrary to your 
example above, we would typically expect that the To: would contain the 
full URI, while the R-URI would only be sip:doken.com. This would 
require more special case processing.)

	Thanks,
	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 24 Mar 2009 20:16:12 -0400

> a usage it would be difficult to find in the wild.

That's a nice pathological case.  But within the context of the current
5 possible meanings of REFER, it seems to be most parallel to the
out-of-dialog REFER.

> association to the INVITE usage is probably meaningless. (Of course its 

A fascinating possibility!  But I'm not sure that we've ever defined how
a REFER within a simple INVITE dialog, specifying a non-INVITE method
should act.  So there's no analog to follow.

> INVITE usage and leave up the SUBSCRIBE usage?

I think we're a victim of sloppy terminology here.  If I send a REFER,
and the far end responds 481, then clearly the far end knows of no
INVITE usage, or otherwise it would not have responded 481.  So I should
delete my belief that there is an INVITE usage.  Whether we consider the
REFER in question to be "part of" the INVITE usage or not doesn't change
anything -- the 481 is evidence that the far end has no knowledge of the
usage.

However, we do have this fine paradox:  If we assume that a REFER within
an established dialog that has no INVITE usage is to be treated as an
out-of-dialog REFER, then *no* REFER will receive a 481 response!
Indeed, if I send a REFER thinking that there is an active INVITE usage,
but the far end believes the INVITE usage has ended, will cause the far
end to do something (initiate an independent dialog) that is
considerably different from what I expected (transfer the current INVITE
usage).

Dale

---

From: aayush bhatnagar <[email-masked]>
Date: Wed, 25 Mar 2009 02:58:10 +0030

If you send an in dialog request (REFER in our case), then you cannot
decouple its semantics with the existing dialog usage. So saying that
even if i send a REFER within an existing dialog, and still decouple
it from the existing dialog usage will not be possible.
If there were such a requirement, then REFER should have been sent as
a standalone dialog creating request outside the INVITE usage.

The recipient of the in dialog REFER will treat it like it should any
in dialog request. It has no way to decide if this request potentially
had nothing to do with the existing dialog usage.

i agree with you when you say that an indialog refer receiving a 481
would mean that the INVITE dialog has been torn down.

However, a refer dialog usage can also terminate, if the UAC sends a
481 in response to the NOTIFY sent by the UAS (Suppose the transaction
did not match). This scenario may happen irrespective of whether the
REFER was within the invite usage or created its own distinct dialog.
If this happens when REFER was sent within an Invite dialog, then the
UAC will be mistaken to clean up its INVITE dialog state.

I  did not understand one part in the paradox above when you said...
"A REFER within an established dialog having no invite usage to be
considered as an out of dialog REFER"
Do you mean to imply a REFER in some other Subscribe event package
dialog for example?

aayush.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Mar 2009 09:45:03 -0400

Dale Worley wrote:

> INVITE usage, or otherwise it would not have responded 481. 

This is not "clear".

There are (at least) two alternatives, depending on whether the 
recipient believes the REFER to be part of an INVITE usage or not.

If it believes that it must be part of an INVITE usage (in the sense 
that BYE is known to be part of an INVITE usage), then the 481 response 
can mean that there is no INVITE usage, even though there is an existing 
matching dialog without an invite usage.

If the recipient believes that the REFER is *not* part of any usage, 
then there can still be a 481 response, indicating that that there is no 
matching dialog.

This is why its important to agree whether the REFER is to be considered 
part of an INVITE usage.

> So I should

I disagree here.

If the message is sent with dialog id info (notably, a To-tag in 
addition to a From-tag and Call-ID) then it should (or at least may) get 
a 481 response if there is no such matching dialog at the recipient. 
This is true even if the message is then to be treated as an 
out-of-dialog message.

> considerably different from what I expected (transfer the current INVITE

That is why dialog matching should still be done. I have no business 
inventing a To-tag for you. It has to be *your* To-tag. If you don't 
recognize it then you send me a 481.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Mar 2009 10:06:10 -0400

aayush bhatnagar wrote:
> decouple its semantics with the existing dialog usage.

You say "*the* dialog usage" as if there can be only one. There could be 
more than one. It might be coupled to:
- the *only* existing usage
- to *one* of several existing usages
- to *none* of the one or more existing usages

For instance, I could have a dialog with just an INVITE usage (the 
common case) and within that dialog send a REFER of a MESSAGE. That 
MESSAGE really has nothing to do with the INVITE usage.

> So saying that

One can argue that it *should* have been. But that isn't the point of 
this discussion. In many cases using the same dialog as been an 
expedient to ensure reaching the same UA when you aren't sure the remote 
target url for the dialog is in fact routable.

> had nothing to do with the existing dialog usage.

You are being sloppy in your use of "dialog" and "dialog usage", as if 
you are not familiar with RFC 5057. If you aren't, please read it.

> would mean that the INVITE dialog has been torn down.

See my reply to Dale.

> did not match).

You need to spell out more details of the case. If it were the *first* 
NOTIFY, resulting from an in-dialog REFER, then that response would be 
indicative of a screwup somewhere.

However, if there had been a prior NOTIFY on the refer subscription that 
indicated that the subscription was over, and then somehow *another* 
NOTIFY was sent, the 481 would be appropriate, indicating that the 
refer-usage was no longer present.

> This scenario may happen irrespective of whether the

Go read 5057. The usages are to be handled separately. So this should 
*not* provoke the UAC to clean up its INVITE dialog usage.

> Do you mean to imply a REFER in some other Subscribe event package

Yes, that is what I meant. I don't have any meaningful cases in mind, 
but it is a theoretical possibility.

	Paul

---

From: aayush bhatnagar <[email-masked]>
Date: Wed, 25 Mar 2009 21:52:10 +0530

>Go read 5057. The usages are to be handled separately. So this should *not*
provoke the UAC >to clean up its INVITE dialog usage.
I have read the relevant RFC. From 5057:

-Existing implementations that destroy all other usages in the dialog will
continue to function as -they do now, except that peers following the
recommendation will attempt to do things with the -other usages and this
element will return 481s for each of them until they are all gone.

I think it is more feasible to destroy the entire dialog, than keeping on to
'hung' state until all the dialog usages are all gone as suggested above. I
am familiar with implementations that clean up dialog state when they get a
481-dialog does not exist response, even if there were other 'active' usages
of that dialog.

The reason being, that if an implementation cannot find a matching dialog as
characterized by the local tag, remote tag, call-id, local and remote
sequence nos etc and has rejected the request by a 481, there is no point in
keeping the dialog state at the UAC.

As for example, if you receive a 481 response for a REFER sent within the
INVITE dialog, there is no point in keeping the REFER usage alive. You
probably sent the REFER to transfer a call, which the server complains that
the call itself does not exist (481).

Moreover from 5057:

-Processing multiple usages correctly is not completely understood.
-What is understood is difficult to implement and is very likely to
-lead to interoperability problems. The best way to avoid the trouble
-that comes with such complexity is to avoid it altogether.
-When designing new applications or features that use SIP dialogs, do
-not require endpoints to construct multiple usages to participate in
-the application or use the feature.

This is very true. By defining multiple dialog usages, you are essentially
extending the dialog state (as defined by 3261) by adding more attributes to
it (such as subscription duration etc). I cant think of a practical use
case, where a subscription that shared the invite dialog usage still needed
to be preserved, even when the original INVITE dialog was no longer active.

As for example a subscription to the 'conference' event package sent within
the scope of an INVITE dialog. If i leave the conference by sending a BYE,
and my subscription's duration is still valid for an hour...will i still
keep on getting redundant SIP notifications for changes to the membership to
that conference ? In the sense of 5057, the subscribe usage will be
preserved until it expires, or until the UAC explicitly un-subscribes, or
the conference server has to send me a final NOTIFY with my
subsription-state = terminated.

It is not important that 5057 is allowing us many theoretical possibilities
by presenting multiple dialog usages.

What is more important is what extra do we get by reusing a dialog, and how
do implementations leverage upon such a possibility and create meaningful
applications around it ?

I would like to share some examples:

1. As for example an application that can practically leverage upon 5057 may
send a SUBSCRIBE to the 'dialog' event package (rfc 4235) that reuses the
INVITE dialog can be used for creating SIP call tracing applications.

2. Other Implementations may include automatic callback applications by this
mechanism (ring back when my sip phone is idle) etc.

3. Yet another application may send me by pre-paid account balance after i
disconnect my ongoing dialog, as it is subscribed to my dialog state.

In all these example applications, the endpoint receiving the SUBSCRIBE will
need to send a NOTIFY that re-uses its existing INVITE dialog (NOTIFY acting
as a target refresh in the sense of 5057).

Best Regards

aayush

On Wed, Mar 25, 2009 at 7:36 PM, Paul Kyzivat <[email-masked]> wrote:

> For instance, I could have a dialog with just an INVITE usage (the common
> case) and within that dialog send a REFER of a MESSAGE. That MESSAGE really
> has nothing to do with the INVITE usage.
>
>  So saying that
> One can argue that it *should* have been. But that isn't the point of this
> discussion. In many cases using the same dialog as been an expedient to
> ensure reaching the same UA when you aren't sure the remote target url for
> the dialog is in fact routable.
>
> You are being sloppy in your use of "dialog" and "dialog usage", as if you
> are not familiar with RFC 5057. If you aren't, please read it.
>
> indicated that the subscription was over, and then somehow *another* NOTIFY
> was sent, the 481 would be appropriate, indicating that the refer-usage was
> no longer present.
>
> Go read 5057. The usages are to be handled separately. So this should *not*
> provoke the UAC to clean up its INVITE dialog usage.
>
> Yes, that is what I meant. I don't have any meaningful cases in mind, but
> it is a theoretical possibility.
>
>        Paul
>
>
>  aayush.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Mar 2009 16:35:22 -0400

aayush bhatnagar wrote:
> *not* provoke the UAC >to clean up its INVITE dialog usage.
> 

OK, sorry. It just sounded like you might not have.

> -Existing implementations that destroy all other usages in the dialog 
> will continue to function as -they do now, except that peers following 
> the recommendation will attempt to do things with the -other usages and 
> this element will return 481s for each of them until they are all gone.
> 
> I think it is more feasible to destroy the entire dialog, than keeping 
> on to 'hung' state until all the dialog usages are all gone as suggested 
> above. I am familiar with implementations that clean up dialog state 
> when they get a 481-dialog does not exist response, even if there were 
> other 'active' usages of that dialog. 

I'm not surprised. Its often "more feasible" to do the wrong thing than 
the right thing. But that doesn't make it right. While its not written 
in black and white in 3261, there is enough info there to infer that you 
need to treat them separately.

> The reason being, that if an implementation cannot find a matching 
> dialog as characterized by the local tag, remote tag, call-id, local and 
> remote sequence nos etc and has rejected the request by a 481, there is 
> no point in keeping the dialog state at the UAC.

This is all hashed out in 5057. The problem is that the 481 response is 
*ambiguous*. The way to maximize interop is to treat the 481 as meaning 
the least serious thing that it could mean - that only the usage has 
gone away. If it turns out that the whole dialog went away, then you 
will eventually find that out anyway. Of course it doesn't hurt to treat 
it as meaning all the usages went away if you would not continue all of 
them anyway. But if the other usage(s) continue to be of value then it 
you are hurting yourself by assuming they have gone away when they might 
not have.

> As for example, if you receive a 481 response for a REFER sent within 
> the INVITE dialog, there is no point in keeping the REFER usage alive. 
> You probably sent the REFER to transfer a call, which the server 
> complains that the call itself does not exist (481). 

That's not the case of relevance. If you got a 481 for a REFER, the 
refer of course failed, and so there is no refer usage to keep alive.

We are still, in this thread, trying to decide what a 481 to a REFER 
means. I think it won't be ambiguous - that it can *only* mean that the 
whole dialog is gone, since it is never associated with a preexisting usage.

Even so, you would be well advised to probe any existing usages with 
in-usage messages to verify if they are alive, even though most likely 
they are not.

> This is very true. By defining multiple dialog usages, you are 
> essentially extending the dialog state (as defined by 3261) by adding 
> more attributes to it (such as subscription duration etc). I cant think 
> of a practical use case, where a subscription that shared the invite 
> dialog usage still needed to be preserved, even when the original INVITE 
> dialog was no longer active.

We aren't *adding more attributes to it*. It is what it is and has been. 
It has been implicitly legal in spite of the problems. And it *is* used. 
There are even reasonable use cases for independent termination of the 
usages. For instance, a refer usage sharing a dialog with an invite 
usage may meaningfully survive after the invite usage terminates.

> As for example a subscription to the 'conference' event package sent 
> within the scope of an INVITE dialog. If i leave the conference by 
> sending a BYE, and my subscription's duration is still valid for an 
> hour...will i still keep on getting redundant SIP notifications for 
> changes to the membership to that conference ?

> In the sense of 5057, the 
> subscribe usage will be preserved until it expires, or until the UAC 
> explicitly un-subscribes, or the conference server has to send me a 
> final NOTIFY with my subsription-state = terminated. 

IMO that is exactly as it *should* be. If the subscriber doesn't want to 
maintain the subscription, it can simply wipe out the state of the 
subscription. Then when another NOTIFY is received, a 481 will be sent 
because there is no state, forcing the end of the usage.

But *assuming* that the subscription *should* go away when the invite 
ends is, IMO, wrong. There may be valid reasons to retain the subscription.

> It is not important that 5057 is allowing us many theoretical 
> possibilities by presenting multiple dialog usages. 
> 
> What is more important is what extra do we get by reusing a dialog, and 
> how do implementations leverage upon such a possibility and create 
> meaningful applications around it ?
> 
> 1. As for example an application that can practically leverage upon 5057 
> may send a SUBSCRIBE to the 'dialog' event package (rfc 4235) that 
> reuses the INVITE dialog can be used for creating SIP call tracing 
> applications. 
> 
> 2. Other Implementations may include automatic callback applications by 
> this mechanism (ring back when my sip phone is idle) etc.
> 
> 3. Yet another application may send me by pre-paid account balance after 
> i disconnect my ongoing dialog, as it is subscribed to my dialog state.
> 
> In all these example applications, the endpoint receiving the SUBSCRIBE 
> will need to send a NOTIFY that re-uses its existing INVITE dialog 
> (NOTIFY acting as a target refresh in the sense of 5057). 

Sounds like you are in favor of dialog reuse.

	Paul

> Best Regards
> 
> aayush
> 
> 
> On Wed, Mar 25, 2009 at 7:36 PM, Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     aayush bhatnagar wrote:
> 
>     You say "*the* dialog usage" as if there can be only one. There
>     could be more than one. It might be coupled to:
>     One can argue that it *should* have been. But that isn't the point
>     of this discussion. In many cases using the same dialog as been an
>     expedient to ensure reaching the same UA when you aren't sure the
>     remote target url for the dialog is in fact routable.
> 
> 
>     You are being sloppy in your use of "dialog" and "dialog usage", as
>     if you are not familiar with RFC 5057. If you aren't, please read it.
> 
> 
>     You need to spell out more details of the case. If it were the
>     *first* NOTIFY, resulting from an in-dialog REFER, then that
>     response would be indicative of a screwup somewhere.
> 
>     However, if there had been a prior NOTIFY on the refer subscription
>     that indicated that the subscription was over, and then somehow
>     *another* NOTIFY was sent, the 481 would be appropriate, indicating
>     that the refer-usage was no longer present.
> 
> 
>     Go read 5057. The usages are to be handled separately. So this
>     should *not* provoke the UAC to clean up its INVITE dialog usage.
> 
> 
>     Yes, that is what I meant. I don't have any meaningful cases in
>     mind, but it is a theoretical possibility.
> 
>            Paul
> 
> 
>         aayush.
> 
>         On 3/25/09, Dale Worley <[email-masked]
>         <mailto:[email-masked]>> wrote:
> 
>             Use [email-masked]
>             <mailto:[email-masked]> for questions on
>             current sip
>             Use [email-masked] <mailto:[email-masked]> for new
>             developments on the application of sip
> 
>         Use [email-masked]
>         <mailto:[email-masked]> for questions on
>         current sip
>         Use [email-masked] <mailto:[email-masked]> for new
>         developments on the application of sip
> 
>

---

From: aayush bhatnagar <[email-masked]>
Date: Thu, 26 Mar 2009 02:22:10 +0030

I am in favor of dialog reuse as long as i can achieve something by it
practically. Coming from the IMS world, i am always on the lookout for
creating interesting sip apps around new concepts.

This RFC, i think also imposes certain functionality on the sip client
(clients being in a very sorry state in IMS).

aayush

---

From: "Doken, Serhad" <[email-masked]>
Date: Fri, 27 Mar 2009 00:13:47 -0700

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, March 24, 2009 7:43 AM
> To: Doken, Serhad
> Cc: Dale Worley; SIP IETF; Brett Tate
> >> that the resulting subscription would share the dialog. I expect
> that
> >> is

3rd party contact center desktop monitoring application is used by the supervisor to see agent's activities. Thru a CTI <->SIP translator, it SUBs to the agent's presence. Once the customer service agent comes in the morning and turns his phone's status to Online(Open), app notices this and forces it to Register. At the end of the day when agent leaves, does the opposite and de-registers it. Thus, it is made sure that they only get billed for the time that agent was registered(online) by the service provider.

> Are you aware of such usage in the wild?

I have seen somewhat similar examples. If you are offering enough stimulus/TARP money, wild frontiers will get closer.

It's mostly used for Xfer however as you alluded to, REFER is implicit or ambiguous that it is open to be used as the Swiss knife if I wanted the other side to do something for me. As long as the sender and receiver know/understand what is meant or the context(especially if they are from the same vendor), everything is fine, if not misinterpretations may happen.

> full URI, while the R-URI would only be sip:doken.com. This would

You are right.

Thanks,
Serhad

---

From: "Doken, Serhad" <[email-masked]>
Date: Fri, 27 Mar 2009 00:13:34 -0700

Perhaps presence was not the best example there given what is supported today though that should not limit the imagination since new services/devices pop up every day. Point is  this can be enabled by the basic Sip building blocks.

Event=kpml will do for a use case that an endpoint tells the server that it wants the key presses to be monitored.

I was making the case that SUB can be included in method parm of REFER.

Serhad

From: aayush bhatnagar [mailto:[email-masked]]
Sent: Tuesday, March 24, 2009 1:19 AM
To: Doken, Serhad
Cc: Paul Kyzivat; SIP IETF; Brett Tate
Subject: Re: [Sip] Is REFER within dialog part of INVITE or subscription usage? (was RE: SIP INFO)

>One can send a out of dialog, norefersub REFER and no dialog is established at the recipient. >Only an implicit subscription is created and a NTFY may be sent or not sent at all.

you are right.

>It should be possible to do Refer-To: sip:[email-masked]<mailto:[email-masked]>;method=SUBSCRIBE?>Event=presence asking REFER receiver to send me a SUBSCRIBE in order to find out about >my presence.

In case the receiver is a server in the network, it must implement the role of a PNA. If its an endpoint, it will subscribe only after approval of the human user, else respond back with 400. I am not sure how many presence clients support forced subscriptions like this.
On Tue, Mar 24, 2009 at 1:01 PM, Doken, Serhad <[email-masked]<mailto:[email-masked]>> wrote:

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> aayush bhatnagar

> of the subscription to the recipient, as the event header cannot be
It should be possible to do Refer-To: sip:[email-masked]<mailto:[email-masked]>;method=SUBSCRIBE?Event=presence asking REFER receiver to send me a SUBSCRIBE in order to find out about my presence.

> On 3/24/09, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
> >
> >
> > Dale Worley wrote:
> > Use [email-masked]<mailto:[email-masked]> for questions on current sip
> > Use [email-masked]<mailto:[email-masked]> for new developments on the application of sip
> >
> Use [email-masked]<mailto:[email-masked]> for questions on current sip
> Use [email-masked]<mailto:[email-masked]> for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Mar 2009 08:08:01 -0400

> 3rd party contact center desktop monitoring application is used by the supervisor to see agent's activities. Thru a CTI <->SIP translator, it SUBs to the agent's presence. Once the customer service…

I find this less than compelling. How does the monitoring application 
discover and address the UA to establish the subscription? If that was 
possible, then the UA must have a globally routable URI that is known to 
the application. And that could be used to send an out-of-dialog REFER.

	Thanks,
	Paul

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 27 Mar 2009 13:33:36 +0100

That, AND why would you not use the OPEN line button to just REGISTER? And
make the application be notified that the registration/deregistration
happened. You could for example route the registrations through the
application hosting proxy to the registrar. Or have like in IMS the
possibility for the registrar to notify an application server upon
registration of a particular user. Much simpler.

/Hans Erik van Elburg

On Fri, Mar 27, 2009 at 1:08 PM, Paul Kyzivat <[email-masked]> wrote:

>> 3rd party contact center desktop monitoring application is used by the
>> supervisor to see agent's activities. Thru a CTI <->SIP translator, it SUBs
>> to the agent's presence. Once the customer service agent comes in the
>> morning and turns his phone's status to Online(Open), app notices this and
>> forces it to Register. At the end of the day when agent leaves, does the
>> opposite and de-registers it. Thus, it is made sure that they only get
>> billed for the time that agent was registered(online) by the service
>> provider.
>>
>
> possible, then the UA must have a globally routable URI that is known to the
> application. And that could be used to send an out-of-dialog REFER.
>
>        Thanks,
>        Paul