Re: INFO Framework - one pakage per INFO

Eric Burger wrote:
> PROBLEM 1: If you want to receive package Foo, and Foo has asymmetric 
> information going the other way, then you want to send Foo-Response. 
> Like you say, Foo is not the same as Foo-Response.  Look at KPML as an 
> example of how to do this right.

OK, it can be done using two packages. It seems a bit clumsy to me but 
it'll work.

> 
> PROBLEM 2: You've got it in one! The correlation MUST be at the 
> application layer.  If you have a package that has asymmetric 
> information flows, then you have two choices.  The first is that you are 
> using a dialog-related application-to-application messaging protocol 
> (INFO) because you want to send messages related to *this* dialog. Any 
> response belongs to the request. Fairly straight forward.  Otherwise, if 

I think we're talking past each other. The problem is not correlating to 
the dialog, it's correlating the app-level response to a particular 
app-level request within a given dialog.

> you have a package that is really using INFO for tunneling, then it is 
> most likely already doing some sort of multiplexing, which means you 
> already need some way of identifying what the messages are for and about.
> 
> PROBLEM 3: Another winner! If you care at all about performance, you 
> would NEVER use INFO!!!!  Come on guys - let's look at DTMF: one to 
> sixteen bytes of payload, two thousand bytes of SIP overhead.

Re: INFO Framework - one pakage per INFO

Hadriel Kaplan wrote:
> But we can't _require_ a fully-layered model.  In other words, all packages have to gracefully handle
failure responses to their INFO request which were caused by processing failure.  And if a package really
cares about processing failure, then it could also define a way to indicate it in a subsequent separate
INFO transaction.
> 
> INFO-DTMF is a good example of one that *won't care*.  There's no real point in indicating errors back.  That
doesn't mean you can't send back a 4xx immediately in response to the INFO request - you can always do that -
it just means we do NOT have to define a way to indicate error after that in an upstream INFO request.

Either it's legal or it isn't. It's no good saying it's not legal but do 
what you gotta do. Are you saying the info-events draft should allow UAs 
to return INFO level errors in response to app-level problems?

> 
> And BTW, any package could define different content-type or body content or whatever for both the normal
use and the error indication, so it won't need separate package names for each.  But anyway that's really up
to the specific package to handle, not the main draft methinks.

So a UA would look at both Send-Info, Recv-Info and Accept in order to 
find out what are the info pkg capabilities of the peer? I guess that 
could work.

Anders

> 
> -hadriel
> 
>> -----Original Message-----

Re: INFO Framework - one pakage per INFO

The gist is...

If one is building request-response type applications, first and  
foremost, why use INFO?  Using INFO says one needs the proxies in the  
path of the messaging.  Sounds like one really needs a rendezvous  
protocol, like SIP, and establish one's own path, e.g., like MSRP.

If one insists on using INFO, one clearly does not care about message  
size, bandwidth utilization, or network element burden. Since 80% of  
the uses of INFO will be for the simple stuff, and the other 20% will  
most likely be over yellow cables (e.g., a media server connected to  
an application server in the same rack), the "extra message" is a tiny  
price to pay to not screw oneself in the future.

On Nov 30, 2008, at 7:30 PM, Anders Kristensen wrote:
> Eric Burger wrote:
>>
[snip]
>> you have a package that is really using INFO for tunneling, then it  
>> is most likely already doing some sort of multiplexing, which means  
>> you already need some way of identifying what the messages are for  
>> and about.
>> PROBLEM 3: Another winner! If you care at all about performance,  
>> you would NEVER use INFO!!!!  Come on guys - let's look at DTMF:  
>> one to sixteen bytes of payload, two thousand bytes of SIP overhead.
>
> I don't think I buy that. If something can be accomplished with one  
> INFO request people are going to wonder why they have to have two.
>
>> Of course, the problems listed below are sort of hyper- 

Re: Multiple body-parts in one INFO

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg <at> ericsson.com]
> Sent: Sunday, November 30, 2008 4:58 PM
>
> Sounds ok.
> But, doesn't the Info-Package header syntax still have to allow the
> piggy-backer to:
> 1) List multiple info packages
> 2) For each listed info package, provide the cid

Nope.  We've already said we're going to not bother doing multiple packages. (or at least I think people have
agreed with that, I hope)
So the next question was on multiple body-parts.  Since INVITE, UPDATE, PRACK, SUBSCRIBE/NOTIFY,
MESSAGE, and legacy INFO, can all carry bodies and not one of them defined a CID mechanism for the body part
that was specific to their message method context, we shouldn't need to for INFO either.

A "piggy-backer" is an extension to SIP that piggy-backs bodies onto any message method types. 
Geolocation is an example of one.  Since it's the responsibility of the piggy-backer to handle
identifying its specific body-part and dis-ambiguating it from the method's, we don't have to do
anything.  In other words, Geolocation would already have to deal with current INFO message and body syntax.

For example, let's suppose someone creates an INFO package for sending virtual location information in a
game, using a content-type of application/pidf+xml.  (whether they should have done it in SIP vs. the
media layer is orthogonal)  And let's suppose for whatever reason the SIP stack always adds Geolocation
information of the UA's physical location.
Here is what it would look like:

----BEGIN----
INFO sip:bob <at> example.com SIP/2.0

Re: INFO Framework - one pakage per INFO

> -----Original Message-----
> From: Anders Kristensen [mailto:andersk <at> cisco.com]
> Sent: Sunday, November 30, 2008 7:30 PM
>
> Hadriel Kaplan wrote:
> > But we can't _require_ a fully-layered model.  In other words, all
> packages have to gracefully handle failure responses to their INFO request
> which were caused by processing failure.  And if a package really cares
> about processing failure, then it could also define a way to indicate it
> in a subsequent separate INFO transaction.
>
> Either it's legal or it isn't. It's no good saying it's not legal but do
> what you gotta do. Are you saying the info-events draft should allow UAs
> to return INFO level errors in response to app-level problems?

The info-events draft has no choice but to allow an INFO request to fail with a failure response code.  ISTM
every SIP request type that can succeed can also fail with a failure response code.  I don't think we need a
*new* response code.  One could use 415 or 400, or Paul suggested 488.  I would do whatever
Subscribe/Notify/Message does in such cases.

And to be clear, I don't think ANY of this needs to be in the base draft.  If someone wants to define a package
that has a body which can contain error information, and sends that in an INFO request after getting an INFO
request it can't process, why should we say a package can't do that?  And I don't mean that in the sense of
"let's be flexible" - I mean it's actually illogical to constrain what a package puts in its INFO message or
why, at layer above SIP.  I don't even know how to word such language.  "You MUST NOT define a package which
contains error information about your application"?

And I don't think we can reasonably mandate that the original INFO request only be responded to with 200 ok if
the entire application processed it successfully.

Re: INFO Framework - one pakage per INFO

> -----Original Message-----
> From: sip-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org] On Behalf Of Eric
> Burger
> Sent: Sunday, November 30, 2008 7:52 PM
>
> If one insists on using INFO, one clearly does not care about message
> size, bandwidth utilization, or network element burden. Since 80% of
> the uses of INFO will be for the simple stuff, and the other 20% will
> most likely be over yellow cables (e.g., a media server connected to
> an application server in the same rack), the "extra message" is a tiny
> price to pay to not screw oneself in the future.

Ummm... the UA may not care, but Proxies sure would.  And it's kinda the UA's decision of whether to use INFO or
not, not the Proxies'.  If we can keep the message count down while still providing the INFO users with what
they need, it would be better IMO.

-hadriel
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

I-D Action:draft-ietf-sip-199-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title           : Response Code for Indication of Terminated Dialog
	Author(s)       : C. Holmberg
	Filename        : draft-ietf-sip-199-03.txt
	Pages           : 15
	Date            : 2008-12-01

This specification defines a new SIP response code, 199 Early Dialog
Terminated, which a SIP forking proxy and a UAS can use to indicate
upstream towards the UAC that an early dialog has been terminated,
before a final response is sent towards the UAC.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-199-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce

Sip-199: New draft version (-03)

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

Re: FW: I-D Action:draft-kaplan-sip-session-id-00.txt

Hadriel,

I am not expecting all problems to be solved, just to not introduce new
ones.

I believe that allowing a proxy to include a session-id header will
introduce more problems than it solves.

I know that we have to work with B2BUAs, and I understand the sentiment
behind getting rid of them all together. The ietf work tends to preclude
handling by B2BUAs but based upon the RFC3261 definition of a B2BUA as a
concatenation of the UAC and UAS then all the ietf specifications have
to ensure is that each Request can be routed to the correct B2BUA and
then it is up to the B2BUA to ensure that it performs the correct
actions for the end-to-end service.

Based upon RFC3261 a B2BUA MUST map the call-id as a Call-id MUST be
globally unique. As a B2BUA is a UAS/UAC the dialogs on either side of
the B2BUA are different dialogs and must have different Call-ids.

The major issue which currently occurs is that a PUI is used to try and
route a request which should be directed to specific UA, e.g. when
referencing an extant dialog. To reach the specific UA the Contact
should be used and if a B2BUA maps the Contact as well as the Call-id
then the new Request should route to the B2BUA which can perform its
'magic' to provide the end-to-end service.

The problem at present is that B2BUA behavior is not defined and many
implemented B2BUAs will not perform the correct actions to provide the
end-to-end service.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: +44 7801723668
ian.elz <at> ericsson.com

-----Original Message-----
From: Hadriel Kaplan [mailto:HKaplan <at> acmepacket.com] 
Sent: 28 November 2008 18:22
To: Ian Elz; Dan Wing; James M. Polk
Cc: SIP List
Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt

I appreciate wanting to solve all possible scenarios (who doesn't! :),
but I am fairly confident there is no possible solution to solve all
possible scenarios.  I am also fairly certain we can't even anticipate
or document all possible scenarios.

ISTM the only way to solve all possible scenarios is to have all B2BUA's
stop changing call-id's and tags - in fact, to not have B2BUA's at all.
Because that is the assumption all RFC uses of callid+tags have made so
far.

At this most recent IETF there appeared to be consensus that the real
world has B2BUA's... LOTS of B2BUA's, of various
flavors/roles/behaviors, from many vendors.  And there appeared to be
consensus that we should try to make things work with them, as much as
pragmatically possible.

> -----Original Message-----
> Having something incomplete may be worse than nothing. We may have a
> scenario where the partial solution gets implemented and then it will
be
> impossible to implement a final solution as you are required to be
> backward compatible to the partial solution.

I can't argue that some future mechanism can't be better than the
session-id mechanism, obviously.  But I would point out the session-id
mechanism would not prevent future mechanisms, any more than current
call-id+tag usage prevents the session-id mechanism.  It would be a "if
session-id match fails, then try this new thing if you understand it",
or it could even be a "try this new thing first, and only if that fails
or you don't understand it then try this session-id thing".  Every
extension to SIP can have those properties as far as I know.  It just
may need a parameter or new header to accomplish it.

But I also don't want to spend 4 years trying to come up with and
standardize a perfect solution, and have the problem last for those 4
years plus whatever time it takes to actually deploy the new solution.
I'd rather have running code in weeks or months, and deployment as soon
as possible - even if it means only some of the scenarios are covered
but not all scenarios.  (and that's not a comment against your comments
- I'm just noting that's how long things take when they're anything more
than really simple)

-hadriel
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip

Re: INFO Framework - one pakage per INFO

See below.

Keith 

> -----Original Message-----
> From: sip-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org] On 
> Behalf Of Hadriel Kaplan
> Sent: Saturday, November 29, 2008 4:50 AM
> To: Anders Kristensen
> Cc: SIP List
> Subject: Re: [Sip] INFO Framework - one pakage per INFO
> 
> 
> > -----Original Message-----
> > From: Anders Kristensen [mailto:andersk <at> cisco.com]
> > Sent: Friday, November 28, 2008 9:44 PM
> >
> > In any event (no pun intended) I don't think the draft adequately 
> > deals with the implications of this model. If errors occurring at 
> > higher layers aren't reported as failure of the INFO 
> request itself, 
> > it pretty much follows that the 200 response to the INFO 
> must include 
> > a payload that carries info (sorry, pun not intended here 
> either) on the error.
> 
> No I think the logic that Eric's arguing for is "you asked 
> for delivery of this package, and I'm responding with 200 ok 
> because it was delivered".  In other words treat INFO as a 
> delivery vehicle, like MESSAGE, and as long as the package 
> was delivered you send a 200 ok, with no correlation to 
> if/when the package was opened and read successfully or not 
> by a higher-layer info-package "consumer".
> 
Correct. And why do something different when MESSAGE already does it
that way.

> 
> > The alternatives would be:
> > 1) Don't report app-level errors. Perhaps OK for simple packages.
> > 2) Report outcome in separate INFO requests going in the opposite 
> > direction. Seems wasteful and requires additional app-level 
> correlation.
> 
> Yeah, I think Eric's argument is for (2).  If they need it, 
> they pay for it.

Correct

A 3xx to 6xx indicates failure to deliver the info package to the
application above.

The simplest error recovery case which seems to apply in existing usage
is no information is sent in the reverse direction regarding application
error handling, or it is handled as part of the application protocol,
i.e. there is a message embedded in the package which in any case
generates a response within the application.
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sipping <at> ietf.org for new developments on the application of sip