Subject: Re: [Sipping] Closing the offer/answer rollback issue -- New drawbacks

From: Paul Kyzivat <[email-masked]>
Date: Sun, 01 Mar 2009 15:42:36 -0500

I just tried to catch up on the discussion here. I mostly see circular
argument/counterargument with no changing of position.

The only thing I have seen here that seems new is Gonzalo's proposal
about "media in use".

I see a lot of issues raised about UAs using media they are not being
charged for. As Tom Taylor said, this is not a new argument, or unique
to this situation. There is always the possibility that two UAs will
attempt to communicate using media they did not signal in an obvious way
in the signaling channel. If they succeed in doing so, it is presumably
because they are using a media path that they have access to independent
of the signaling. In that case the intermediary who feels it should be
charging for this is simply hoping to charge for a service it is not
providing, and so has no real grievance.

The case where this might be a real problem is if a middlebox controls
the media path (what resources are assigned, and whether media is /
isn't permitted to flow), and yet the rules about session state are such
that the middlebox and the endpoints have differing understandings of
whether the active session includes a given media path or not. IMO that
is the key issue that needs to be nailed down.

	Thanks,
	Paul

gaoyang wrote:
>  
> New drawbacks:
>  
> 1. In the original mail, "in use" is after O/A and can be used.
> In RFC3261,
> If the session description has changed, the UAS
>    MUST adjust the session parameters accordingly, possibly *after asking
>    the user for confirmation*.
> "*asking the user for confirmation*" can be user's preference(as Local 
> Policy).
>  
> Then, the "in use" can be depend on "Local Policy".
>  
> 2. As your original example:
> some with precondition not OK, some without precondition or precondition 
> has been OK.
> The modification part of the later(without precondition or precondition 
> has been OK) can need for "*asking the user for confirmation*".
>  
> But the Re-INVITE failed for precondition not satisfied, and the user 
> will not be alerted or hinted. But the modification would go on beyond 
> user's idea.
>  
> Another "Let alone" drawback, it is more serious than "rejected but 
> still let alone".
> For "rejected but still let alone", user at least know what happened.
>  
> 3. Partially comit and partially rollback of O/A which is considered atomic.
> The impact is unknown now.
>  
>  
> 
>  
>  > Date: Fri, 27 Feb 2009 12:38:14 +0200
>  > From: [email-masked]
>  > To: [email-masked]
>  > CC: [email-masked]; [email-masked]; 
> [email-masked]
>  > Subject: Re: [Sipping] 答复: Re: 答复: Re: 答复: Re: ??: Re: ??: Re: 
> ??: Re: ??: Re: ??: Re: ??: Re: ??: Re: Closing the offer/answer 
> rollback issue
>  >
>  > Hi,
>  >
>  > at this point, the discussions are going in circles and are not
>  > productive any longer. No new ideas are being introduced.
>  >
>  > I think I now understand your main points (media synchronization and
>  > session continuity) so that I can put together a more formal description
>  > of the straw-man proposal in my original email that meets all the
>  > requirements brought up here.
>  >
>  > The proposal will be what the WG had agreed on before with slight
>  > modifications (e.g., a clarification of the "in use" concept) in order
>  > to better address your concerns.
>  >
>  > Thanks for your input,
>  >
>  > Gonzalo
>  >
>  > [email-masked] wrote:
>  > >
>  > > Yes. I think it is can, not MUST.
>  > >
>  > > And with precondition, the user can be hinted the new modification 
> just
>  > > after Offer/Answer pairs.
>  > >
>  > >
>  > >
>  > >
>  > > *Gonzalo Camarillo <[email-masked]>*
>  > >
>  > > 2009-02-27 18:22
>  > >
>  > >
>  > > 收件人
>  > > [email-masked]
>  > > 抄送
>  > > [email-masked], [email-masked], 
> [email-masked],
>  > > [email-masked], [email-masked]
>  > > 主题
>  > > Re: 答复: Re: 答复: Re: ??: Re: [Sipping] ??: Re: ??: Re: ??: Re: ??:
>  > > Re: ??: Re: ??: Re: Closing the offer/answer rollback issue
>  > >
>  > >
>  > >
> & gt; >
>  > >
>  > >
>  > >
>  > >
>  > > Hi,
>  > >
>  > > UEB would have rejected the video stream in the 183 response.
>  > >
>  > > Gonzalo
>  > >
>  > > [email-masked] wrote:
>  > > >
>  > > > HI,
>  > > >
>  > > > I think the video will be established.The figure below shows the 
> case.
>  > > >
>  > > >
>  > > > 1. REINVITE(audio，vedio)
>  > > > ----------------------------->
>  > > > 2. 183
>  > > > <-----------------------------
>  > > > 3. PRACK/200
>  > > > <------------------------------>
>  > > > 4. UPDATE(audio，vedio)
>  > > > ----------------------------->
>  > > > 5. 200(audio，vedio)
>  > > > <-----------------------------
>  > > >
>  > > > 6. 4XX
>  > > > <-----------------------------
>  > > >
>  > > > After step 5, UEs' precondition are met ,and the video stream is
>  > > > established too.
>  > > > But UE-B send 4xx to reject 4XX (step 6).
>  > > >
>  > > > Regards.
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > *Gonzalo Camarillo <[email-masked]>*
>  > > >
>  > > > 2009-02-27 17:30
>  > > >
>  > > >
>  > > > 收件人
>  > > > [email-masked]
>  > > > 抄送
>  > > > [email-masked],
>  > > [email-masked], [email-masked],
>  > > > [email-masked]
>  > > > 主题
>  > > > Re: 答复: Re: ??: Re: [Sipping] ??: Re: ??: Re: ??:
>  > > Re: ??: Re: ??:
>  > > > Re: ??: Re: Closing the offer/answer rollback issue
>  > > >
>  > > >
>  > > >
>  > > >
>  > > ; >
>  > > >
>  > > >
>  > > >
>  > > > Hi,
>  > > >
>  > > > > If UE-A wants to communicate with UE-B by video, but UE-B only
>  > > want to
>  > > > > communicate by audio.
>  > > >
>  > > > then UE-B rejects the video stream and the video stream is never
>  > > > established.
>  > > >
>  > > > Cheers,
>  > > >
>  > > > Gonzalo
>  > > >
>  > > >
>  > > > --------------------------------------------------------
>  > > > 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 an d 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.
>  > >
>  > >
>  > >
>  > > --------------------------------------------------------
>  > > 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.
>  >
>  > _______________________________________________
>  > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
>  > This list is for NEW development of the application of SIP
>  > Use [email-masked] for questions on current sip
>  > Use [email-masked] for new developments of core SIP
> 
> ------------------------------------------------------------------------
> 使用新一代 Windows Live Messenger 轻松交流和共享！ 立刻下载！ 
> <http://im.live.cn/messenger.aspx>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 1 Mar 2009 22:37:26 +0100

Hi Paul,

As long as the intermediates don't reject offers I don't think there should be a problem - as long as we can come up with some understandable rules, that is :)

Regarding using media one is not being charged for, I agree with you. I don't think that has anything do to with this discussion. I can call you, being charged for audio (the SDP only contains audio), and we can verbally agree on what IP address/ports and codecs to use for video. If operators want to prevent that they need other mechanisms - offer/answer rules won't prevent it.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Sunday, March 01, 2009 10:43 PM
To: gaoyang
Cc: Gonzalo Camarillo; [email-masked]; [email-masked]; [email-masked]; Christer Holmberg
Subject: Re: [Sipping] Closing the offer/answer rollback issue -- New drawbacks

I just tried to catch up on the discussion here. I mostly see circular argument/counterargument with no changing of position.

The only thing I have seen here that seems new is Gonzalo's proposal about "media in use".

I see a lot of issues raised about UAs using media they are not being charged for. As Tom Taylor said, this is not a new argument, or unique to this situation. There is always the possibility that two UAs will attempt to communicate using media they did not signal in an obvious way in the signaling channel. If they succeed in doing so, it is presumably because they are using a media path that they have access to independent of the signaling. In that case the intermediary who feels it should be charging for this is simply hoping to charge for a service it is not providing, and so has no real grievance.

The case where this might be a real problem is if a middlebox controls the media path (what resources are assigned, and whether media is / isn't permitted to flow), and yet the rules about session state are such that the middlebox and the endpoints have differing understandings of whether the active session includes a given media path or not. IMO that is the key issue that needs to be nailed down.

	Thanks,
	Paul

gaoyang wrote:
> some with precondition not OK, some without precondition or 
> precondition has been OK.
> The modification part of the later(without precondition or 
> precondition has been OK) can need for "*asking the user for confirmation*".
>  
>  > Date: Fri, 27 Feb 2009 12:38:14 +0200  > From: 
> [email-masked]  > To: [email-masked]  > CC: 
> [email-masked]; [email-masked]; 
> [email-masked]  > Subject: Re: [Sipping] 答复: Re: 答复: 
> Re: 答复: Re: ??: Re: ??: Re:
> rollback issue  >  > Hi,  >  > at this point, the discussions are 
> going in circles and are not  > productive any longer. No new ideas 
> are being introduced.
>  >
>  > I think I now understand your main points (media synchronization 
> and  > session continuity) so that I can put together a more formal 
> description  > of the straw-man proposal in my original email that 
> meets all the  > requirements brought up here.
>  >
> > modifications (e.g., a clarification of the "in use" concept) in 
> order  > to better address your concerns.
>  >
>  > Thanks for your input,
>  >
>  > Gonzalo
>  >
>  > > And with precondition, the user can be hinted the new 
> modification just  > > after Offer/Answer pairs.
>  > >
>  > >
>  > >
>  > >
>  > > *Gonzalo Camarillo <[email-masked]>*  > >  > > 
> 2009-02-27 18:22  > >  > >  > > 收件人
>  > > [email-masked]
>  > > 抄送
> [email-masked],  > > [email-masked], [email-masked]  
> > > 主题
>  > > Re: ??: Re: ??: Re: Closing the offer/answer rollback issue  > >  
> > >  > > & gt; >  > >  > >  > >  > >  > > Hi,  > >  > > UEB would have 
> rejected the video stream in the 183 response.
>  > >
>  > > Gonzalo
>  > >
>  > > > I think the video will be established.The figure below shows 
> the case.
>  > > >
>  > > >
>  > > > 1. REINVITE(audio，vedio)
>  > > > <------------------------------>  > > > 4. UPDATE(audio，vedio)
>  > > > After step 5, UEs' precondition are met ,and the video stream 
> is  > > > established too.
>  > > > *Gonzalo Camarillo <[email-masked]>*  > > >  > 
> > > 2009-02-27 17:30  > > >  > > >  > > > 收件人
>  > > > [email-masked]
>  > > > 抄送
>  > > > [email-masked],  > > [email-masked], 
> [email-masked],  > > > [email-masked]  > > > 主题
>  > > > Re: ??: Re: Closing the offer/answer rollback issue  > > >  > > 
> >  > > >  > > >  > > ; >  > > >  > > >  > > >  > > > Hi,  > > >  > > > 
> > If UE-A wants to communicate with UE-B by video, but UE-B only  > > 
> want to  > > > > communicate by audio.
>  > > >
>  > > > then UE-B rejects the video stream and the video stream is 
> never  > > > established.
>  > > >
>  > > > Cheers,
>  > > >
>  > > > Gonzalo
>  > > >
>  > > >
>  > > > 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 an d 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.
>  > >
>  > >
>  > >
>  > > ZTE Information Security Notice: The information contained in 
> this mail is solely property of the sender's organization. This mail 
> 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.
>  >
>  > This list is for NEW development of the application of SIP  > Use 
> [email-masked] for questions on current sip  > Use 
> [email-masked] for new developments of core SIP
> 
> This list is for NEW development of the application of SIP Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments of core SIP

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 1 Mar 2009 17:36:36 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Sunday, March 01, 2009 3:43 PM
>

+1

-hadriel

---

From: [email-masked]
Date: Mon, 2 Mar 2009 10:25:56 +0800

Hi Paul

I agree with you on the talk on middlebox control.

But I still think charge issue is exist. 
I answered Tom Taylor last Saturday from [email-masked]. But the 
mail list did not dispact it. I will send it again.

Gao

Paul Kyzivat <[email-masked]> 
2009-03-02 04:42

收件人
gaoyang <[email-masked]>
抄送
[email-masked], [email-masked], 
[email-masked], [email-masked], [email-masked]
主题
Re: [Sipping] Closing the offer/answer rollback issue -- New drawbacks

                 Thanks,
                 Paul

>  > modifications (e.g., a clarification of the "in use" concept) in 
order
this
>  > > > This email an d any files transmitted with it are confidential 
and
>  > > > This message has been scanned for viruses and Spam by ZTE 
Anti-Spam

--------------------------------------------------------
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: [email-masked]
Date: Mon, 2 Mar 2009 10:54:54 +0800

/********* the mail to Tom ************
Tom:
 
Thanks for you attention. 
 
Answer for you:
In fact, by the original mail from the Chair, the modification will be 
letted alone, without any help of hacked software.
 
And the only way is waiting for user's Self-discipline Re-INVITE.
 
If we make new UA equipment, I can do it. (althogh I do not prefer)
But for current using ones, it will be Compatible issue.
 
There is no fault from users and current UA equipment.
 
That's the difference, I think.
 
Waiting for you more comments. And I like talking this style.
 
Gao.
********end of the mail to Tom ***********/

By my view, there are two main points:

1. "hacker way" is user's behavior, but "Let alone the modification" is 
system behavior.

2. If user think they rejected the modification, "Let alone the 
modification" can send information which user do not want to be sent.

收件人

                 Thanks,
                 Paul

order
this
and
Anti-Spam

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 01 Mar 2009 23:04:53 -0500

I don't understand your point at all.

If the UAs have a media stream that works, then there is no reason why
they should not use it if they wish. The main point of the signaling is
for the two of them to negotiate what they want to do. That need have
nothing to do with billing/charging/paying. Its quite possible that
there is no incremental cost for using the stream vs. not using it.
(This is the case when I make a sip call over my internet connect - that
I pay for monthly regardless of use.)

If an entity in the middle of the network is providing resources for
transporting the media, and charges for that, then it had better ensure
that it knows when that resource is being used, and charge accordingly.
If there is a way for the two endpoints to use the media resource and
not be charged for it, then you can be quite certain that some will find
a way to exploit that.

Of course the converse situation exists as well. If the entity in the
middle charges for a resource that it believes it is providing and is
being used, but the endpoints don't know that they are being charged,
then they will eventually discover this and will argue that the bill is
in error.

The worst situation, IMO, is when some entity in the middle bills for
the transport of media yet provides no extra service to convey the
media. It is then simply charging for an illusory "service" which is
unjustified. It may have provided a service of helping in the exchange
of the signaling messages, and so should perhaps get a fee for that, but
not for the media itself.

	Thanks,
	Paul

[email-masked] wrote:
> And the only way is waiting for user's *Self-discipline *Re-INVITE.
> 
> But for current using ones, it will be *Compatible* issue.
> 
> *Paul Kyzivat <[email-masked]>*
> 
> 2009-03-02 04:42
> 
> 	
> 收件人

---

From: [email-masked]
Date: Mon, 2 Mar 2009 13:17:32 +0800

2009-03-02 12:04

收件人
[email-masked]
抄送
[email-masked], gaoyang <[email-masked]>, 
[email-masked], [email-masked], [email-masked]
主题
Re: 答复: Re: [Sipping] Closing the offer/answer rollback issue -- New 
drawbacks

[Gao] I think if user rejected the modification, UAs MUST NOT still let 
the modification works.
If the modification still works and the user think he/she has rejected it, 
some info can be sent beyond user's view.

For example, A and B have audio talk and A requests B to add vedio. B 
thinks he/she does not prefer vedio now, so rejects it.
B think he/she has rejected, so he/she would do something. But all the 
thing is under A's eyes.

I think system should close the door for B, that's the reason I said "Let 
alone the modification" is not a nice system behavior.

[Gao] Yes. But if B just not send a new Re-INVITE(as Holmberg said) to 
close the door. Do you think it is B's/*B's UA's* fault, or the operator 
can charge it.

[Gao] Yes. We can find user's rejecting by signal of 4xx, and the "using 
media" footprint.
If the user forgetting to send a new Re-INVITE, we should not charge it.
If the user just using it for means, we can charge it.

But it is hard to distinguish it.

[Gao] Yes.

                 Thanks,
                 Paul

> *Paul Kyzivat <[email-masked]>*
precondition
>  > The modification part of the later(without precondition or 
precondition
and
order
>  >  > > And with precondition, the user can be hinted the new 
modification
>  >  > > > I think the video will be established.The figure below shows 
the
>  >  > > > 1. REINVITE(audio，vedio)
is
>  >  > > > then UE-B rejects the video stream and the video stream is 
never
this
and
this
this
>  > intended solely for the use of the individual or entity to whom they 
are
those
Anti-Spam
> 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.
system.