Subject: [Sip] INFO: A recap, sense of consensus and a proposal for direction.

From: Dean Willis <[email-masked]>
Date: Wed, 24 Oct 2007 14:18:41 -0500

Wow, this has been a heartily discussed topic.

I'd like to recap some points I think we have a mostly-working  
consensus on:

1) INFO is underspecified and lacks a satisfactory negotiation  
mechanism for usages thereof.

2) We need more than just content-type and content-disposition to  
describe and negotiate usages of INFO. The event package nomenclature  
seems to satisfy this need.

3) SIP Events (RFC 3265) could functionally replace all uses of INFO,  
but there are reasons (primarily relating to overhead and complexity)  
for the fact that we continue to see deployments using INFO.

4) The situation relating to INFO and the angst and confusion  
stemming from it are sufficiently motivating for us to at least  
heartily debate the topic, and presumably motivating enough for us to  
actually tackle a solution at the working group level.

5) We do NOT believe that just deprecating INFO will make the problem  
go away.

6) We believe that something that allows events to be negotiated as  
part of an INVITE-initiated dialog usage would satisfy the majority  
of the requirements.

Some less-consensed items include:

7) Use of NOTIFY, INFO, or some other method for the invite-dialog  
event method. We have a majority position that is best described as  
"anything but NOTIFY", and the remainder is roughly split on INFO vs  
something else.

8) Do we use the same registry and review process for invite-dialog  
events as for subscribe-dialog events? This seems to be in part  
predicated on whether any events will occur in both types of dialogs.  
The emerging consensus seems to be that at least some events could be  
used in either dialog type, and that therefore a single registry and  
process is needed. However, we probably need to add a column to the  
registry for the dialog-type.

9) While we agree that we need to negotiate directionality of event  
flow (being able to send an event is not the same as being able to  
receive it), we're up in the air on mechanism. We have proposals for  
either replacing Allow-Events (in INVITE request) with two new header  
fields such as "Send-Events" and "Receive-Events", or of extending  
each event-package name with a sub-parameter indicating  
directionality similar to those used in SDP (send, recv, sendrecv or  
the like). While functionally equivalent, the first fits into our  
existing IANA registries more readily and is therefore easier to  
document.

These leads to a concrete proposal:

I propose we develop a new RFC that extends RFC 3265 and obsoletes  
RFC 2976.

This RFC will document use of event bodies in INFO messages exchanged  
in dialog usages established by SIP INVITE transactions. This will  
include definition of the "Send-Events" and "Recv-Events" header  
fields, use of those header fields in INVITE transactions to provide  
an offer/answer exchange, definition and use of a new option tag for  
this extension, and the needed changes to the registry established by  
RFC 3265.

There may then be a need for a subsequent RFC or RFCs to extend RFC  
3398 (ISUP) and RFC 4498 (QSIG) for consistency with the new model of  
INFO.

So, how does this sound to people?

--
Dean

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Oct 2007 23:36:57 -0400

Dean,

Nice summary.

I generally agree with what you have written.

My major concern is with the negotiation mechanism. In particular I 
think it needs to be done as a two-way handshake, not three way. A three 
way negotiation will not work well with 3pcc.

	Thanks,
	Paul

Dean Willis wrote:
> I'd like to recap some points I think we have a mostly-working consensus 
> on:
> 
> 1) INFO is underspecified and lacks a satisfactory negotiation mechanism 
> for usages thereof.
> 
> 4) The situation relating to INFO and the angst and confusion stemming 
> from it are sufficiently motivating for us to at least heartily debate 
> the topic, and presumably motivating enough for us to actually tackle a 
> solution at the working group level.
> 
> 5) We do NOT believe that just deprecating INFO will make the problem go 
> away.
> 
> 6) We believe that something that allows events to be negotiated as part 
> of an INVITE-initiated dialog usage would satisfy the majority of the 
> requirements.
> 
> 
> 7) Use of NOTIFY, INFO, or some other method for the invite-dialog event 
> method. We have a majority position that is best described as "anything 
> but NOTIFY", and the remainder is roughly split on INFO vs something else.
> 
> 9) While we agree that we need to negotiate directionality of event flow 
> (being able to send an event is not the same as being able to receive 
> it), we're up in the air on mechanism. We have proposals for either 
> replacing Allow-Events (in INVITE request) with two new header fields 
> such as "Send-Events" and "Receive-Events", or of extending each 
> event-package name with a sub-parameter indicating directionality 
> similar to those used in SDP (send, recv, sendrecv or the like). While 
> functionally equivalent, the first fits into our existing IANA 
> registries more readily and is therefore easier to document.
> 
> I propose we develop a new RFC that extends RFC 3265 and obsoletes RFC 
> 2976.
> 
> This RFC will document use of event bodies in INFO messages exchanged in 
> dialog usages established by SIP INVITE transactions. This will include 
> definition of the "Send-Events" and "Recv-Events" header fields, use of 
> those header fields in INVITE transactions to provide an offer/answer 
> exchange, definition and use of a new option tag for this extension, and 
> the needed changes to the registry established by RFC 3265.
> 
> There may then be a need for a subsequent RFC or RFCs to extend RFC 3398 
> (ISUP) and RFC 4498 (QSIG) for consistency with the new model of INFO.
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 25 Oct 2007 11:09:46 +0100

Dean,

A good summary and proposal. I am not yet 100% convinced we need to do
anything, but if we do the proposal sounds good. Just to correct one
point.

> 3398 (ISUP) and RFC 4498 (QSIG) for consistency with the new 
I think you intended to type RFC 4497 for QSIG. However, that RFC only
deals with interworking between QSIG and SIP. Tunnelling of QSIG over
SIP is specified in ECMA-355 from Ecma-International.

For both SIP-T and QSIG tunnelling we would need to maintain backwards
compatibility with the existing standards.

John

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 Oct 2007 15:06:17 -0500

> this extension, and the needed changes to the registry established by 

I can support such a plan.

I will continue to argue that the event packages and info packages 
should be independent of each other, but that's a minor detail. I 
generally agree with the larger picture.

/a

---

From: Robert Sparks <[email-masked]>
Date: Thu, 25 Oct 2007 15:43:07 -0500

I'm pretty (actually extremely) unhappy with the idea, but I'll try  
not to throw myself on the tracks in front of it.

Taking a tumble down the slope:

These info packages need to be separate from event packages - there  
may be some
where you just derive an info package from an event package with a  
trival rfc, but it will
_not_ be the case that it will make sense to throw any old event  
package's payload into
an INFO like thing like this (think of the mess you'll get into with  
anything with a partial
payload, and the bigger mess when you get into the infrastructure of  
the framework, including winfo
and eventlists).

And we'd need to specify quite concretely what happens when one of  
these INFOs gets rejected.
In most cases, the call is going to have to go away, and I bet that's  
going to make a lot of people unhappy.

RjS

On Oct 25, 2007, at 3:06 PM, Adam Roach wrote:

>> This RFC will document use of event bodies in INFO messages  
>> exchanged in dialog usages established by SIP INVITE transactions.  
>> This will include definition of the "Send-Events" and "Recv- 
>> Events" header fields, use of those header fields in INVITE  
>> transactions to provide an offer/answer exchange, definition and  
>> use of a new option tag for this extension, and the needed changes  
>> to the registry established by RFC 3265.
>
>

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Thu, 25 Oct 2007 17:12:08 -0400

Why does the call need to go away, if INFO is rejected? Isn't INFO not
supposed to affect call state(s)?

- Sanjay 

>-----Original Message-----
>From: Robert Sparks [mailto:[email-masked]] 
>Sent: Thursday, October 25, 2007 4:43 PM
>To: Adam Roach
>Cc: sip List; Dean Willis
>Subject: Re: [Sip] INFO: A recap,sense of consensus and a 
>proposal for direction.
>
>I'm pretty (actually extremely) unhappy with the idea, but 
>I'll try not to throw myself on the tracks in front of it.
>
>These info packages need to be separate from event packages - 
>there may be some where you just derive an info package from 
>an event package with a trival rfc, but it will _not_ be the 
>case that it will make sense to throw any old event package's 
>payload into an INFO like thing like this (think of the mess 
>you'll get into with anything with a partial payload, and the 
>bigger mess when you get into the infrastructure of the 
>framework, including winfo and eventlists).
>
>And we'd need to specify quite concretely what happens when 
>one of these INFOs gets rejected.
>In most cases, the call is going to have to go away, and I bet 
>that's going to make a lot of people unhappy.
>
>RjS
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 Oct 2007 16:22:09 -0500

> supposed to affect call state(s)?

http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-06.txt

/a

---

From: "Frank W. Miller" <[email-masked]>
Date: Thu, 25 Oct 2007 15:41:33 -0600

Forgive me if this question has already been asked but...

In reading this draft over, which is very interesting, I observe that
for the case of mutual subscription, it would be much simpler to just
disallow the subscribed party to reuse the dialog for the incoming
subscription?

Thanks,
FM

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Thursday, October 25, 2007 3:22 PM
To: Sanjay Sinha (sanjsinh)
Cc: sip List; Dean Willis
Subject: Re: [Sip] INFO: A recap,sense of consensus and a proposal for
direction.

> supposed to affect call state(s)?

http://www.ietf.org/internet-drafts/draft-ietf-sipping-dialogusage-06.tx
t

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 Oct 2007 16:59:22 -0500

> disallow the subscribed party to reuse the dialog for the incoming

Yes. And, with GRUUs, we now have this ability. Absent GRUUs, there was 
no way to guarantee that you ended up talking to exactly the same device 
without re-using dialogs.

/a

> Use [email-masked] for new developments oFrom [email-masked] Thu Oct 25 18:04:28 2007
Date: Thu, 25 Oct 2007 16:59:22 -0500
From: Adam Roach <[email-masked]>
To: "Frank W. Miller" <[email-masked]>
Subject: Re: [Sip] Mutual subscriptions
Cc: "'Sanjay Sinha \(sanjsinh\)'" <[email-masked]>,
	'sip List' <[email-masked]>, 'Dean Willis' <[email-masked]>

> disallow the subscribed party to reuse the dialog for the incoming

Yes. And, with GRUUs, we now have this ability. Absent GRUUs, there was 
no way to guarantee that you ended up talking to exactly the same device 
without re-using dialogs.

/a

---

From: Robert Sparks <[email-masked]>
Date: Thu, 25 Oct 2007 16:59:53 -0500

And there we go... not even 20 minutes.

So, you are right for INFO as we have historically known it.

This new gorgon that Dean is proposing is not like that INFO.

It's something that's carrying state based on (effectively) an  
implicit subscription (or something very much like a subscription,  
but without any of the control infrastructure) in the INVITE.

If something goes _wrong_ in that subscription, you don't have a  
clean separate usage you can tear down and leave the INVITE usage up  
(I expect pushback here, and I anticipate that when you try to _add_  
that clarity, you'll end up most, if not all, of the way to just  
using SUBSCRIBE).

Maybe to avoid the confusion you just pointed to, we could call this  
beast NOTINFO?

RjS

On Oct 25, 2007, at 4:12 PM, Sanjay Sinha (sanjsinh) wrote:

>> I'm pretty (actually extremely) unhappyn the application of sip
>

---

From: Robert Sparks <[email-masked]>
Date: Thu, 25 Oct 2007 16:59:53 -0500

RjS

 with the idea, but

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Oct 2007 19:10:03 -0400

Robert Sparks wrote:
> I'm pretty (actually extremely) unhappy with the idea, but I'll try not 
> to throw myself on the tracks in front of it.
> 
> These info packages need to be separate from event packages - there may 
> be some
> payload, and the bigger mess when you get into the infrastructure of the 

AFAIK nobody is suggesting that by some stroke of the pen all event 
packages will magically become usable via this new mechanism. I agree 
that makes no sense.

It would indeed require some action on each and every one to adapt it to 
work with this new environment. For many it would make no sense to do 
so, and would probably be impossible.

For those where it is possible and desirable I think it will be sort of 
like making a new "skin" for a GUI - the moving parts are all the same, 
though perhaps not all are visible through the new skin, but the look is 
different.

> And we'd need to specify quite concretely what happens when one of these 
> INFOs gets rejected.

I don't understand you here. I just checked dialogusage. As far as I can 
tell, the behavior in there makes perfect sense here. Those errors on 
INFO that tear down the usage or the dialog should do the same here.

If it does turn out that the error handling for this new approach are 
inconsistent with error handling for INFO then we should define a new 
method.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Oct 2007 19:15:04 -0400

Robert Sparks wrote:
> It's something that's carrying state based on (effectively) an implicit 
> subscription (or something very much like a subscription, but without 
> any of the control infrastructure) in the INVITE.
> 
> If something goes _wrong_ in that subscription, you don't have a clean 
> separate usage you can tear down and leave the INVITE usage up (I expect 
> pushback here, and I anticipate that when you try to _add_ that clarity, 
> you'll end up most, if not all, of the way to just using SUBSCRIBE).

My impression is that people are assuming that this way of handling 
events only makes sense when they are tightly related to the INVITE 
usage. So its ok if the kinds of errors that kill usages and dialogs 
kill the INVITE. The kinds of errors that are pertinent only to the 
event notification are typically the kinds of things that only affect 
the transaction anyway.

> Maybe to avoid the confusion you just pointed to, we could call this 

Actually I'm ok with that.

(I was advocating MESSAGE, not INFO. I don't see any great value in INFO 
over anything else.)  :-)

	Paul

---

From: "Henry Sinnreich" <[email-masked]>
Date: Thu, 25 Oct 2007 16:41:55 -0700

Are there some compelling usage scenarios to break the tie?

Henry

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: Thursday, October 25, 2007 5:00 PM
To: Sanjay Sinha (sanjsinh)
Cc: sip List; Adam Roach; Dean Willis
Subject: Re: [Sip] INFO: A recap,sense of consensus and a proposal for
direction.

RjS

---

From: "Frank W. Miller" <[email-masked]>
Date: Thu, 25 Oct 2007 17:48:32 -0600

I mean this a little bit phoceciously, but where is Jonathan in all
this?  When I proposed some INFO based extensions a several years ago,
there was a drumbeat of INFO is going away, don't use it damnit!!

As far as my opinion, I don't really care.  Its just more implementation
effort, or not.  SIP is really turning into a jobs program, job security
forever...

FM

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, October 25, 2007 5:10 PM
To: Robert Sparks
Cc: sip List; Adam Roach; Dean Willis
Subject: Re: [Sip] INFO: A recap,sense of consensus and a proposal for
direction.

> I'm pretty (actually extremely) unhappy with the idea, but I'll try
not 
> These info packages need to be separate from event packages - there
may 
> payload, and the bigger mess when you get into the infrastructure of
the 

different.

> And we'd need to specify quite concretely what happens when one of
these 

	Paul

>>> This RFC will document use of event bodies in INFO messages
exchanged

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 25 Oct 2007 23:48:31 -0400

> going to make a lot of people unhappy.

When I looked at the usage draft a while ago it seemed to me that the failures you're talking about *should* make the call go away.
-hadriel

t.com>
Accept-Language: en-US
acceptlanguage: en-US
Cc: sip List <[email-masked]>, Dean Willis <[email-masked]>

> going to make a lot of people unhappy.

When I looked at the usage draft a while ago it seemed to me that the failures you're talking about *should* make the call go away.
-hadriel

---

From: Robert Sparks <[email-masked]>
Date: Thu, 25 Oct 2007 22:59:10 -0500

On Oct 25, 2007, at 10:48 PM, Hadriel Kaplan wrote:

> When I looked at the usage draft a while ago it seemed to me that  
> the failures you're talking about *should* make the call go away.

Oh - I very much think they should. Sorry if what I wrote above was  
unclear. I'm just expecting that not to be a universally shared  
sentiment (yet).

---

From: Dean Willis <[email-masked]>
Date: Fri, 26 Oct 2007 09:28:17 -0500

On Oct 24, 2007, at 10:36 PM, Paul Kyzivat wrote:

> think it needs to be done as a two-way handshake, not three way. A  
> three way negotiation will not work well with 3pcc.

I should have commented on this in my recap as a point of discussion.  
But I am persuaded by your argument, and support a 2-way transacation  
and that was what was intended in my proposal.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 26 Oct 2007 09:29:37 -0500

> SIP is specified in ECMA-355 from Ecma-International.

Yes, you're right.

> compatibility with the existing standards.

Of course. However, nothing prevents us from ALSO providing a forward- 
compatible and fully-negotiable solution, should we choose to do so.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 26 Oct 2007 09:33:39 -0500

On Oct 25, 2007, at 3:43 PM, Robert Sparks wrote:

> an INFO like thing like this (think of the mess you'll get into  
> with anything with a partial
> payload, and the bigger mess when you get into the infrastructure  
> of the framework, including winfo
> and eventlists).
>
>

I concur. Ever existing event package is defined to work only with  
SUBSCRIBE dialogs. For any of those that needs to work with INVITE  
dialogs, we'd need a an RFC defininging (and IANA registering) the  
new behavior.

Future event packages would have the option of defining and  
registering only INVITE dialog usage, only SUBSCRIBE dialog usages,  
or both.

> that's going to make a lot of people unhappy.

Yes, that's definitely a point to document. I'm not sure I agree that  
a failure-to-grok-a-body response terminates the dialog, but am open  
to discussion.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 26 Oct 2007 09:36:56 -0500

> but without any of the control infrastructure) in the INVITE.

I'd like to point out, it is not an implicit subscription. It's  
explicit. The event package usage was negotiated in the INVITE  
transaction. So even if we followed the current dialog usage model  
and terminated the dialog, that would arguably be a reasonable thing  
to do. The failure-to-understand a body means that there was a  
failure in the offer/answer exchange for the event package, and  
somebody needs to know about it.

--
Dean

---

From: Robert Sparks <[email-masked]>
Date: Fri, 26 Oct 2007 09:45:01 -0500

On Oct 26, 2007, at 9:36 AM, Dean Willis wrote:

> and terminated the dialog, that would arguably be a reasonable  
> thing to do. The failure-to-understand a body means that there was  
> a failure in the offer/answer exchange for the event package, and  

It's just as implicit as the subscription to the refer event package  
is when you accept a REFER, and it's going to suffer from exactly the  
same problems we have there.

So, what's the duration? How do you unsubscribe? How do you learn  
about your permissions to subscribe to the thing (pending vs active  
vs denied)? I'm not really asking for that design right now, just  
pointing out these as examples of the questions that the _implicit_  
subscription you're talking about would have to address - and  
remember the hairier ones after that, like how you cause a full-state  
notify to happen if you get out of sync in some partial scheme.

---

From: Adam Roach <[email-masked]>
Date: Fri, 26 Oct 2007 10:10:38 -0500

Dean Willis wrote:
> registering only INVITE dialog usage, only SUBSCRIBE dialog usages, or 
> both.

But even having a structure that encourages that kind of thinking is bad 
hygiene. Having more than one way to do the same thing in a protocol is 
the fastest and most powerful way to simultaneously decrease 
interoperability and increase implementation burden.

Implementations need to either include all possible mechanisms (I just 
love telling developers that they get to do RFC 4733, KPML, *and* INFO 
if they want to convey DTMF), or they end up not working with everything 
out there. Either outcome is seriously unfortunate.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Oct 2007 11:27:00 -0400

Robert Sparks wrote:
>> transaction. So even if we followed the current dialog usage model and 
>> terminated the dialog, that would arguably be a reasonable thing to 
>> do. The failure-to-understand a body means that there was a failure in 
>> the offer/answer exchange for the event package, and somebody needs to 
>> know about it.
> 
> It's just as implicit as the subscription to the refer event package is 
> when you accept a REFER, and it's going to suffer from exactly the same 
> problems we have there.

I agree with dean that it is explicit. It is a "subscription" in the 
broad sense, but not in the 3265 sense. A formalism for its properties 
will be needed, but we haven't settled on that yet.

IMO it isn't like an implicit REFER subscription. Instead of a new 
dialog usage sharing the same dialog, we end up with some added behavior 
within the invite dialog usage.

I do agree that we must tread carefully here because we are creating a 
new kind of thing that we didn't have before. And it could have 
unintended consequences, just as turned out to be the case with multiple 
dialog usages sharing a dialog.

> So, what's the duration? How do you unsubscribe? How do you learn about 
> your permissions to subscribe to the thing (pending vs active vs 
> denied)? I'm not really asking for that design right now, just pointing 
> out these as examples of the questions that the _implicit_ subscription 
> you're talking about would have to address - and remember the hairier 
> ones after that, like how you cause a full-state notify to happen if you 
> get out of sync in some partial scheme.

These are all good questions that need to be answered.

It may indeed turn out that after all those things are considered it 
will be apparent that the whole thing is a bad idea.

I expect that what people are looking for is simplicity. Namely, when an 
issue such as you mention starts to have a difficult answer then the 
solution is to limit applicability to avoid the problem. But if it turns 
out that the simplifications exclude all interesting uses then again we 
pack up and go home.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Oct 2007 11:36:45 -0400

Adam,

I agree with you on this. And yet people keep using all these different 
things for DTMF, with KPML apparently last in the running.

I know my employer currently implements at least *two* non-standard 
mechanisms for DTMF, plus 4733, in a number of products. Even if we came 
up with a standard way that had the message conserving properties that 
seem to be required, it would then it would have to be added along side 
those.

Perhaps we need a discussion specifically about DTMF - what is happening 
in the real world, and what the chances are for improving that 
situation. (Sounds like a bar BOF to me.)

	Paul

---

From: Adam Roach <[email-masked]>
Date: Fri, 26 Oct 2007 12:20:32 -0500

Paul Kyzivat wrote:
> I agree with you on this. And yet people keep using all these 
> different things for DTMF, with KPML apparently last in the running.

DTMF provides a powerful cautionary tale, but it wasn't the point I was 
trying to make. If we encourage two ways to do things (INFO and NOTIFY) 
for future event packages, this problem will spread beyond DTMF, into a 
variety of new specifications.

So, to make sure I understand what you're agreeing with me on: are you 
specifically agreeing that the arguments I'm making point to needing 
separate namespaces for event packages and INFO packages?

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Oct 2007 13:42:38 -0400

> separate namespaces for event packages and INFO packages?

I'm agreeing with you that having multiple ways of doing things has 
negative consequences. I'm not necessarily agreeing that those 
consequences mean we should not do this, because we currently have 
multiple *unstandardized* ways of doing things and if we can turn that 
into standardized ways it might make things better.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 26 Oct 2007 13:31:57 -0500

> So, what's the duration? How do you unsubscribe?

Isn't the whole point of this proposal that it would linked to be the
duration of the dialog?

Otherwise, you would just SUBSCRIBE.

---

From: Robert Sparks <[email-masked]>
Date: Fri, 26 Oct 2007 13:48:16 -0500

So, the thing we're talking about then is not a subscription.
(You will not use the same code to service it that you would have  
used to service a subcription).

And if you accept that the fates are tightly coupled (as I think you  
are asserting here), then we
_don't_ have separate usages that spring into being and disappear at  
the same time. There's only
one usage - the INVITE usage.

And forgive me for continuing to point, but are you going to address  
the authorization mechanics and if not, what are the simplifying  
assumptions that let us ignore them.

RjS

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 26 Oct 2007 13:52:02 -0500

> Sent: Friday, October 26, 2007 11:48
> To: Audet, Francois (SC100:3055)
> Cc: Dean Willis; Sanjay Sinha (sanjsinh); sip List; Adam Roach
> Subject: Re: [Sip] INFO: A recap, sense of consensus and a 
> proposal for direction.
> 
> (You will not use the same code to service it that you would 
> have used to service a subcription).

Fair enough.

> And if you accept that the fates are tightly coupled (as I 
> think you are asserting here), then we _don't_ have separate 
> usages that spring into being and disappear at the same time. 
> There's only one usage - the INVITE usage.

Agree.

> And forgive me for continuing to point, but are you going to 
> address the authorization mechanics and if not, what are the 
> simplifying assumptions that let us ignore them.

I don't know. 

Again, I'm not the one pushing for this :^)

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Oct 2007 18:04:29 -0400

Robert Sparks wrote:
> (You will not use the same code to service it that you would have used 
> to service a subcription).

Certainly the negotiation and establishment parts are different.

It is possible that the code used to determine when to send a 
notification, and to process an incoming in-dialog notification, could 
be the same for some event types.

That of course would only make sense if both forms were supported by a 
given UA for a particular event type. And it would only be true if the 
implementation *chose* to do it that way. Its clearly a local 
implementation issue.

> And if you accept that the fates are tightly coupled (as I think you are 
> asserting here), then we
> _don't_ have separate usages that spring into being and disappear at the 
> same time. There's only

Yes, I think so. That is the essential simplification that might make 
this attractive to some people.

> And forgive me for continuing to point, but are you going to address the 
> authorization mechanics and if not, what are the simplifying assumptions 
> that let us ignore them.

Well, of course it is the same UAC and UAS, so some authorization is in 
common. But it is true that someone might be permitted to make a call, 
but not to have access to the event data.

In that case I think it is simply a matter of not negotiating the 
capability if it isn't authorized. In that case I guess it is a 
simplification in that there is no way to indicate that forbidden rather 
than unsupported.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 27 Oct 2007 00:13:12 +0200

Hi,

>used to service a subcription).

It's not a subscription usage as defined today.

>are asserting here), then we_don't_ have separate usages that spring into being and disappear at 
>the same time. There's only one usage - the INVITE usage.

Yes! I don't know how many times I've said that :)

>assumptions that let us ignore them.

I guess we would need to think about that, but my first answer would be that we don't need any additional mechanisms than what we already have for the invite dialog.

Regards,

Christer

RjS

---

From: Robert Sparks <[email-masked]>
Date: Fri, 26 Oct 2007 17:24:43 -0500

On Oct 26, 2007, at 5:04 PM, Paul Kyzivat wrote:

> notification, and to process an incoming in-dialog notification,  
> could be the same for some event types.
>
> That of course would only make sense if both forms were supported  
> by a given UA for a particular event type. And it would only be  
> true if the implementation *chose* to do it that way. Its clearly a  
> local implementation issue.
>

I disagree - you are, I think, pointing to potential code reuse for  
dealing with the payload of a NOTIFY.
The code that is involved in dealing with the NOTIFY itself is not  
going to be reusable. Most, if not _all_ of the
code for dealing with a _subscription_ will likely not be reusable.  
That code _has_ to assume the mechanics
of a subscription. (A NOTIFY updates the timer for how long a  
subscription lasts - that notion is gone).

>> And if you accept that the fates are tightly coupled (as I think  
>> you are asserting here), then we
>> _don't_ have separate usages that spring into being and disappear  
>> at the same time. There's only
> Yes, I think so. That is the essential simplification that might  
> make this attractive to some people.
>
> Well, of course it is the same UAC and UAS, so some authorization  
> is in common. But it is true that someone might be permitted to  
> make a call, but not to have access to the event data.
That would well be the normal case for most of the event packages  
that are currently defined (More evidence that its probably not going  
to be the case that the packages for this thing and the packages for  
events are going to closely line up).

> simplification in that there is no way to indicate that forbidden  
> rather than unsupported.
>
> 	Paul
>
>> RjS

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 27 Oct 2007 00:24:54 +0200

Hi,

>seem to be required, it would then it would have to be added along side
 
Correct - what is already out there is most going to stay out there - and there is nothing we can do about that (writing a you-must-not-do-that-RFC won't help). But, if we can provide a more simple way of doing things we will hopefully then see more and more deployments using it.

>Perhaps we need a discussion specifically about DTMF - what is happening in the real world, and what the chances are for >improving that situation.
 
Finally someone who agrees with me that there is a real world outside our Hilton meeting rooms :)
 
> (Sounds like a bar BOF to me.)
 
If the outcome of such bar BOF is simply going to be a we-need-to-go-out-and-make-people-understand-that-they-have-to-implement-RFC-xxx type of statement it's not going to be very useful.
Regards,
 
Christer

        Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 26 Oct 2007 22:55:13 -0500

On Oct 26, 2007, at 9:45 AM, Robert Sparks wrote:

>>> implicit subscription (or something very much like a  
>>> subscription, but without any of the control infrastructure) in  
>>> the INVITE.
>>
> It's just as implicit as the subscription to the refer event  
> package is when you accept a REFER, and it's going to suffer from  
> exactly the same problems we have there.
>
> So, what's the duration?

Until the dialog ends.

> How do you unsubscribe?

BYE.

> How do you learn about your permissions to subscribe to the thing  
> (pending vs active vs denied)?

You don't. Either stuff shows up, or it doesn't. Or, put another way,  
the other end TOLD you that you were authorized when it made the  
offer. There is no "pending", no "denied".

> I'm not really asking for that design right now, just pointing out  
> these as examples of the questions that the _implicit_ subscription  
> you're talking about would have to address - and remember the  
> hairier ones after that, like how you cause a full-state notify to  
> happen if you get out of sync in some partial scheme.

BYE. INVITE.

Seriously, this stuff only makes sense for fairly atomic events.  
Partial notification just doesn't compute. That's why it would be  
silly to say it works for all event packages.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 26 Oct 2007 23:02:17 -0500

> So, the thing we're talking about then is not a subscription.

Right. That's why I called it event notification within an INVITE- 
initiated dialog.

> used to service a subcription).

Of course not. What it is is a negotiation mechanism for INFO. You'd  
use the same code for it that you used for servicing INFO. But now,  
each event-carrying message also has a naming component that tells  
you what you're supposed to be doing with the event notification.

> one usage - the INVITE usage.

Yes, exactly.

> simplifying assumptions that let us ignore them.

The authorization mechanics are obvious and simple. If you're  
authorized for the INVITE dialog, you're authorized for any event  
notifications offered within the INVITE transaction that instantiated  
the dialog.

Or hey, if you decide the peer is unauthorized during a dialog, you  
either end it (with a BYE), or just stop sending the event  
notifications. If they were all that important, the other end will  
eventually send a BYE, right?

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 27 Oct 2007 16:15:22 -0400

> Sent: Friday, October 26, 2007 2:48 PM
> To: Francois Audet
> Cc: Sanjay Sinha (sanjsinh); sip List; Adam Roach; Dean Willis
> Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal for
> direction.
>

Right, I think several of us have said it's not a subscription in the 3265 sense of the word (and it's probably less confusing if we don't use the word "subscription" at all).

> one usage - the INVITE usage.

Precisely.  Exactly how INFO was used before.

> assumptions that let us ignore them.

Actually I think it's clearer for this mechanism than it is for Subscriptions.  With Subscribe, I don't see how an Invite-generating UAC can truly authorize a subscriber as the UAS.  It's clear how a server offering a subscription service such as presence can do it, because the server should know which UA's can subscribe to its service, and can challenge them knowing the user password or whatever.  But how does my phone know any shared secret with which to challenge some random entity subscribing to KPML for an Invite dialog?  With this inline INFO mechanism, it would be based on the Invite.  If the UAC sent the Invite with the send/recv event headers, it's authorizing the receiver of the Invite to send/recv them.  If the UAS wants to accept the events, it responds with such headers.  The INFO message would be handled the same way as re-Invites would, with regard to their acceptance.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Sun, 28 Oct 2007 16:58:16 -0500

> silly to say it works for all event packages.

You misspelled "any."

/a

---

From: Dean Willis <[email-masked]>
Date: Sun, 28 Oct 2007 22:42:30 -0500

>> silly to say it works for all event packages.

No, I don't believe so. It would, for example, function quite well  
with MWI (although not be terribly useful).

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Sun, 28 Oct 2007 23:10:02 -0500

> with MWI (although not be terribly useful).

Which is pretty much my point. I assume you picked a useless example 
because there isn't a useful one. Is there anything better? Let's check 
the IANA registry.

Conference? That doesn't seem to match you assertion that "partial 
notification just doesn't compute." Or are you thinking you'll be 
passing full conference state around in INFO?

Dialog? No, you're in the dialog -- you know how it's going.

KPML? That uses a lot of the SUBSCRIBE mechanics to set up what triggers 
notification. And if the endpoints are interested, send 2833/4733.

MWI? I agree with what you say above -- not terribly useful.

POC settings? You're in a call with the device -- it no longer matters 
whether it will auto answer or whether it's going to bar you from calling.

REG? This gets heavily into the authorization questions Robert was 
raising (unless you're talking to yourself, in which case it's downright 
silly) -- and even if we blithely wave our hands at auth and say "send 
it if you like and don't send it if you don't," what is the use case? 
Why would someone do this?

Refer? Spirits? Winfo? What would those even *mean*?

We've been working on this for the past 7 years, and there's not a 
single reasonable proof of concept that what you're fighting so 
vigorously for has any practical application. The best example you can 
come up with is one you concede is useless. Robert has raised a host of 
reasonable concerns, and I've been pointing out additional sets of 
problems that arise from your proposal.

We know the downsides, and they are non-trivial. To make a fair 
judgment, we need to balance those against the benefits. What are they?

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 30 Oct 2007 11:52:48 -0400

Do you mean this in the context of: "are there any registered 3265-type events which would be useful for this?"  Or do you mean this in the sense of: "are there any events in general which would be useful for this?"

For the former, I tend to agree with you.  I don't see any registered 3265 events which would really be useful for tying to an Invite dialog in an INFO.

For the latter, we've already been discussing one: dtmf.  The next obvious one would be ISUP info exchange (though it's not as clear if it's needed).

But one can also envision future ones.  For example a way to perform a traceroute type thing across b2bua's (like incrementing max-forwards, but not identical).  Or a package for sending vcard info to the caller/called.  Or a package for giving out a jpeg for photo-id, or for call screen display.  Or a package for soft-key maps for a specific call (like a call to a vmail server).  Or a package for giving out an HTTP URL for simultaneous click-to-web-browsing with call.  Or a package for sending a "failed media path" indication.  Or a package for sending instructions for a SIP-based game.  Can some or all of these be done with Subscribes?  Sure.  And for some I think it probably makes sense to ONLY allow it in subscribes/publish/whatever.  But for some of those, or for something in the future, it may make more sense to only exchange it in the Invite dialog it's related to, without the overhead of a Subscribe dialog.

I do assume from a SIP stack model perspective and its application user that there would need to be some form of clear differentiation of subscription Event Package support/usage, and one for Info-Packages.  So I guess separating these from Subscription-type Event packages makes sense in that context.  But does that mean one can't define a new package that works both ways?

-hadriel

> Sent: Monday, October 29, 2007 12:10 AM
> To: Dean Willis
> Cc: Sanjay Sinha (sanjsinh); sip List

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Oct 2007 11:07:30 -0500

> I do assume from a SIP stack model perspective and its application user that there would need to be some form of clear differentiation of subscription Event Package support/usage, and one for Info-…

One could. [1]

My argument is that one shouldn't. Because when one does, one creates 
two ways to do the same thing. Which means that implementors either 
choose a single mechanism (and fail to work with the other -- this is 
bad) or are forced to implement both mechanisms (doubling implementation 
cost -- this is also bad).

Why are we putting forth mechanisms that force implementors to choose 
between two bad options?

The examples you cite clearly work better in an INVITE context -- so 
define them that way, and leave SUBSCRIBE out of it.

/a

----
[1] One can also pound screws into wood with a hammer -- the measure of 
whether to do something isn't "can we", but "what happens if we do?"

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Oct 2007 11:11:21 -0500

> define them that way, and leave SUBSCRIBE out of it.

Correction: I meant "...leave SUBSCRIBE and NOTIFY out of it."

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 30 Oct 2007 12:16:30 -0400

Yeah I was thinking the same thing - if there are two ways someone will surely do one and not the other and we'll have problems.
I was just thinking someone may come up with one that makes sense for both, in different usage contexts.  But I guess that's really 2 different package types that may just happen to share a defining RFC or have the same registered package name, but are really two separate "things".
Regardless, I think it's safer to say for now the two package types are unrelated.
-hadriel

> Sent: Tuesday, October 30, 2007 12:08 PM
> To: Hadriel Kaplan
> Cc: Dean Willis; sip List
> > I do assume from a SIP stack model perspective and its application user
> that there would need to be some form of clear differentiation of
> subscription Event Package support/usage, and one for Info-Packages.  So I
> guess separating these from Subscription-type Event packages makes sense
> in that context.  But does that mean one can't define a new package that
> works both ways?
> >
>
> One could. [1]
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Oct 2007 13:03:07 -0500

> Regardless, I think it's safer to say for now the two package types are unrelated.

Excellent.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Oct 2007 14:13:20 -0400

OK. Adam has persuaded me that overlap with relevant existing event 
packages is negligible (none, or perhaps KPML - more on that later) and 
that recommending that new ones be created to support two mechanisms is 
a bad idea.

So that leaves the question of whether to nail down a negotiation 
mechanism for "info-packages".

The obvious first case to consider is DTMF. The problem of course is 
that we already have two standard methods for transfering DTMF 
(telephone-events in RTP, and KPML subscriptions.) So standardizing use 
of INFO for this would mean standardizing a *different* way than KPML. 
And most likely it would be different than the non-standard way(s?) of 
using INFO for DTMF in the wild. Is that going to do anybody any good, 
or just give people more heartburn? Perhaps we should either bless what 
is being used or else continue to treat it with benign neglect.

Once you get past that one, I think we might as well wait until somebody 
has something else they want to exchange this way to before getting too 
caught up in inventing machinery.

	Paul

Adam Roach wrote:
>> I do assume from a SIP stack model perspective and its application 
>> user that there would need to be some form of clear differentiation of 
>> subscription Event Package support/usage, and one for Info-Packages.  
>> So I guess separating these from Subscription-type Event packages 
>> makes sense in that context.  But does that mean one can't define a 
>> new package that works both ways?
>>   
> 
> One could. [1]
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 30 Oct 2007 23:01:44 +0100

Hi,

>caught up in inventing machinery.

I think we should invent the machinery, and HOPEFULLY people will then start implement it instead of the non-standard way.

I also know that other SDOs are looking into using INFO for certain things, so I think it would be really good to define a proper mechanism before they also start to use INFO as it's used today (with all the problems people have listed).

Regards,

Christer

        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Oct 2007 18:52:35 -0400

> I think we should invent the machinery, and HOPEFULLY people will then start implement it instead of the non-standard way.

My original thinking was that this was just a lightweight way to 
establish a slightly restricted subscription. I was thinking of it as a 
way to use an existing event specification in a particular sub-case 
where you knew you wanted the target and duration to be the same as your 
invite. That is why I thought the same event package definitions would 
apply.

That is no longer the case. This is a new thing. As such, it needs to 
define its own scope of applicability. There must be a way to say: "THIS 
new behavior should be done as an info-event because ..., and THAT new 
behavior should be done using an event/subscription because ...".

What do we use to decide on that scope? We need some use cases. Other 
than DTMF, do we have any? And for DTMF, do you know how to partition 
those cases that should use this technique from the other two standard 
techniques and N non-standard techniques?

> I also know that other SDOs are looking into using INFO for certain things, so I think it would be really good to define a proper mechanism before they also start to use INFO as it's used today (wi…

Could you be more specific? I'm guessing you are talking about 3GPP?

We keep getting into trouble with 3GPP because we are asked to provide 
mechanisms without use cases and clear requirements for the mechanism.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 30 Oct 2007 19:04:22 -0500

> Or a package 
> for sending vcard info to the caller/called.  Or a package 
> for giving out a jpeg for photo-id, or for call screen 
> display.  

Isn't that what the Call-info header is exactly for (RFC 3261/20.9)?

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 30 Oct 2007 23:25:56 -0400

> From: Francois Audet [mailto:[email-masked]]
>
> > Or a package

It was my understanding the Call-Info header was to give a URI to go fetch stuff from, usually an HTTP URI (if one could use the term "usually" for the Call-Info header ;).  That is highly unlikely I think, since it is highly unlikely a SIP UA has a web-server to provide such, or one globally reachable (like, good luck if it's behind a NAT/FW).  I guess you could put in a SIP URI and tell it to Subscribe for a jpeg photo-id package, and stick some cookie in the uri so the serving UA can correlate the subscribe request to the call (i.e., which call is asking for this info?).  <sarcasm>Yeah that's a lot more reasonable than just using the Invite dialog to send it in an INFO.</sarcasm>

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 31 Oct 2007 00:05:48 -0400

> Sent: Tuesday, October 30, 2007 2:13 PM
> To: Adam Roach
> Cc: Hadriel Kaplan; sip List; Dean Willis

My vote would be to re-use the most common one, which I think is the application/dtmf-relay one.  If for no other reason than to make it as easy as possible, for as many non-standard implementations as possible, to implement the negotiation and follow a standard.

KPML is orthogonal to info-dtmf.  It has its own use cases, if people want to use it.

The sticky part in my mind has always been what to do if both info-dtmf were negotiated and 2833/4733 was offered/answered.  Or even what to do with in-audio tones.  I *think* the answer is info-dtmf should trump 2833 - i.e., if you negotiated info-dtmf only do that, for a variety of reasons; but with delayed SDP offers that would mean you'd always end up using info-dtmf when you could have done 2833 instead.  And I can see the argument for "do both", and that's what kpml did except it has the suppression/<pre> concept, but I assumed that was due to pattern matching being inconsistent with in-band event sending one-at-a-time.  But I still think info-dtmf trumping would be right, because the tones will get to the far end if they should.

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 31 Oct 2007 08:47:55 +0100

Hi Paul, 

>>>packages is negligible (none, or perhaps KPML - more on that later) 
>>>and that recommending that new ones be created to support two
mechanisms is a bad idea.
>>>(telephone-events in RTP, and KPML subscriptions.) So standardizing 
>>>use of INFO for this would mean standardizing a *different* way than
KPML.
>>>And most likely it would be different than the non-standard way(s?) 
>>>of using INFO for DTMF in the wild. Is that going to do anybody any 
>>>good, or just give people more heartburn? Perhaps we should either 
>>>bless what is being used or else continue to treat it with benign
neglect.
>>>
>>>Once you get past that one, I think we might as well wait until 
>>>somebody has something else they want to exchange this way to before 
>>>getting too caught up in inventing machinery.
>> 
>>I think we should invent the machinery, and HOPEFULLY people will then
start implement it instead of the non-standard way.
> 
>My original thinking was that this was just a lightweight way 
>to establish a slightly restricted subscription. I was 
>thinking of it as a way to use an existing event 
>specification in a particular sub-case where you knew you 
>wanted the target and duration to be the same as your invite. 
>That is why I thought the same event package definitions would apply.
> 
>That is no longer the case. This is a new thing. As such, it 
>needs to define its own scope of applicability. There must be 
>a way to say: "THIS new behavior should be done as an 
>info-event because ..., and THAT new behavior should be done 
>using an event/subscription because ...".

It's up to the one defining the event packages to describe those things,
and to say whether an event package is applicable for info-events and/or
subscription-events.

>What do we use to decide on that scope? We need some use 
>cases. Other than DTMF, do we have any? And for DTMF, do you 
>know how to partition those cases that should use this 
>technique from the other two standard techniques and N 
>non-standard techniques?

That's for the implementors - not us - to decide. We provide the tools,
and a clear definition on how they can be used etc.

And, I think DTMF IS a very valid use-case to start working on this
mechanism. The issues has been around for years, and it won't go away.

Another use-case I've seen is related to interworking, where certain
H.245 messages are mapped into INFO.

Another use-case I've seen is related to video control, where INFO is
used to control video-type-of applications.

Another use-case is of course ISUP transport, and other type of
PSTN/ISDN information.

Other use-cases are when application are exchaning some data (e.g. the
here-is-a-jpeg example which comes up all the time :) between
themselves. These kind of use-cases will most likely grow as the number
of applications grow. Applications can of course also exchange data by
setting up a data channel, but there may be cases where the amount and
frequency of data is not that large.

And, we don't know how many such applications there already are out
there. If we provide a standardized tool, people will hopefully bring
those to IETF.

Another use-case (and you're going to love this one :), is SIP overlap
dialling. Some organizations have proposed requirements to optionally
support SIP overlap in IMS. Currently TISPAN is studying two mechanism.
One is based on the RFC, where a new initial INVITE is sent when more
digits are provided. The other mechanism is based on, once an early
dialog has been established with the remote peer, sending the additional
digits in-dialog, and INFO is obviously one of the candidate methods for
providing the additional digits.

>I also know that other SDOs are looking into using INFO for 
>certain things, so I think it would be really good to define 
>a proper mechanism before they also start to use INFO as it's 
>used today (with all the problems people have listed).
> 

At this point I think it's more TISPAN, but much of the work will
probably end up in 3GPP sooner or later. Unfortunately I am not involved
in that work, so I can't give any details.

>We keep getting into trouble with 3GPP because we are asked 
>to provide mechanisms without use cases and clear 
>requirements for the mechanism.

And when 3GPP does provide use-cases we start to argue against them...

Anyway, that is another topic, so let's not get into that discussion
here and now.

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Wed, 31 Oct 2007 09:00:31 -0500

> techniques and N non-standard techniques?

We have the entire family of mid-call "telephony tunneling" events for
which we've previously agreed to use INFO as use cases.

I think the clear factor between scoping events to an INVITE dialog
(INFO) versus a SUBSCRIBE dialog is whether the events being reported
are completely bounded by an INVITE dialog. That is, they're what we
would have previously called "mid-call events".  If they have no
meaningful context before the INVITE or after the BYE, then they may be
reasonably considered to be INFO events.

--
Dean

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 31 Oct 2007 10:19:26 -0400

>From: Hadriel Kaplan [mailto:[email-masked]] 
>Sent: Tuesday, October 30, 2007 11:26 PM
>To: Francois Audet
>Cc: sip List
>Subject: RE: [Sip] INFO: A recap, sense of consensus and a 
>proposal fordirection.
>
>
>
>> > for sending vcard info to the caller/called.  Or a package for 
>> > giving out a jpeg for photo-id, or for call screen display.
>>
>It was my understanding the Call-Info header was to give a URI 
>to go fetch stuff from, usually an HTTP URI (if one could use 
>the term "usually" for the Call-Info header ;).  That is 
>highly unlikely I think, since it is highly unlikely a SIP UA 
>has a web-server to provide such, or one globally reachable 
>(like, good luck if it's behind a NAT/FW).  I guess you could 
>put in a SIP URI and tell it to Subscribe for a jpeg photo-id 
>package, and stick some cookie in the uri so the serving UA 
>can correlate the subscribe request to the call (i.e., which 
>call is asking for this info?).  <sarcasm>Yeah that's a lot 
>more reasonable than just using the Invite dialog to send it 
>in an INFO.</sarcasm>

One can also use out of dialog REFER with the URI in Refer-To header and
add a Target-Dialog header referencing the INVITE dialog this
information to be fetched from URI in Refer-To applies to.  The Refer-To
url can be globally reachable one.

Thanks.
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Wed, 31 Oct 2007 10:26:36 -0400

Pl. see inline ..

>Sent: Wednesday, October 31, 2007 12:06 AM
>To: Paul Kyzivat (pkyzivat); Adam Roach
>> Subject: Re: [Sip] INFO: A recap, sense of consensus and a proposal 
>> for direction.
>>
>> use of INFO for this would mean standardizing a *different* 
>way than KPML.
>> or just give people more heartburn? Perhaps we should either bless 
>> what is being used or else continue to treat it with benign neglect.
>
>My vote would be to re-use the most common one, which I think 
>is the application/dtmf-relay one.  If for no other reason 
>than to make it as easy as possible, for as many non-standard 
>implementations as possible, to implement the negotiation and 
>follow a standard.
>
I think KPML is more suitable for things like dial-plan match etc. and
not for OOB dtmf signaling.

>
>The sticky part in my mind has always been what to do if both 
>info-dtmf were negotiated and 2833/4733 was offered/answered.
A UA can have configured preferences, if more than one mechanism is
offered. So if it is configured for both info-dtmf and 2833/4733, based
on preference it can choose one or the other and provide that in answer
response. I am not sure why would some implementation choose info-dtmf
over 2833/4733 mechanism.
  
>Or even what to do with in-audio tones.
Based on negotiated mechanism, it can ignore the other mechanism. So if
info-dtmf is the negotiated mechanism and for a pstn gw, it can instruct
the DSP to drop in-band dtmf packets.

Thanks.

>I *think* the answer is info-dtmf should trump 2833 - i.e., if you
negotiated 
>info-dtmf only do that, for a variety of reasons; but with 
>delayed SDP offers that would mean you'd always end up using 
>info-dtmf when you could have done 2833 instead.  And I can 
>see the argument for "do both", and that's what kpml did 
>except it has the suppression/<pre> concept, but I assumed 
>that was due to pattern matching being inconsistent with 
>in-band event sending one-at-a-time.  But I still think 
>info-dtmf trumping would be right, because the tones will get 
>to the far end if they should.
>
>-hadriel
>
>
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 31 Oct 2007 09:53:48 -0500

> It was my understanding the Call-Info header was to give a URI to go fetch stuff from, usually an HTTP URI (if one could use the term "usually" for the Call-Info header ;).  That is highly unlikely…

Hey, I've always been a fan of putting data URLs (RFC 2397) in 
Alert-Info and Call-Info header fields. I think it's much cleaner than 
any of the approaches you mention.

Alert-Info: 
<data:text/directory;profile=vCard,BEGIN%3AVCARD%5CnVERSION%3A3%2E0%5CnN%3ARoach%3BAdam%3B%3B%3B%5CnFN%3AAdam%20Roach%5CnORG%3AEstacado%20Systems%3B%5CnTITLE%3ACTO%5CnEMAIL%3Btype%3DINTERNET%3Btype%3DWORK%3Aadam%40estacado%2Enet%5CnEMAIL%3Btype%3DINTERNET%3Btype%3DHOME%3Btype%3Dpref%3Aadam%40nostrum%2Ecom%5CnEND%3AVCARD%5Cn>

Of course, if you don't like long headers, you can get a very similar 
effect with multipart MIME bodies and CID URIs (RFC 2392).

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 31 Oct 2007 11:54:34 -0400

Adam beat me to it re the CID URI. The data URI works too. (I hadn't 
thought of it in that context.)

	Paul

Adam Roach wrote:
>> It was my understanding the Call-Info header was to give a URI to go 
>> fetch stuff from, usually an HTTP URI (if one could use the term 
>> "usually" for the Call-Info header ;).  That is highly unlikely I 
>> think, since it is highly unlikely a SIP UA has a web-server to 
>> provide such, or one globally reachable (like, good luck if it's 
>> behind a NAT/FW).  I guess you could put in a SIP URI and tell it to 
>> Subscribe for a jpeg photo-id package, and stick some cookie in the 
>> uri so the serving UA can correlate the subscribe request to the call 
>> (i.e., which call is asking for this info?).  <sarcasm>Yeah that's a 
>> lot more reasonable than just using the Invite dialog to send it in an 
>> INFO.</sarcasm>
>>   
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 31 Oct 2007 11:06:45 -0500

Well, the photo can be on some web server:

Call-info: <http:someserver.example.com?mypicture.jpeg;purpose=icon>

> Sent: Tuesday, October 30, 2007 20:26
> It was my understanding the Call-Info header was to give a 
> URI to go fetch stuff from, usually an HTTP URI (if one could 
> use the term "usually" for the Call-Info header ;).  That is

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 31 Oct 2007 12:54:22 -0400

> Sent: Wednesday, October 31, 2007 11:55 AM
> To: Adam Roach
> Cc: Hadriel Kaplan; sip List; Francois Audet

Me neither.  I wonder how many implementers had thought of it - i.e., how many phones would it actually work for. :)  Someone should probably write a sipping draft for that someday.
But anyway it was just an example.  And to continue the example the beauty of sending a vcard in an Info is it lets the user trigger the action.  So for example once I call you I can ask you for someone else's contact info and you can send someone else's vcard.  Or at least wait to hear who's calling me before sending them my vcard.

-hadriel