Subject: RE: [Sip] Major Open Issue #113: Overlapping Transactions

From: "Mark Watson" <[email-masked]>
Date: Wed, 19 Dec 2001 13:28:53 -0000

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> <snip>
> 
> Q1. Can we use it to update the Request-URI? 
> 
> IF, I guess the overlap dialing discussion will once again come up; do
> we use INVITE + UPDATE(s), or do we use re-INVITEs (for 
> separate legs)?
> 

Interesting idea - we rejected using INVITE + INFO for overlap because
intervening proxies would not be able to see the additional digits, but with
UPDATE they could (if they had Record-Routed).

> 
> Q2. Can we use it to update the SDP? 
> 
> In a basic SIP situation the answer is probably no, since SIP uses the
> INVITE/200 (or 200/ACK) mechanism. However, extension mechanisms
> (similar to the manyfolks resource reservation) could use it - instead
> of PRACK.
>

The requirement was for the UAC to be able to put early media on hold, and I
see no reason why it shouldn't *try* to do this - whether it suceeds will
just depend on whether the UAS supports it or not. You will find out when
you get the response to the UPDATE.
 
> 
> Q3. Can we use it in mid-session, ie "outside" an ongoing INVITE
> transaction?
> 
> Can the method be used, instead of re-INVITE (and in some cases maybe
> also instead of INFO) to update some parameters. A current example is
> the Allow header; would we really need a re-INVITE to update 
> that, if we
> can use the UPDATE method?

It doesn't seem to make any difference to me which you use, but we should
probably specify one or the other. I would have thought re-INVITE for
backwards compatibility. However, UAS will need to support UPDATE after it
has sent the 200 OK for the case where the UPDATE and 200 OK cross, so from
a UAS perspective you would have to support both UPDATE & re-INVITE in all
states after dialog establishment.

> 
> 
> Q4. Proxy support?
> 
> Depending on the method would be used for, there are cases where proxy
> support for the method would be needed (in another mail Jonathan gave
> midcom as an example). Would we define an option-tag, or would it be a
> MUST for proxies to support the method?
> 
> 
> I am sure there are many more similar questions, and I think we should
> try to answer all of them before we define a new method/extension.
> Otherwise they will come up sooner or later anyway, and the discussion
> will go on forever... 
> 
> Please also note that the text above are NOT proposals - simply
> QUESTIONS that would come up if an UPDATE method proposal was to be
> given.
> 
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > There was consensus at IETF 52 that overlapping non-INVITE should be
> > allowed, and that does not seem to have been controversial 
> in this thread.
> > 
> > The main issue remains overlapping INVITE. This is tightly 
> coupled to
> > whether or not a new INVITE Is used for the solution for 
> both (1) early
> > media and (2) the heterogeneous error response forking 
> problem. In both
> > cases, the UA needs to pass additional information to a 
> specific UAS in
> > order for call processing to continue, in order to generate a final
> > response to INVITE.
> > 
> > So, the big question is: do we use INVITE for this, or 
> something else?
> > Some of the issues to tackle when using INVITE are:
> > 
> > 1. what happens to the first transaction when the second 
> INVITE arrives?
> > Does the uas reject it (this may impact services)? Does it 
> continue to
> > use it, but accept the second one? If so, what is the implication on
> > status of the dialog? What if the first INVITE is later 
> rejected - is
> > the dialog up or down? Race conditions may make it hard to say.
> > 
> > 2. what is the impact on intermediate proxy and other elements (like
> > firewall controllers)?
> > 
> > 
> > -Jonathan R.
> > 
> > Anders Kristensen wrote:
> > 
> > >
> > > Jonathan Rosenberg wrote:
> > >
> > >>Issue:
> > >>
> > >>This is a major issue. One of the more major ones remaining.
> > >>
> > >>Currently, the spec forbids more than one INVITE at a 
> time, and more than
> > >>one non-INVITE at a time. This is simple, but there are 
> valid concerns that
> > >>it will bite us down the road when uses require faster 
> operation. Thus, the
> > >>issue is whether to relax this two constraints.
> > >>
> > >>Discussion points:
> > >>
> > >>The reason we forbid it with INVITE was that you couldn't 
> easily figure out
> > >>the most recent session description. There was no way to 
> tell whether the
> > >>response to the first INV was sent before or after the 
> response to the
> > >>second INVITE. Without a consistent view of which was the 
> most recent SDP,
> > >>the session parameters would be wrong.
> > >>
> > >
> > > I agree that it would be desirable to allow overlapping 
> transactions,
> > > including INVITEs. What's the problem with saying that 
> the CSeq (and
> > > subordinately RSeq) defines which is the most recent SDP?
> > >
> > > Anders
> > >
> > 
> > --
> > Jonathan Rosenberg, PhD                 72 Eagle Rock Avenue
> > Chief Scientist                         First Floor
> > dynamicsoft                             East Hanover, NJ 07936
> > [email-masked]                 FAX: (973) 952-5050
> > http://www.jdrosen.net                  PH: (973) 952-5000
> > http://www.dynamicsoft.com
> > 
> > _______________________________________________
> > Sip mailing list  http://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
> 
> _______________________________________________
> Sip mailing list  http://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: Christer Holmberg <[email-masked]>
Date: Wed, 19 Dec 2001 15:58:35 +0200

Hi,

>>IF, I guess the overlap dialing discussion will once again come up;
>>do we use INVITE + UPDATE(s), or do we use re-INVITEs (for
>>separate legs)?
>> 
>intervening proxies would not be able to see the additional digits,
>but with UPDATE they could (if they had Record-Routed).

Another reason was that INFO must not be used to affect the SIP call
state. 

>>In a basic SIP situation the answer is probably no, since SIP uses
>>the INVITE/200 (or 200/ACK) mechanism. However, extension mechanisms
>>(similar to the manyfolks resource reservation) could use it -
>>instead of PRACK.
> 
>The requirement was for the UAC to be able to put early media on hold,
>and I see no reason why it shouldn't *try* to do this - whether it
>suceeds will just depend on whether the UAS supports it or not. You
>will find out when you get the response to the UPDATE.

I guess this depends on how the early media handling will be
implemented. But, assuming you use SDP parameters to accept early media,
and/or put early media on hold/unhold, the question is: WHICH SDP
parameters are we allowed to update? For example, are we only llowed to
update some specific attributes, or are we also allowed to update
codec/IP parameters, or are we even allowed to add/remove streams?

Thanks for your comments!

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 19 Dec 2001 21:22:52 +0200

Hi,

Mark Watson wrote:
> do

No. We rejected to use INVITE + INFO because once the early dialog was
established, subsequent INFOs could not be routed in a different way
than the INVITE.

Regards,

Gonzalo