Subject: Re: [sipcore] New revision of the re-INVITE handling draft

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 5 Aug 2009 21:12:06 +0200

Hi,

What about this ICE specific way of sending provisional responses
"reliably" without using PRACK? If I use ICE as part of a re-INVITE, can
those responses refresh the remote target?

I hope the answer is "no", but whatever it is I guess it would be good
to mention it.

Regards,

Christer 

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Thursday, July 30, 2009 3:41 PM
To: OKUMURA Shinji
Cc: Paul Kyzivat; [email-masked]; Christer Holmberg; SIPCORE
Subject: Re: [sipcore] New revision of the re-INVITE handling draft

Hi,

please, read Section 8 of the draft. It points to the relevant
paragraphs of RFC 3261.

Cheers,

Gonzalo

OKUMURA Shinji wrote:
> Hi,
> 
> I want to confirm one basic points,
> 
> Gonzalo Camarillo <[email-masked]>
>> Hi,
>>
>> it seems we can cover most cases with the following rules:
>>
>> 1) a reliable provisional response or a 2xx response to a target 
>> refresh confirms that the UAS has refreshed the target. This refresh 
>> is not rolled back under any circumstance (i.e., even if the target 
>> refresh was a re-INVITE that eventually failed or the target refresh 
>> was an UPDATE within a re-INVITE that eventually failed).
> 
> I don't dislike this rule. But AFAIK RFC3261 and 3262 don't allow 
> (even if reliable) provisional responses to refresh targets.
> Therefore I think this is a normative change.
> 
> Regards,
> 
> Shinji

---

From: [email-masked]
Date: Thu, 20 Aug 2009 09:42:57 +0800

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   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

--------------------------------------------------------
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.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Aug 2009 09:01:01 -0400

[email-masked] wrote:
> 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.

You mean that you prefer suspension being for the whole session (*all* 
streams)???

> existence of other streams( with precondition).

It seems you are arguing in favor of suspension being per-stream.

IMO the suspension behavior is defined on a per-stream basis and so 
needs to be implemented that way.

Another reason for this is that it is possible the various streams are 
not controlled by the same entity, so that coordination of when they 
take effect could be problematic.

If someone wants the changes to multiple streams to take effect together 
they are free to put preconditions on them all and synchronize the 
resolution of those preconditions.

	Thanks,
	Paul

---

From: [email-masked]
Date: Fri, 21 Aug 2009 00:41:53 +0800

Hi Paul,

As you can see that i am arguing in favor of suspension being per-stream 
:).
It is a clerical error. I prefer "suspending is effective for streams with 
precondition", the 2st one.

But RFC 3312 & 4032 has such description:
While session establishment is suspended(for QoS type precondition), user 
agents SHOULD not send any data over any media stream.  In the case of 
RTP, neither RTP nor RTCP packets are sent.

So, do we need correction for this?

Thanks.

Gao

Paul Kyzivat <[email-masked]> 
2009-08-20 21:01

收件人
[email-masked]
抄送
SIPCORE <[email-masked]>, Gonzalo Camarillo 
<[email-masked]>, Christer Holmberg 
<[email-masked]>, [email-masked]
主题
Re: Suspending and Resuming modification of session or stream?   //New 
revision of the re-INVITE handling draft

                 Thanks,
                 Paul

> 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Aug 2009 14:59:32 -0400

[email-masked] wrote:
> It is a clerical error. I prefer "suspending is effective for streams 
> with precondition", the 2st one.
> 
> While session establishment is suspended(for QoS type precondition), 
> user agents SHOULD not send any data over *any media stream*.  In the 
> case of RTP, neither RTP nor RTCP packets are sent.
> 

I haven't thought about it a lot, but my immediate reaction is *yes*,
this doesn't seem right. I would like to hear what Gonzalo thinks.

In the writing of 4032, I think the focus here was on narrowing the
scope of this limitation, so that it applied only to QoS and not other
precondition types. I don't think ay consideration was given to

	Thanks,
	Paul

> *Paul Kyzivat <[email-masked]>*
> 
> 2009-08-20 21:01
> 
> 	
> 收件人
> 	[email-masked]
> 抄送
>  > 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.

---

From: [email-masked]
Date: Fri, 21 Aug 2009 08:07:45 +0800

> this doesn't seem right. I would like to hear what Gonzalo thinks.

I'd like to hear Gonzalo's points too. But I remember that he said that he 
will get back to office on September 1st.
Perhaps he can only show his idea then.

> precondition types. 

Yes, it is needful to narrow the scope of this limitation for other 
precondition type beyond QoS type.

> I don't think ay consideration was given to

I can't catch this sentence. What's the meaning of "ay consideration"?

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Aug 2009 20:34:37 -0400

[email-masked] wrote:
> I'd like to hear Gonzalo's points too. But I remember that he said that 
> he will get back to office on September 1st.

Sorry, I guess I sent before I was done.

I meant to say that I don't think any consideration was given the point
you are now raising. It just never came up.

	Thanks,
	Paul

---

From: [email-masked]
Date: Fri, 21 Aug 2009 08:48:09 +0800

OK. Thanks for your explanation.

And adding your arguing points, we have three ones for "in favor of 
suspension being per-stream":

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).
3. Various streams are not controlled by the same entity, so that 
coordination of when they take effect could be problematic

And we can talk it further together when Gonzalo get back.

2009-08-21 08:34

收件人
[email-masked]
抄送
Christer Holmberg <[email-masked]>, Gonzalo Camarillo 
<[email-masked]>, SIPCORE <[email-masked]>, 
[email-masked]
主题
Re: 答复: Re: 答复: Re: Suspending and Resuming modification of session or 
stream?   //New revision of the re-INVITE handling draft

                 Thanks,
                 Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 21 Aug 2009 12:46:28 +0200

Hi,

I think you are asking for problems if you start combining preconditions and non-preconditions in a re-INVITE. 

It is already difficult enough to be sure on when the new media parameters will be taken in use, and when the old ones cannot be used anymore, so if different parameters are to be taken into use at different times I think it will create a mess...

So, why not do the audio change and the video change in separate transactions?

But, I need to do some more thinking before answering your question. In principle I guess it would be good to keep each media stream as separate as possible, but the way SIP, SDP and the media descriptions are boundled together there may be some limitations.

We also need to keep in mind that the precondition modification can fail, and what happens to the non-precondition change in that case.

Regards,

Christer

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 20. elokuuta 2009 22:00
> To: [email-masked]
> Cc: Christer Holmberg; Gonzalo Camarillo; SIPCORE; 
> [email-masked]
> Subject: Re: 答复: Re: Suspending and Resuming modification of 
> session or stream? //New revision of the re-INVITE handling draft
> 
> 
> 
> > As you can see that i am arguing in favor of suspension being 
> > per-stream :).
> I haven't thought about it a lot, but my immediate reaction 
> is *yes*, this doesn't seem right. I would like to hear what 
> Gonzalo thinks.
> 
> In the writing of 4032, I think the focus here was on 
> narrowing the scope of this limitation, so that it applied 
> only to QoS and not other precondition types. I don't think 
> ay consideration was given to
> 
> 	Thanks,
> 	Paul
> 
> > Thanks.
> > 
> > Gao
> > 
> >  > 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).
> >  >
> >  > For the use case, A and B should not use new codec or 
> address for 
> > audio  > before vedio's preconditon is met.
> >  >
> >  > For the use case, A and B can use new codec or address for audio 
> > before  > vedio's preconditon is met.
> >  >
> >  >
> >  > 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).
> > 
> > If someone wants the changes to multiple streams to take effect 
> > together they are free to put preconditions on them all and 
> > synchronize the resolution of those preconditions.
> > 
> >                 Thanks,
> >                 Paul
> > 
> > maintain secrecy and are not permitted to disclose the contents of 
> > this communication to others.
> > 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.
> >  >
> > 
> > 
> > 
> > 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.

---

From: [email-masked]
Date: Fri, 21 Aug 2009 19:43:24 +0800

"Christer Holmberg" <[email-masked]> 写于 2009-08-21 
18:46:28:

> 
> Hi,
> 
> I think you are asking for problems if you start combining 
> preconditions and non-preconditions in a re-INVITE. 
> 
> It is already difficult enough to be sure on when the new media 
> parameters will be taken in use, and when the old ones cannot be 
> used anymore, so if different parameters are to be taken into use at
> different times I think it will create a mess...
> 

When to switch from old to new parameters should obey RFC3264. And 
suspending semantic for session or stream is RFC3312 & 4032.
The two problems have relationship, but they have separate sources of 
defintion.

And if we choose the way of *suspending semantic for whole session*, then 
as Paul said that coordination of when they take effect could be 
problematic. It can create a bigger mess. :)

> So, why not do the audio change and the video change in separate 
transactions?

I agree with you. But I can not stop people from doing so.
And we really have equipment as *various streams are not controlled by the 
same entity*( In fact, ZTE has a equipment in this way). And it is really 
hard to wrap various streams has the same ability, such as precondition.

> But, I need to do some more thinking before answering your question.
> In principle I guess it would be good to keep each media stream as 
> separate as possible, but the way SIP, SDP and the media 
> descriptions are boundled together there may be some limitations.
> 

Yes. I also think it is better to *keep each media stream as separate as 
possible*. So, I prefer the way of *suspending semantic for streams with 
precondition*.
And I think it is better to make a detailed reasoning for the two 
approachs.

> We also need to keep in mind that the precondition modification can 
> fail, and what happens to the non-precondition change in that case.
> 

Yes, the precondition can fail.
By the way in the draft:
And as it(the precondition stream) is not used, and the non-precondition 
is used(in case of having done the first O/A), UA can send a UPDATE with 
non-precondition stream(by RFC3264, the preconditon stream should be set 
as port=0) to show the rollback state of session.

> > confidential and

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Aug 2009 09:08:04 -0400

> I think you are asking for problems if you start combining preconditions and non-preconditions in a re-INVITE. 

Well, do you have a choice?
Suppose you have a regular audio session without preconditions.
Then you want to add video, but know you must have preconditions in
order to have a successful video session.
Do you put new preconditions on the audio stream just to be consistent?

> It is already difficult enough to be sure on when the new media parameters will be taken in use, and when the old ones cannot be used anymore, so if different parameters are to be taken into use at…

Like most things, its confusing until somebody thinks through the
details. Perhaps a use cases draft would be helpful here. Gao?

> So, why not do the audio change and the video change in separate transactions?

That is a possibility, unless you *need* a matching audio change to go
with the video. (Perhaps something has to be changed to assure lip sync.)

> But, I need to do some more thinking before answering your question. In principle I guess it would be good to keep each media stream as separate as possible, but the way SIP, SDP and the media desc…

I think that principle is important.

> We also need to keep in mind that the precondition modification can fail, and what happens to the non-precondition change in that case.

Gonzalo's draft addresses that part.

	Thanks,
	Paul

---

From: [email-masked]
Date: Fri, 21 Aug 2009 23:39:12 +0800

> details. Perhaps a use cases draft would be helpful here. Gao?

OK. I will do it next week.

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 21 Aug 2009 23:16:23 +0200

Hi,
 
>Do you put new preconditions on the audio stream just to be consistent?

Well, you could do that. That way you would ensure that the changes are "activated" at the same time, which may be useful for the lip synch case you describe further down.

>That is a possibility, unless you *need* a matching audio change to go with the video. (Perhaps something has to be changed to assure lip sync.)

That would assume that the non-precondition audio media change isn't "activated" until the precondition media does, right?

But, in that case you could use preconditions also for the audio media, as mentioned earlier.
 
AND, things get even more fun when you start adding CapNeg stuff, and you may need additional offer/answers just for that :)

>Gonzalo's draft addresses that part.

Yes, I know. I was just thinking whether it would somehow have an impact on which of Gao's alternatives would make more sense.

Regards,

Christer

>> Subject: Re: ??: Re: Suspending and Resuming modification of
>>> ???
>>> ??
>>> ??