Re: [sipcore] Suspending and Resuming modification of session or stream? //New revision of the re-INVITE handling draft

[Gonzalo Camarillo <[e-mail]>]

Hi,

[I am resurrecting this old thread because it did not reach a conclusion.]

Originally, preconditions were designed with initial INVITE requests in 
mind. The idea was to keep the UAS from alerting the callee until the 
media streams with preconditions were ready to be established (e.g., 
their QoS was in place). That is, if there were some streams that did 
not have preconditions, they would not be established until the 
preconditions for the other streams were met. For example, let us assume 
an initial INVITE with an audio stream without preconditions and a video 
stream with QoS preconditions. Until the QoS for the video stream is in 
place, the audio stream will not be established and the callee will not 
be alerted. In short, when one or more streams within a session have 
preconditions, the whole session establishment is suspended until those 
preconditions are met.

When we extended the concept of preconditions to re-INVITEs, we wanted 
to have similar behavior for initial INVITEs and for re-INVITEs. That is 
why RFC 4032 talks about about *session* establishment being suspended:

http://tools.ietf.org/html/rfc4032#section-3.4

Therefore, the idea was that no changes were applied to any stream until 
all the preconditions were met.

So, the above was our original thinking. However, at present we have a 
better understanding about the problems with long-lived re-INVITE 
transactions. If we allow the whole session establishment to be 
suspended, it would be impossible to change the session parameters of 
any stream while the UAs were working on meeting the preconditions of 
other streams. On the other hand, we want to be able to make the changes 
to one stream conditional to the changes on other stream being executed 
(e.g., use this new audio codec if you accept adding a video stream to 
the session; otherwise, keep on using the old audio codec).

Before we explore this more deeply, I would like to understand if there 
is interest in resolving this type of issue. Some time ago I put 
together a draft dealing with a similar issue (media state during 
preconditions) but we concluded that, at that point, there was not 
enough interest for me (or anyone else for that matter) to put more 
energy into it:

http://tools.ietf.org/html/draft-camarillo-sipping-precons-00

If people want these issues to be clarified, we should by all means do 
so. However, if people do not really care about these corner cases, we 
should prioritize other specs.

Thanks,

Gonzalo



[e-mail] wrote:
> 
> Considering a use case, A and B has a audio only session. Then A send a 
> Re-INVITE for adding vedio stream( with precondition) and changing codec 
> or address for audio stream( without preconditon).
> 
> If suspending is effective for whole session, then streams without 
> precondition should use old parameters while in suspending state.
> For the use case, A and B should not use new codec or address for audio 
> before vedio's preconditon is met.
> 
> If suspending is effective for streams with precondition, the then 
> streams without preconditio can use new parameters after first O/A 
> during the Re-INVITE.
> For the use case, A and B can use new codec or address for audio before 
> vedio's preconditon is met.
> 
> 
> I prefer the first one, as;
> 1. To delay using of new parameters for stream without precondition may 
> arose media clip problem.
> 2. Behavior of streams without precondition should be independent of 
> existence of other streams( with precondition).
> 
> ===================================
> Zip    : 210012
> Tel    : 87211
> Tel2   :([phone]
> e_mail : [e-mail]
> ===================================
> 
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>