Subject: [Sipping] Closing the offer/answer rollback issue

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Feb 2009 13:42:39 +0200

Folks,

it is time to close the offer/answer rollback issue. We need to make a 
decision and move forward.

We face this issue when one or more offer/answer exchanges are 
successfully completed within a re-INVITE that ends up failing. The 
question is, what should the session state be after the re-INVITE fails. 
For more details on this issue, see:

http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-10#section-6.2

A more-or-less straight forward solution would be to specify that the 
session state should be that of the last offer/answer exchange that was 
completed successfully. We lose the atomicity of the re-INVITE, but it 
is a price most people seem willing to pay according to our discussions.

Now, there is an additional issue with this solution. What happens if 
the last successfully completed offer/answer exchange contained 
preconditions that were never met? In that case, media changes in that 
offer/answer exchange that were affected by the preconditions had not 
been executed. Per RFC3312:

http://tools.ietf.org/html/rfc3312#section-6

   "However, offers containing
    preconditions sent in the middle of an ongoing session need further
    explanation.  Both user agents SHOULD continue using the old session
    parameters until all the mandatory preconditions are met. "

A solution to this issue could be to specify that, when the re-INVITE 
fails, the session state should be that which is *in use* at that point.

Of course, we need to clarify what "in use" exactly means. The idea 
would be the following:

An INVITE request establishes a session:

      INVITE
------------------>
       200
<------------------

After this first offer/answer exchange, we have an audio stream and a 
video stream using the following codecs:

audio stream: audio codec 1
video stream: video codec 1

Now we have a re-INVITE with an offer that changes the codec for the 
audio stream to audio codec 2 and the video codec to video codec 2. The 
change in the video codec is subject to preconditions. The answer 
arrives in a reliable 1xx response:

audio stream: audio codec 2
video stream: video codec 2 (subject to preconditions)

    re-INVITE
------------------>
       1xx
<------------------

Now, the session state in use is the following:

audio stream: audio codec 2
video stream: video codec 1

The video codec has not been changed (yet) because the preconditions for 
the video stream has not been met yet.

Now, the re-INVITE fails with a 4xx response. The session state *in use* 
would be the one above, which is a mixture between the first the second 
offer/answer exchanges. The state of the audio stream comes from the 
second exchange while the state of the video stream comes from the first 
exchange (because the preconditions in the second exchange for that 
media stream were never met).

At this point, the endpoints could perform a new offer/answer exchange 
just to make sure they both are on the same page.

Do people think it would be worthwhile specifying/clarifying this *in 
use* concept?

We would appreciate comments on this because, as stated above, we would 
like to close this in a relatively short time.

Thanks,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 26 Feb 2009 13:05:23 +0100

Hi,

If we want to go for a solution where the precondition state matters,
there is one issue:

Assume that one side has indicated that his preconditions are met, but
the other side has still not indicated it. What happens now if the
re-INVITE fails?

I ASSUME we would have to say that if all preconditons - on both sides -
are met, the change is comitted and there is no fallback. If the
preconditions are met only on one side, and the re-INVITE fails, there
is a fallback. Or?

In addition, there is also the "late commitment" concept by Gao.

I am afraid that we make all this too complicated for its own good. The
easiest solution is to say that all changes are commited (or current
agreement), OR that there is always a full rollback if the re-INVITE
fails.

The second alternative was favored e.g. by Paul, but the problem was the
UPDATE race condition. But, that could be solved by the BCP proposal by
Gao: use UPDATEs only "inside" a re-INVITE transaction.

It is also quite difficult to discuss this per e-mail: a face-to-face
meeting, with a big whiteboard, would be much better. But, AFAIK many of
the key persons in this issue are not coming to SFO, so I don't know
when such meeting could take place...

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Gonzalo Camarillo
Sent: Thursday, February 26, 2009 1:43 PM
To: sipping
Subject: [Sipping] Closing the offer/answer rollback issue

Folks,

http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-10#section
-6.2

      INVITE
------------------>
       200
<------------------

    re-INVITE
------------------>
       1xx
<------------------

Thanks,

Gonzalo

_______________________________________________
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: [email-masked]
Date: Thu, 26 Feb 2009 20:26:44 +0800

Dear Christer Holmberg

"late commitment" of modification triggered by Re-INVITE is important from 
user's experience.

And UPDATE race condition has a solution in theory in my draft. BCP 
proposal is anonther way :)

If you have time now, I'd like to have a further talk now.

yours Gao

"Christer Holmberg" <[email-masked]> 
发件人:  [email-masked]
2009-02-26 20:05

收件人
"Gonzalo Camarillo" <[email-masked]>, "sipping" 
<[email-masked]>
抄送

主题
Re: [Sipping] Closing the offer/answer rollback issue

Hi,

Regards,

Christer

-----Original Message-----

Folks,

      INVITE
------------------>
       200
<------------------

    re-INVITE
------------------>
       1xx
<------------------

Thanks,

Gonzalo

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

--------------------------------------------------------
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: Thu, 26 Feb 2009 20:43:01 +0800

Dear Gonzalo Camarillo and all the people in the SIPPING mail list:

I think this problem is important. We should choose a right way for the 
future.

Could we make the main proposal(such as mine and Christer Holmberg's) as a 
WG draft. I think it is important to let the people outside the SIPPING 
mail list to join in the disccussion, if they want. :)

I think my draft have solved this problem, and without any violation of 
current RFCs. But I still prefer the inspection from  the people outside 
the SIPPING mail list.

Gao

Gonzalo Camarillo <[email-masked]> 
发件人:  [email-masked]
2009-02-26 19:42

收件人
sipping <[email-masked]>
抄送

主题
[Sipping] Closing the offer/answer rollback issue

Folks,

      INVITE
------------------>
       200
<------------------

    re-INVITE
------------------>
       1xx
<------------------

Thanks,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 26 Feb 2009 13:43:20 +0100

Hi,

>"late commitment" of modification triggered by Re-INVITE is important from user's experience.  
 
Assume I send a re-INVITE with an offer, without preconditions or UPDATEs. If the receiving user is prompted to accept/reject the offer, I don't think there will be a 18x with an answer. If the receiving user accepts the offer there will be a 200 with the answer, or if the receiving user rejects the offer there will be some error response.
 
Then, assume I send a re-INVITE with an offer, WITH preconditions, UPDATEs etc etc etc. At some point the re-INVITE will either be rejected or accepted.
 
So, would it not be easier to ALWAYS apply "late commitment" - no matter whether there are preconditions, UPDATEs or not? 
 
And, that would be the same as saying that there is a full rollback if the re-INVITE fails.

>And UPDATE race condition has a solution in theory in my draft. BCP proposal is anonther way :)  
 
Yes.
 
Regards,
 
Christer

yours Gao 

2009-02-26 20:05 

收件人
"Gonzalo Camarillo" <[email-masked]>, "sipping" <[email-masked]> 
抄送
主题
Re: [Sipping] Closing the offer/answer rollback issue

Hi,

Regards,

Christer

-----Original Message-----

Folks,

     INVITE
------------------>
      200
<------------------

   re-INVITE
------------------>
      1xx
<------------------

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Feb 2009 15:01:13 +0200

Hi Christer,

> the other side has still not indicated it. What happens now if the

endpoints always know what is the session "in use" because that is the 
way their media tools are currently configured. Therefore, no matter 
what the precondition state is, you always revert to the state your 
media tools are in.

Of course, race conditions may be an issue, but not only in this 
particular case. They are a general issue that needs to be resolved in a 
general way.

Cheers,

Gonzalo

---

From: [email-masked]
Date: Thu, 26 Feb 2009 21:08:32 +0800

2009-02-26 20:43

收件人
<[email-masked]>
抄送
"Gonzalo Camarillo" <[email-masked]>, "sipping" 
<[email-masked]>, <[email-masked]>
主题
RE: Re: [Sipping] Closing the offer/answer rollback issue

Hi,

>"late commitment" of modification triggered by Re-INVITE is important 
from user's experience.  
 
Assume I send a re-INVITE with an offer, without preconditions or UPDATEs. 
If the receiving user is prompted to accept/reject the offer, I don't 
think there will be a 18x with an answer. If the receiving user accepts 
the offer there will be a 200 with the answer, or if the receiving user 
rejects the offer there will be some error response.

[Gao] I agree with you. Without precondition or UPDATE is simple, and the 
session state is clear.
 
Then, assume I send a re-INVITE with an offer, WITH preconditions, UPDATEs 
etc etc etc. At some point the re-INVITE will either be rejected or 
accepted.
 
So, would it not be easier to ALWAYS apply "late commitment" - no matter 
whether there are preconditions, UPDATEs or not? 

And, that would be the same as saying that there is a full rollback if the 
re-INVITE fails.

[Gao] Precondition notification and a new modification will make different 
result.
Precondition notification is part of the orignal modification triggered by 
Re-INVITE, so it obeys "late commitment".

A new modification is a new one, so it have nothing to do with Re-INVITE 
and its final response. 

So, the session state is clear.
 
 I re-arrage the Rules in version 02 by the talk in the mail list with you 
and others, I think it is more readable.

I should point out that, the definition in "a new modification" just obeys 
RFC3264. But any organization or operator can add it definition.
Such as "refine of Codec", some people in or out of my corporation treat 
it is part of the original the modification; some treat it not.
In the framework of nested transaction, it is just the form of the nested 
transaction. Any understanding has clear session state.
As IETF's text are the base of others, so I omit any definition beyond 
RFCs.

Yes.
 
Regards,
 
Christer

yours Gao 

收件人

主题

Hi,

Regards,

Christer

-----Original Message-----

Folks,

     INVITE
------------------>
      200
<------------------

   re-INVITE
------------------>
      1xx
<------------------

Thanks,

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 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: Thu, 26 Feb 2009 21:28:46 +0800

Dear Gonzalo Camarillo

Two sides can have different precondition, so it can be one side's 
precondition satisfied while the other's not.

And this will make the two sides have different session state.

But rollback the session state after 4xx, will make the session state 
clear.(if the modification is triggered by Re-INVITE)

If the modification is triggered by UPDATE(no matter during or outside 
Re-INVITE), it has nothing to do with Re-INVITE.

And if the other side can not accept it without user's permition(or with 
mandatory precondition), the other side should reject it by 504(defined in 
RFC3311).
But if it accept it, the modification would be committed. 

Triggering a new modification with precondition using UPDATE is an 
interesting thing.(I recommend to do so using Re-INVITE)
The session modification would be committed in signal level, but suspended 
in media level. But the session state is clear.

yours Gao

2009-02-26 21:01

收件人
Christer Holmberg <[email-masked]>
抄送
sipping <[email-masked]>
主题
Re: [Sipping] Closing the offer/answer rollback issue

Hi Christer,

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Feb 2009 15:30:44 +0200

Hi,

> I think this problem is important. We should choose a right way for the 

yes, that is why we should make a decision, close it, and move forward.

> Could we make the main proposal(such as mine and Christer Holmberg's) as 
> a WG draft. I think it is important to let the people outside the 
> SIPPING mail list to join in the disccussion, if they want. :)

we already have a WG draft. What we are discussing here is how to close
an open issue within that draft. I made a concrete proposal on this
thread and asked for feedback on it. Please, focus on discussing that
point so that we can move forward. If you want to discuss different
issues, feel free to do it in a different thread.

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Feb 2009 15:33:17 +0200

Hi,

> precondition satisfied while the other's not.

endpoints should not care about whether or not *some* preconditions are
met. They just care about the *current* media state. The media state
only changes when *all* preconditions are met.

Cheers,

Gonzalo

---

From: [email-masked]
Date: Thu, 26 Feb 2009 21:38:33 +0800

I think we are talking the same thing :).

The main problem is What the session state is.

Perhaps I said somthing on How to have a clear session state. I think the 
two has correlation.

2009-02-26 21:30

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

Hi,

Thanks,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 26 Feb 2009 14:46:25 +0100

Hi,
   
>[Gao] Precondition notification and a new modification will make different result. 
>Precondition notification is part of the orignal modification triggered by Re-INVITE, so it obeys "late commitment". 
> 
>A new modification is a new one, so it have nothing to do with Re-INVITE and its final response.  
 
Yes, but the question is to clearly define what a "new modfication" is. I think your draft doesn't define it clear enough (or, 3264 is not clear enough). Also, you may have offers/answer which contain both modifications and notifications.
 
Solution 1:
---------------
 
One could of course say that if the SDP version number is modified, then it is a new modification - no matter what has changed.
 
But, I THINK one has to update the SDP version number also for pure precondition notifications, so I am not sure it would work.
 
Solution 2:
---------------
 
Another way would be to recommend against using new modifications inside re-INVITEs. In real life I think the most common use-cases are going to be things like codec refine etc.
 
>I should point out that, the definition in "a new modification" just obeys RFC3264. But any organization or operator can add it definition.  
 
3GPP, OMA, TISPAN, IETF etc shall NOT make their own definitions - there should be a common one. That's the main reason 3GPP sent the LS to IETF in the first place.
 
Becuase, if I call from my 3GPP client to an IETF client, the re-INVITE fails and 3GPP and IETF have different "defintions", we are in the same situation where we are today.

>Such as "refine of Codec", some people in or out of my corporation treat it is part of the original the modification; some treat it not.  
 
Everybody have to treat it in the same way. You can not assume that both endpoints are specified by the same "organization". Both the UAC and the UAS has to know what the status is if the re-INVITE fails.
 
Regards,
 
Christer

Hi,

Regards,

Christer

-----Original Message-----

Folks,

    INVITE
------------------>
     200
<------------------

  re-INVITE
------------------>
     1xx
<------------------

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Feb 2009 15:49:58 +0200

Hi,

what I would like to know is if rolling back to the session state "in
use" is an acceptable solution for you.

Thanks,

Gonzalo

[email-masked] wrote:
> Perhaps I said somthing on How to have a clear session state. I think 
> the two has correlation.
> 
> 
> 
> 
> *Gonzalo Camarillo <[email-masked]>*
> 
> 2009-02-26 21:30
> 
> 	
> 收件人
> 	[email-masked]
> 抄送

---

From: [email-masked]
Date: Thu, 26 Feb 2009 21:51:52 +0800

Dear Gonzalo Camarillo

You mean that one side should suspend until its and the other side's 
precondition OK?

I do think it is RFC3312's meaning.

RFC3312:
A user agent server knows that all the preconditions are met for a
   media line when its local status table has a value of "yes" in all
   the rows whose strength-tag is "mandatory".  When the preconditions
   of all the media lines of the session are met, session establishment
   SHOULD resume.

                  Direction   Current  Desired Strength
                  ______________________________________
                  local send     no           none
                  local recv     no           none
                  remote send    no         optional
                  remote recv    no           none

m=audio 20002 RTP/AVP 0
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos optional local sendrecv
a=des:qos mandatory remote sendrecv

It is one side's precondition. Perhaps the other side has different 
precondition.

And I think one side need not to care about the other side's precondition

2009-02-26 21:33

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

Hi,

Cheers,

Gonzalo

---

From: [email-masked]
Date: Thu, 26 Feb 2009 21:56:30 +0800

Not acceptable by my personal view.

Reason:

1. define "in use" may make violation of current RFCs.

2. the two side can have different view of "in use".

3. And as there is a clear session state by current RFCs, why not choose 
it :).

2009-02-26 21:49

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

Hi,

Thanks,

Gonzalo

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Feb 2009 15:59:13 +0200

Hi,

I am talking about the parameters you are actually *using* in your media
session. For example, you are exchanging media using a particular codec.
That is the session in use.

Now, you may want to change that codec subject to preconditions. If
those preconditions are never met and you never get to change to the new
codec, then the session "in use" has not changed. See my original email
for an example of this situation.

Thanks,

Gonzalo

[email-masked] wrote:
>    media line when its *local status table* has a value of "yes" in all

---

From: Eric wang <[email-masked]>
Date: Thu, 26 Feb 2009 22:03:59 +0800

Dear all,

    I think the discussion should be continued or moved forward.
    Just raise an example, In RFC3264, phones should listen on both the old
port and the new port, but not all the phones support this rule.Then finding
the right session state to switch if new sdp negotiates success,or finding
the proper state to fallback or remain listening if new sdp negotiates
fails.
It's useful the find the state.
    I think that the draft gives a way to find the state.

Regards,
Eric.wang

---

From: [email-masked]
Date: Thu, 26 Feb 2009 22:05:49 +0800

A's Offer
audio stream: audio codec 2
video stream: video codec 2 (A's preconditions, mandatory)

B's Answer
audio stream: audio codec 2
video stream: video codec 2 (A's preconditions, optional)

A will use 

B will use
audio stream: audio codec 2
video stream: video codec 2

It is different of "strength-tag ". And precondition itself can be 
different, such as B care something A never care.

2009-02-26 21:59

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

Hi,

Thanks,

Gonzalo

system.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Feb 2009 16:06:39 +0200

Hi,

> 1. define "in use" may make violation of current RFCs.

the issue we are talking about is not addressed by current RFCs. As I
indicated in my original email, we will have to make compromises. After
many discussions within the WG, the current understanding is that we are
willing to lose the atomicity of re-INVITEs. The idea is not to avoid
violations by all means but to choose the best solution.

> 2. the two side can have different view of "in use".

if two endpoints are involved in a media session, they need to have the
same view. Otherwise, if an endpoint uses a codec the other endpoint is
not ready to receive, nothing would work. Could you provide an example
of a situation where two endpoints are not in synch.

> 3. And as there is a clear session state by current RFCs, why not choose 

Section 6 of RFC 3312 introduces the concept of the session parameters
the endpoints are using and the session parameters the endpoints will
use once their preconditions are met. However, that RFC did not define
the concept formally or clearly. We can define it properly if we think
it is a useful concept to have.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Feb 2009 09:11:27 -0500

Gonzalo,

I think your proposal/concept about "in use" is interesting.
But is is it in fact the case that all involved parties agree on what
that is?

I think this could especially be a problem for B2BUAs that don't
terminate media. Their *only* knowledge about the current state is what
they have learned from the signaling. Based on that they may have to
decide which SDP reflects what is currently "in use". But perhaps this
isn't really a problem and the B2BUA will simply discover the current
state later based on subsequent interactions with the two UAs.

Also, "using" has two parts: "sending" and "receiving". There are
definitely windows during which one end is "sending" something but the
other side isn't "receiving" it yet.

There are also those middleboxes that control "media gates" - only
letting media pass if the O/A conforms to their policies. Its unclear to
me how they are affected by this decision. But it could enhance the
difference between what one side is sending and the other side is receiving.

Replying to Gao/Christer - I remain confused about what constitutes a
"new modification". I know there are sequences in use where the initial
exchange is done with a=inactive, and then another o/a is exchanged,
within the (re)INVITE to switch to a=sendrecv. Is that a "new
modification", or not?

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Feb 2009 16:11:44 +0200

Hi,

your example is not possible. An answerer cannot downgrade the
precondition from mandatory to optional. See Section 5.2 of RFC 3312:

http://tools.ietf.org/html/rfc3312#section-5.2

      Desired Strength: We define an absolute ordering for the
            strength-tags: "none", "optional" and "mandatory".
            "Mandatory" is the tag with the highest grade and "none" the
            tag with the lowest grade.  An answerer MAY upgrade the
            desired strength in any entry of the transaction status
            table, but it MUST NOT downgrade it.  Therefore, it is OK to
            upgrade a row from "none" to "optional", from "none" to
            "mandatory", or from "optional" to "mandatory", but not the
            other way around.

Cheers,

Gonzalo

[email-masked] wrote:
>  > 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: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Feb 2009 16:17:24 +0200

Hi Paul,

current B2BUAs already need to keep track of these things. Let's say
that instead of changing a codec an endpoint wants to change the UDP
port for the stream subject to preconditions. If the B2BUA wants to be
able to keep the right pin holes open and open new ones at the right
time, it needs to understand that the endpoints will be using their old
session parameters until the preconditions are met. So, we are not
imposing any new requirements on B2BUAs.

Also, the state of the session can be derived from the signalling going
back and forth. That is, the B2BUA has all the information needed in
order to know which session parameters are currently being used.

Cheers,

Gonzalo

---

From: [email-masked]
Date: Thu, 26 Feb 2009 22:17:10 +0800

Dear Christer Holmberg

In the Version 02 of my draft, I add "new modification"'s definition. You 
said you have a urgent issue this week, so perhaps you did not have time 
to read it :).

The framework of nested transaction is open for "codec refine" as 
sub-transaction or not.

Two main work of my draft is:

1. introducing nested transaction to session modification( this is for 
current and future).

2. define the cascade of nested transaction for current usages.

In fact, "codec refine" concerns to 2.

And it is in Version 00 and 01. If you and other think it is useful, I 
will added it again.

yours Gao

2009-02-26 21:46

收件人
<[email-masked]>
抄送
<[email-masked]>, "sipping" <[email-masked]>, "Gonzalo 
Camarillo" <[email-masked]>
主题
RE: [Sipping] 答复: RE: Re:  Closing the offer/answer rollback issue

Hi,
  
>Then, assume I send a re-INVITE with an offer, WITH preconditions, 
UPDATEs etc etc etc. At some point the re-INVITE will either be rejected 
or accepted.  
>Precondition notification is part of the orignal modification triggered 
by Re-INVITE, so it obeys "late commitment". 
and its final response.  
 
Yes, but the question is to clearly define what a "new modfication" is. I 
think your draft doesn't define it clear enough (or, 3264 is not clear 
enough). Also, you may have offers/answer which contain both modifications 
and notifications.
 
Solution 1:
---------------
 
One could of course say that if the SDP version number is modified, then 
it is a new modification - no matter what has changed.
 
But, I THINK one has to update the SDP version number also for pure 
precondition notifications, so I am not sure it would work.
 
Solution 2:
---------------
 
Another way would be to recommend against using new modifications inside 
re-INVITEs. In real life I think the most common use-cases are going to be 
things like codec refine etc.
 
>I should point out that, the definition in "a new modification" just 
obeys RFC3264. But any organization or operator can add it definition.  
 
3GPP, OMA, TISPAN, IETF etc shall NOT make their own definitions - there 
should be a common one. That's the main reason 3GPP sent the LS to IETF in 
the first place.
 
Becuase, if I call from my 3GPP client to an IETF client, the re-INVITE 
fails and 3GPP and IETF have different "defintions", we are in the same 
situation where we are today.

Everybody have to treat it in the same way. You can not assume that both 
endpoints are specified by the same "organization". Both the UAC and the 
UAS has to know what the status is if the re-INVITE fails.
 
Regards,
 
Christer

Hi,

Regards,

Christer

-----Original Message-----

Folks,

    INVITE
------------------>
     200
<------------------

  re-INVITE
------------------>
     1xx
<------------------

Thanks,

Gonzalo

---

From: [email-masked]
Date: Thu, 26 Feb 2009 22:29:33 +0800

Thanks for your correct.

If one side without precondition, the other with. It might make different 
view.

And in fact, by my proposal, "late commitment" is the final commitment of 
Re-INVITE.
Two side's differet view of precondition will not violate the rollback.

2009-02-26 22:11

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

Hi,

Cheers,

Gonzalo

system.

---

From: [email-masked]
Date: Thu, 26 Feb 2009 22:38:36 +0800

Dear Paul Kyzivat

What is "a new modification" by user's view will make the cascade of the 
O/A pairs in modification.

And we should give user the session state they anticipanted.

Precondition notification is not "a new modification". And most of the 
people would agree this.
And distinguish it is not a hard way.

Another well known is "refine codec", it is also practical to distinguish 
it.

And it really open the door for complex modification using more than one 
O/A pair as precondition.

Gao

Paul Kyzivat <[email-masked]> 
2009-02-26 22:11

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

Gonzalo,

There are also those middleboxes that control "media gates" - only
letting media pass if the O/A conforms to their policies. Its unclear to
me how they are affected by this decision. But it could enhance the
difference between what one side is sending and the other side is 
receiving.

                 Thanks,
                 Paul

system.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Feb 2009 16:40:42 +0200

Hi,

> If one side without precondition, the other with. It might make 
> different view.

this is also impossible. If an offer does not have preconditions, the
answerer cannot add them.

Cheers,

Gonzalo

---

From: [email-masked]
Date: Thu, 26 Feb 2009 22:53:24 +0800

Dear Gonzalo Camarillo

I remember 3GPP have situation that one side with, other side without.

But I reviewed the RFC:

An offerer MUST include this tag in the
   Require header field if the offer contains one or more "mandatory"
   strength-tags.

So, you are right :).

But this is not the main branching of our view.

Gao

2009-02-26 22:40

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

Hi,

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Feb 2009 16:57:44 +0200

Hi,

> But this is not the main branching of our view.

if you have requirements in mind that are not covered by the straw-man
proposal I made in my initial email, please share them with us. As I
said, I would like to have focused discussions on this issue so that we
can close it sooner rather than later.

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Feb 2009 17:52:32 +0200

Hi,

could you please briefly summarize the drawbacks of the straw-man
proposal I made in my original email? You draft could not have addressed
that because the proposal has been made today.

I would like to understand which requirements it fails to address in
order to improve it if necessary until all (or as many as possible)
requirements are reasonably covered.

Thanks,

Gonzalo

gaoyang wrote:
>  
>  
>  
> I am Gao([email-masked] <mailto:[email-masked]>). There's 
> something wrong with my mail server.
> So, I use my personal email here.
>  
> My draft is talking about the Open Issue.
> URL: 
> http://www.ietf.org/internet-drafts/draft-gaoyang-sipping-session-state-criterion-02.txt
>  
> And I talked drawback of current proposed solutions.
>  
> 
>  
>  > Date: Thu, 26 Feb 2009 16:57:44 +0200
>  > From: [email-masked]
>  > To: [email-masked]
>  > CC: [email-masked]; [email-masked]
>  > Subject: Re: [Sipping] 答复: Re: 答复: Re: 答复: Re: 答复: Re: 答复: 
> Re: Closing the offer/answer rollback issue
>  >
>  > Hi,
>  >
>  > Use [email-masked] olumbia.edu for questions on current sip
> ------------------------------------------------------------------------
> 更多热辣资讯尽在新版MSN首页！ 立刻访问！ <http://cn.msn.com/>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Feb 2009 18:20:26 +0200

Hi,

> 2.1.2.  Confirmed state but not enough for usage

this point does not apply to the proposal because we are not performing
any rollback at the media level. Whatever media parameters are being
used they will still be used after the re-INVITE fails. Therefore, the
point where the re-INVITE fails does not represent any discontinuity in
the media session. The media session continues as it was before the
failure of the re-INVITE.

> 2.1.4.  Illegal using session parameters
> 
>    The modification in media level can be used illegally, while the
>    modification is unsuccessful in signal level.

this does not apply to the proposal because the proposal does not
specify any new media usage. It simply tells the endpoints to continue
doing what they were already doing.

> 2.2.  Drawback of manual rollback

this does not apply to the proposal because there is no rollback at the
media level.

> 2.2.1.  Problems for ordinary SDP
> 
>    Sections mentioned above introduced "manual rollback" using a new Re-
>    INVITE as the way to resume the session under ambiguous situations.
>    But *if the two sides have no consistent view of session state, no
>    matter which side sends the new Re-INVITE, the other side will treat
>    it as violation of session continuity* because of different view of
>    session state.

you provided a few examples of situations where the endpoints may have
inconsistent views of the session state. None of the examples were
valid. If you could provide a valid example, it would help us understand
if there is a problem here.

In any case, if endpoints end up with an inconsistent view of the
parameters in use, it would be a bigger problem than the issue we are
talking about here, because it would mean that the media session between
them would not work.

> 2.2.2.  Problems for non-integrative SDP
> 
>    Because the SDP just describes part of the session, not all aspects
>    of the session.  It must be combined with the previous one(or ones)
>    to show the effects, as the formula:
> 
>    *"current session state" = "previous session state" + "modification
>    session description"*.
> 
> & nbsp;  Even if using a new Re-INVITE with "modification session
>    description", we can not rebulid the "current session state" without
>    the definition of the "previous session state".  So, the "previous
>    session state" is important here, and we still need to give out a
>    precise definition of session state to get the "previous session
>    state" here.

in the proposal we are discussing here, we do not need to rebuild any
state because we just continue using the current media state. Therefore,
this drawback does not apply to the proposal either.

Thanks,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 26 Feb 2009 20:10:43 +0100

Hi, 

>>If one side without precondition, the other with. It might make different view.
>
>this is also impossible. If an offer does not have preconditions, the answerer cannot add them.

Correct. 

Also, if an offer does not indicate preconditions, the assumption is that they are met.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 26 Feb 2009 20:11:39 +0100

Can you please tell me what 3GPP situation you are refering to?
 
Regards,
 
Christer

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 26, 2009 4:53 PM
To: Gonzalo Camarillo
Cc: Christer Holmberg; sipping
Subject: 答复: Re: 答复: Re: 答复: Re: 答复: Re: 答复: Re: [Sipping] Closing the offer/answer rollback issue

Dear Gonzalo Camarillo 

But I reviewed the RFC: 

So, you are right :). 

Gao 

2009-02-26 22:40 

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

Hi,

Cheers,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 26 Feb 2009 20:15:30 +0100

Hi,
 
I don't want to distinguish "refine codec", because then we may later find out other things that should also be distinguished.
 
In my opinion "refine codec" is as much modification as anything else.
 
Regards,
 
Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, February 26, 2009 4:39 PM
To: Paul Kyzivat
Cc: sipping; Gonzalo Camarillo
Subject: [Sipping] 答复: Re: 答复: Re: 答复: Closing the offer/answer rollback issue

Dear Paul Kyzivat 

What is "a new modification" by user's view will make the cascade of the O/A pairs in modification. 

Precondition notification is not "a new modification". And most of the people would agree this. 
And distinguish it is not a hard way. 

Another well known is "refine codec", it is also practical to distinguish it. 

And it really open the door for complex modification using more than one O/A pair as precondition. 

Gao 

2009-02-26 22:11 

收件人

Gonzalo,

                Thanks,
                Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 26 Feb 2009 20:31:26 +0100

Hi,
 
I think the definition of "in use" is:
 
"Whatever session parameters (SDP) have been negotiated, AND preconditions are met on both sides for those parameters."
 
The good thing with the "in use" approach is that we don't need to distinguish "codec refine" etc inside the offer/answers.

I guess the question is about "late commitment".
 
Take the following case:
 
1. The UAC wants to add video to a session, so it sends a re-INVITE, with preconditions.
 
2. There are PRACKs, UPDATEs, etc etc, and at some point both the UAC and the UAS indicate that preconditions are met.
 
3. The UAS is prompted if he wants to accept the video (I guess it's an implementation issue exactly at what point the UAS is prompted).
 
4. The UAS rejects the video, and an error response is sent for the video.
 
Now, with the pure "in use" proposal there is no rollback, because preconditions had been met before the rejection.
 
Using "late commitment", there would be a rollback, even if preconditions had been met before the rejection.

I do NOT think we should start talking about billing issues etc.

Regards,
 
Christer

From: gaoyang [mailto:[email-masked]] 
Sent: Thursday, February 26, 2009 6:38 PM
To: Gonzalo Camarillo
Cc: [email-masked]; [email-masked]; Christer Holmberg
Subject: RE: [Sipping] 答复: Re: 答复: Re: 答复: Re: 答复: Re: 答复: Re: Closing the offer/answer rollback issue

 
1. Make session state just out of signal control.
 
2. Is the session state the one user prefer?
 
Other comments inline.
 
> Date: Thu, 26 Feb 2009 18:20:26 +0200
> To: [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Sipping] 答复: Re: 答复: Re: 答复: Re: 答复: Re: 答复: Re: Closing the offer/answer rollback issue
> 
> Hi,
> 
 
I just mean that the session state is not the ine user prefer.
 
A new Re-INVITE is to fix it.

> doing what they were already doing.
 
If A want to use vedio, and B reject it. But A and B can use vedio and say that they have rejected using it by signal, and operater can not bill it.
 
> In any case, if endpoints e nd up with an inconsistent view of the
 
I talked it in the draft because some people treat it as solution.
If you do not think it is needful, we can stop talking manual rollback.

MSN 9.0 正式版上线，捆绑免费25G网络硬盘！ 立刻下载！ <http://im.live.cn/msn9/>

---

From: [email-masked]
Date: Fri, 27 Feb 2009 10:02:49 +0800

I just mean that if one side using Require precondition because of 
"mandatory" strength-tags, the other side would reject it with 421 while 
it do not using precondition.
Then the hypothetic situation(by me) is impossible. So, Gonzalo Camarillo 
is right.

2009-02-27 03:11

收件人
<[email-masked]>, "Gonzalo Camarillo" 
<[email-masked]>
抄送
"sipping" <[email-masked]>
主题
RE: Re: 答复: Re: 答复: Re: 答复: Re: 答复: Re: [Sipping] Closing the 
offer/answer rollback issue

Regards,
 
Christer

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, February 26, 2009 4:53 PM
To: Gonzalo Camarillo
Cc: Christer Holmberg; sipping
Subject: 答复: Re: 答复: Re: 答复: Re: 答复: Re: 答复: Re: [Sipping] 
Closing the offer/answer rollback issue

Dear Gonzalo Camarillo 

But I reviewed the RFC: 

So, you are right :). 

Gao 

收件人
[email-masked] 
抄送

Hi,

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 10:21:13 +0800

2009-02-27 03:15

收件人
<[email-masked]>, "Paul Kyzivat" <[email-masked]>
抄送
"sipping" <[email-masked]>, "Gonzalo Camarillo" 
<[email-masked]>
主题
RE: [Sipping] 答复: Re:  答复: Re: 答复:  Closing the offer/answer 
rollback issue

Hi,
 
I don't want to distinguish "refine codec", because then we may later find 
out other things that should also be distinguished.

[gao] Yes. So, I prefer a open way. 
We can give nested transaction concept and base definition of "new 
modification".

If there is on one extend the semantics of "new modification", it would be 
peace.
 If someone want to do so, he can do it.(but the one should consider the 
interoperability). And he can not say IEFT's restrict, and the 
interoperability is his issue.

And the door is open for the extension from IEFT.

[gao] I agree with you.
But as we can find a way to make the best of both worlds(the people think 
it is a new modification and the people think it is not).

Why not.

Regards,
 
Christer

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of [email-masked]
Sent: Thursday, February 26, 2009 4:39 PM
To: Paul Kyzivat
Cc: sipping; Gonzalo Camarillo
Subject: [Sipping] 答复: Re: 答复: Re: 答复: Closing the offer/answer 
rollback issue

Dear Paul Kyzivat 

Gao 

收件人

Gonzalo,

                Thanks,
                Paul

system.

---

From: [email-masked]
Date: Fri, 27 Feb 2009 10:33:05 +0800

Comments inline.

2009-02-27 03:31

收件人
"gaoyang" <[email-masked]>, "Gonzalo Camarillo" 
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
Re:  Closing the offer/answer rollback issue - definition of "in use"

Hi,

"Whatever session parameters (SDP) have been negotiated, AND preconditions 
are met on both sides for those parameters."
 
The good thing with the "in use" approach is that we don't need to 
distinguish "codec refine" etc inside the offer/answers.
 
 [gao] Yes. 
And my attitude towards "refine codec" is ,  I prefer a open way. 

Take the following case:
 
1. The UAC wants to add video to a session, so it sends a re-INVITE, with 
preconditions.
 
2. There are PRACKs, UPDATEs, etc etc, and at some point both the UAC and 
the UAS indicate that preconditions are met.
 
3. The UAS is prompted if he wants to accept the video (I guess it's an 
implementation issue exactly at what point the UAS is prompted).

Now, with the pure "in use" proposal there is no rollback, because 
preconditions had been met before the rejection.
 
Using "late commitment", there would be a rollback, even if preconditions 
had been met before the rejection.

[gao] Yes.  It is the situation.
With preconditionm, it is usually hint the user after preconditin OK. So, 
it alway reject in signal, "in use" in media level.

And without precondition, UA should hint the user before Answer(answering 
the offer). But there is really some UA hint the user after 
Answer(answering the offer).
So, the situation can be in situation without precondition.

[gao] Yes. I just think billing is a problem derived from violation of 
"late commitment".

Regards,
 
Christer

Subject: RE: [Sipping] 答复: Re: 答复: Re: 答复: Re: 答复: Re: 答复: Re: 

 
 
Other comments inline.

 

> doing what they were already doing.
 
If A want to use vedio, and B reject it. But A and B can use vedio and say 
that they have rejected using it by signal, and operater can not bill it.

> Gonzalo

MSN 9.0 正式版上线，捆绑免费25G网络硬盘！ 立刻下载！

---

From: [email-masked]
Date: Fri, 27 Feb 2009 11:19:37 +0800

I want to know can it be addressed.

2009-02-26 23:52

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

Hi,

Thanks,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 14:33:41 +0800

1. the situation of inconsistent media level(perhaps it is impossible)

UAC              UAS

Re-INVITE---------->(Offer)
<----------------183(Answer)
PRACK-------------->

Offer is optional;
Answer is mandatory;

UAS is the resumer of suspended session, so:
A UAS that is not capable of unilaterally meeting all of the
   mandatory preconditions MUST include a confirm-status attribute in
   the SDP (offer or answer) that it sends (see Section 7).

If UAC do not conf the UAS，UAC could never see the Precondition OK by 
SDP.

So, it can be that UAS see the Precondition OK, but UAC do not.

Then, after 4xx of Re-INVITE, UAS's "in use" media is the one after 
Re-INVITE.
And UAC's "in use" media is the one before Re-INVITE.

Some people may say that UAS could send 180 after its Precondition OK. But 
it is optional for Re-INVITE.
And if 180 is not 100rel, no one can assure UAC would recv it.

2. the derived problem

If the situation mentioned above is possible, there are something derived 
from it:

o If UAC do not conf the UAS, UAC have some cases can see the Precondition 
OK by SDP:
If the UAS conf UAC, UAC will send UPDATE, and at that time UAS is OK.

o UAC have some cases can see 180. And this is signal of resuming. 

o Time of 4xx, before Precondition OK or not.

The indeterminacy of such situation would make UA's session parameters 
uncertain.
From user's view, with/without precondition; having or having no 180; Time 
of 4xx would make session parameters uncertain.
It will be a puzzle for them.

2009-02-27 00:20

收件人

Hi,

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 27 Feb 2009 09:09:05 +0200

Hi,

> 1. Make session state just out of signal control.

no, we are not specifying any new rules about how to control the media
state. To decide the media state in use at any given point, we are just
 using the traditional rules we use to control media. No new rules here.
Therefore, your point above is not valid.

> 2. Is the session state the one user prefer?

we need to decide what will be the default media state after the
re-INVITE fails. The idea is that we define a default behavior that is
in line with what the user prefers *most of the time*. Obviously, there
will be cases where the user prefers something else because the default
behavior cannot possibly cover all cases. In those cases where the user
prefers something else, the user can issue a new re-INVITE or UPDATE.

> If A want to use vedio, and B reject it. But A and B can use vedio and 
> say that they have rejected using it by signal, and operater can not 
> bill it.

If B rejects the video stream the operator should not be charging for it
because there is no video stream to charge for.

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 15:28:13 +0800

comments in inline

2009-02-27 15:09

收件人

Hi,

[Gao] I think it is violation of RFC3261, which has the semantics of 
rejecting.

[Gao]  Issue a new re-INVITE or UPDATE, would have the drawback I 
mentioned.
That is manual rollback called in folk.

[Gao] But A and B can still using it illegal.

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 15:35:30 +0800

As admit Precondition as nested transaction overlap more than one 
Offer/Answer pair.

Then, let's concentrate on the main branching: Late commitment of 
Re-INVITE 200OK.

Is it needful.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 27 Feb 2009 09:37:38 +0200

Hi,

> [Gao] I think it is violation of RFC3261, which has the semantics of 

we cannot violate any RFC because we are not specifying *any* new rules
for media control.

> That is manual rollback called in folk.

As I said in the paragraph above, we need to find a solution that does
not require a new re-INVITE or UPDATE most of the time. However, when
the user preferences are not the default, there is no way around it. You
will need the new offer/answer exchange.

> [Gao] But A and B can still using it illegal.

if a stream is rejected, it will not be in use. We do not indent to
change that rule anywhere.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 27 Feb 2009 09:50:42 +0200

Hi,

> 1. the situation of inconsistent media level(perhaps it is impossible)

there is a situation we need to clarify regarding how to configure the
endpoint's media tools at a given point. However, this is a general
issue, not specific to the rollback issue we are discussing here. We
discussed this issue a long time ago but clarifying it at this point may
be a good idea. The issue is the following:

Two endpoints involved in a session perform a successful offer/answer
exchange in a re-INVITE or in an UPDATE to change the media parameters.
When can the endpoints stop using the old parameters and start using the
new parameters? This synchronization-related issue is caused by the fact
that signalling and media are only loosely coupled. The typical answer
is that the endpoint stops using the old media parameters (e.g., stop
listening on the old port) when it starts receiving media with the new
parameters. Of course, the endpoint can also implement a timer to cope
with delayed media packets using the old parameters.

When preconditions are used, the period where the endpoint acting as the
UAC needs to be prepared to receive media with both the old and the new
parameters is longer because once its preconditions are met, the UAS may
take a while to meet its own preconditions. In any case, the solution is
the same. The UAC stops using the old configuration when it starts
receiving media with the new configuration. The UAC can also request
confirmation of the preconditions so that the UAS lets the UAC know when

In any case, as you can see, this is a general SIP issue on
signalling-media synchronization, not specific to the rollback issue we
are discussing here.

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 15:51:13 +0800

2009-02-27 15:37

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

Hi,

[Gao] RFC3261:
If a UA receives a non-2xx final response to a re-INVITE, the session
   parameters MUST remain unchanged, as if no re-INVITE had been issued.

However, the
   failure of the re-INVITE does not cause the existing call to fail -
   the session continues using the previously negotiated
   characteristics. 

[Gao] Why think after 4xx, the "most" case is that user prefer to using 
the media negotiated in Re-INVITE.
I think rejecting is the "most" case.
But this is subjective branching :).

[Gao] I think the usage should be restricted by signaling, while not end 
users' consciousness. :)

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 27 Feb 2009 09:55:40 +0200

Hi,

>    the session continues using the previously negotiated

yes, as I explained in my original email, the consensus in the WG has
been that we are willing to lose this atomicity property. It is a
tradeoff between keeping that property and doing the right thing.

> But this is subjective branching :).

the assumption we are working on is that the user would prefer that the
failure of the re-INVITE does not trigger a sudden media change. That
is, the media session would continue unchanged when the 4xx for the
re-INVITE arrives.

> [Gao] I think the usage should be restricted by signaling, while not end 

We are talking about signalling here.

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 15:59:10 +0800

Current definition of "in use" is the one proposed by Holmberg yesterday:

But as the two sides can have different view of when "preconditions are 
met". The problem is still exist.

What I talked here is just signaling concerned. And I admit that combine 
with the "signalling-media synchronization", it will be more complex.

2009-02-27 15:50

收件人
[email-masked]
抄送
[email-masked], [email-masked]
主题
Re: [Sipping] Closing the offer/answer rollback issue //discussion: the 
situation of inconsistent media level

Hi,

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 27 Feb 2009 10:08:11 +0200

Hi,

> Current definition of "in use" is the one proposed by Holmberg yesterday:

no, we are discussing the proposal in my original email. As I have said
before, the idea is to have focused discussions without jumping from
topic to topic before resolving any of them.

In any case, so far we have not found any requirement that would not be
met by the straw-man proposal in my original email. If we do not find
any soon, we will be making a decision shortly.

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 16:18:44 +0800

2009-02-27 15:55

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

Hi,

[Gao] If there's no elegant way, I also would have agreed "Committed by 
Offer/Answer" or "manual rollback".
But I think I the nested transaction concept is really important here.
I am happy to see that the nested transaction concept of Precondition is 
admitted here.
But I still think that "Late commitment of Re-INVITE 200OK" is also 
important, and it just obeys the concept in RFC3261.

[Gao] The modification triggered by Re-INVITE will go on after failure of 
Re-INVITE, disregarding the signalling.
If it is really most of the people's preference, I accept it.

[Gao] Yes. The session state is clear. But I just want to reveal the 
hidden trouble of "illegal use media".

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 16:22:45 +0800

OK. Then there is no definition of "in use" at all.

2009-02-27 16:08

收件人
[email-masked]
抄送
[email-masked], [email-masked]
主题
Re: 答复: Re: [Sipping] Closing the offer/answer rollback issue 
//discussion: the situation of inconsistent media level

Hi,

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 16:33:13 +0800

Dear Gonzalo Camarillo

And I think:

1. the situation of inconsistent media level

2. illegal of media use

3. violation of session continuity

Still exist.

And talking about "the situation of inconsistent media level", I just talk 
the session state can be inconsistent from two sides.
But you think it is "signalling-media synchronization" issue. I do not 
think it is.

And talking "illegal of media use", you restrcited me talking media level 
usage.

And talking "violation of session continuity", you think it is not the 
most case.

Gao

收件人
[email-masked]
抄送

Hi,

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 27 Feb 2009 10:40:24 +0200

Hi,

I have already addressed your concerns on the three points below in this
email thread. If you think something is not completely or properly
addressed, explain it or provide an example. Going in circles and
discussing again what we have already discussed would be pointless.

Thanks,

Gonzalo

[email-masked] wrote:
> And talking about "the situation of inconsistent media level", I just 
> talk the session state can be inconsistent from two sides.
> And talking "illegal of media use", you restrcited me talking media 
> level usage.
>

---

From: [email-masked]
Date: Fri, 27 Feb 2009 16:57:38 +0800

UAC              UAS

Offer is optional;
Answer is mandatory;

Then, after 4xx of Re-INVITE, UAS's "in use" media is the one after 
Re-INVITE. In your examle, that is:
audio stream: audio codec 2
video stream: video codec 2 (subject to preconditions OK)

And UAC's "in use" media is the one before Re-INVITE.
audio stream: audio codec 2
video stream: video codec 1 (subject to preconditions is not OK)

You tell me yesterday:
If you could provide a valid example, it would help us understand
if there is a problem here.

I think it is. Do you think it is? YES/NO

2. illegal of media use
It is a real problem, no matter in signalling level what the state should 
be.
I want to ask could end user using the session parameters?  YES/NO

3. violation of session continuity
It is a real problem. Do you think so? YES/NO
And the accessorial is that is it the most case?
I know your answer. 

2009-02-27 16:40

收件人
[email-masked]
抄送

Hi,

Thanks,

Gonzalo

system.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 27 Feb 2009 11:06:44 +0200

Hi,

1) I just sent you an email about our point 1 below explaining you the
general issue in SIP and discussing its implication. I will not repeat
the same arguments here.

2) On your point 2 below, nothing that has not been negotiated at the
signalling level can be used. Therefore, endpoints will not be able to
use media illegally.

3) I already answered your point 3 below in a previous email. Session
continuity is achieved by continuing using the session parameters
currently in use when the re-INVITE fails.

Thanks,

Gonzalo

[email-masked] wrote:
> If UAC do not conf the UAS，UAC could never see the Precondition OK by SDP.
> 
> parameters in use, it would be a *bigger problem* than the issue we are
> It is a real problem, no matter in signalling level what the state 
> should be.
> 	Re: 答复: Re: 答复: Re: [Sipping] Closing the offer/answer rollback 
> issue //discussion: the situation of inconsistent media level
> 
> 
> 	
> 
> 
> 
> 
> 
> Hi,
>

---

From: [email-masked]
Date: Fri, 27 Feb 2009 17:05:47 +0800

>is, the media session would continue unchanged when the 4xx for the

  The modification triggered by Re-INVITE will go on after failure of 
Re-INVITE, disregarding the signalling.
It's not acceptable, i believe. 

Also If pre-conditions are met,and re-INVITE fails, UEs could use the new 
SDP. 
This solution will give someone a way to escape charging. 
For example, if UEs use audio at the first time, 
then one of them raise a re-INVITE with a SDP carrying both audio and 
video, 
after the preconditions are met, then the other rejects the re-INVITE, 
but they can communicate with both audio and video after all.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 27 Feb 2009 11:10:57 +0200

Hi,

> Also If pre-conditions are met,and re-INVITE fails, UEs could use the 
> new SDP.

No, if they negotiate video and the preconditions are met, they will be 
charged for video, regardless of what happens with the re-INVITE.

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 17:24:09 +0800

2009-02-27 17:06

收件人
[email-masked]
抄送

Hi,

I prefer to think that our discussion is friendly, everything is just 
becasue of different thoughtway :).

[Gao] Is it a real case without violation of current RFCs? YES/NO is 
enough.

[Gao] I just said the situation two sides have successful media 
modification, then user rejected.
With precondition, it is alway so.
And by your proposal, the parameters is useful. Why say it "nothing can be 
used".

[Gao] User just rejected it. And the way as your proposal is to issue a 
new Re-INVITE or UPDATE.
If it is using Re-INVITE, and the other side need user permition, so 
during the time, use can not using the parameters they prefer.

As your saying, the original parameters user rejected is useable now. But 
it is what user just rejected.
So, from user's view, it is violation. Do you think so.

I do not prefer to explain to user the interval media clip in modification 
rejecting (if the way accepted by IETF).

Thanks,

Gonzalo

SDP.

system.

---

From: [email-masked]
Date: Fri, 27 Feb 2009 17:24:32 +0800

Hi Gonzalo Camarillo,

  If UE-A wants to communicate with UE-B by video, but UE-B only want to 
communicate by audio.
and if they uses the new SDP, when pre-conditions met, UE-B will send 
his/her videos regardless
of UE-B's willing.
  And if UE-B never send his video although the pre-conditions are met, 
then UE-A will be puzzled why 
he/she is charged for vedio while receiving NO vedio from UE-B.

  I think this is a operational problem that we have to solve too.

regards,
Eric

2009-02-27 17:10

收件人
[email-masked]
抄送
[email-masked], [email-masked], [email-masked], 
[email-masked]
主题
Re: ??: Re: [Sipping] ??: Re:  ??: Re: ??: Re: ??: Re: ??: Re: ??: Re: 
Closing the offer/answer rollback issue

Hi,

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 17:26:22 +0800

My proposal is on  January 8, 2009, not yesterday, so I think it should be 
considered here. :)

And we have talked it in the SIIPPING mail list for more than one month.

sipping                                                           Y. Gao
Internet-Draft                                                       ZTE
Intended status: Standards Track                         January 8, 2009
Expires: July 12, 2009

                     The Criterion of Session State
          draft-gaoyang-sipping-session-state-criterion-00.txt

收件人
[email-masked]
抄送

Hi,

Thanks,

Gonzalo

SDP.

system.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 27 Feb 2009 11:29:01 +0200

Hi,

> becasue of different thoughtway :).

who said this was an unfriendly discussion? :o)

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 27 Feb 2009 11:30:20 +0200

Hi,

>   If UE-A wants to communicate with UE-B by video, but UE-B only want to 

then UE-B rejects the video stream and the video stream is never
established.

Cheers,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 27 Feb 2009 10:31:26 +0100

Hi,
 
If preconditions are met for the video stream, but UE-B then decideds that he doesn't want to video, an alternative to "late commitment" is for UE-B to send a new re-INVITE/offer to UE-A and remove the video.
 
Regards,
 
Christer

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 27, 2009 11:25 AM
To: Gonzalo Camarillo
Cc: Christer Holmberg; [email-masked]; [email-masked]; [email-masked]
Subject: 答复: Re: ??: Re: [Sipping] ??: Re: ??: Re: ??: Re: ??: Re: ??: Re: ??: Re: Closing the offer/answer rollback issue

Hi Gonzalo Camarillo, 

  If UE-A wants to communicate with UE-B by video, but UE-B only want to communicate by audio. 
and if they uses the new SDP, when pre-conditions met, UE-B will send his/her videos regardless 
of UE-B's willing. 
  And if UE-B never send his video although the pre-conditions are met, then UE-A will be puzzled why 
he/she is charged for vedio while receiving NO vedio from UE-B. 

regards, 
Eric 

2009-02-27 17:10 

收件人
[email-masked] 
抄送
[email-masked], [email-masked], [email-masked], [email-masked] 
主题
Re: ??: Re: [Sipping] ??: Re:  ??: Re: ??: Re: ??: Re: ??: Re: ??: Re:  Closing the offer/answer rollback issue

Hi,

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 17:44:51 +0800

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.

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,

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 17:48:31 +0800

Dear Christer,

  I think , the additional re-INVITE will solve the problem
But as UE-B has rejected the re-INVITE obviously by 4xx,  he/she doesn't 
need to send the addtional re-INVITE.

Regards,
Eric

2009-02-27 17:31

收件人
<[email-masked]>, "Gonzalo Camarillo" 
<[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 preconditions are met for the video stream, but UE-B then decideds that 
he doesn't want to video, an alternative to "late commitment" is for UE-B 
to send a new re-INVITE/offer to UE-A and remove the video.
 
Regards,
 
Christer

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 27, 2009 11:25 AM
To: Gonzalo Camarillo
Cc: Christer Holmberg; [email-masked]; [email-masked]; 
[email-masked]
Subject: 答复: Re: ??: Re: [Sipping] ??: Re: ??: Re: ??: Re: ??: Re: ??: 
Re: ??: Re: Closing the offer/answer rollback issue

Hi Gonzalo Camarillo, 

regards, 
Eric 

收件人
[email-masked] 
抄送

Hi,

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 17:55:30 +0800

If B do not do so, then A and B can use it illegal. That's what I said 
times :)

I think it is a important drawback for operating network.

收件人

Hi,

Regards,
 
Christer

Hi Gonzalo Camarillo, 

regards, 
Eric 

收件人
[email-masked] 
抄送

Hi,

Cheers,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 27 Feb 2009 11:02:42 +0100

Hi,

>If B do not do so, then A and B can use it illegal. That's what I said times :)  
 
I am not sure I understand...
 
If B doesn't want to use video, he should remove it (no matter how it is done). 
 
If he doesn't remove it, it will be used, charged for etc. I don't know what is "illegal" by that. 
 
Regards,
 
Christer 

2009-02-27 17:31 

收件人
<[email-masked]>, "Gonzalo Camarillo" <[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, 

Regards, 
  
Christer 

Hi Gonzalo Camarillo, 

regards, 
Eric 

2009-02-27 17:10 

收件人
[email-masked] 
抄送

Hi,

Cheers,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 27 Feb 2009 11:04:46 +0100

Hi,

>But as UE-B has rejected the re-INVITE obviously by 4xx,  he/she doesn't need to send the addtional re-INVITE.  
 
Well, THAT is the main issue we are discussion now, isn't it? Ie does the re-INVITE error response have an impact on the negotiated SDP (with preconditions met) or not.
 
Regards,
 
Christer

2009-02-27 17:31 

收件人

Hi, 

Regards, 
  
Christer 

Hi Gonzalo Camarillo, 

regards, 
Eric 

2009-02-27 17:10 

收件人
[email-masked] 
抄送

Hi,

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 18:06:39 +0800

I just mean that B can pretend to reject the adding vedio modification 
request. But A and B use vedio after the rejecting 4xx.

That is yhe illegal situation.

2009-02-27 18:02

收件人
<[email-masked]>
抄送
"Gonzalo Camarillo" <[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

Hi,

times :)  

If B doesn't want to use video, he should remove it (no matter how it is 
done). 
 
If he doesn't remove it, it will be used, charged for etc. I don't know 
what is "illegal" by that. 
 
Regards,
 
Christer 

收件人

Hi, 

Regards, 
  
Christer 

Hi Gonzalo Camarillo, 

regards, 
Eric 

收件人
[email-masked] 
抄送

Hi,

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 18:08:50 +0800

What's the meaning of Ie( Ie does)

=================================
 高扬/固网软件开发一部/中心研究院/中兴通讯
 Tel    : 87211
 MSN    : [email-masked]
 e_mail : [email-masked]
 Addr   :南京市雨花台区紫荆花路68号 210012
===================================

2009-02-27 18:04

收件人
<[email-masked]>, <[email-masked]>
抄送
<[email-masked]>, "Gonzalo Camarillo" 
<[email-masked]>, <[email-masked]>, 
<[email-masked]>
主题
RE: RE: Re: ??: Re: [Sipping] ??: Re:  ??: Re: ??: Re: ??: Re: ??: Re: ??: 
Re:  Closing the offer/answer rollback issue

Hi,

Well, THAT is the main issue we are discussion now, isn't it? Ie does the 
re-INVITE error response have an impact on the negotiated SDP (with 
preconditions met) or not.
 
Regards,
 
Christer

收件人

Hi, 

Regards, 
  
Christer 

Hi Gonzalo Camarillo, 

regards, 
Eric 

收件人
[email-masked] 
抄送

Hi,

Cheers,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 27 Feb 2009 11:10:42 +0100

"In other words"
 
...or something like that :) I guess it should be I.e.

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 27, 2009 12:09 PM
To: Christer Holmberg
Cc: [email-masked]; Gonzalo Camarillo; [email-masked]; [email-masked]; [email-masked]
Subject: 答复: RE: RE: Re: ??: Re: [Sipping] ??: Re: ??: Re: ??: Re: ??: Re: ??: Re: ??: Re: Closing the offer/answer rollback issue

2009-02-27 18:04 

收件人
<[email-masked]>, <[email-masked]> 
抄送
<[email-masked]>, "Gonzalo Camarillo" <[email-masked]>, <[email-masked]>, <[email-masked]> 
主题
RE: RE: Re: ??: Re: [Sipping] ??: Re:  ??: Re: ??: Re: ??: Re: ??: Re: ??: Re:  Closing the offer/answer rollback issue

Hi, 

  
Regards, 
  
Christer 

2009-02-27 17:31 

收件人

Hi, 

Regards, 
 
Christer 

Hi Gonzalo Camarillo, 

regards, 
Eric 

2009-02-27 17:10 

收件人
[email-masked] 
抄送

Hi,

Cheers,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 27 Feb 2009 11:13:46 +0100

So, what is the difference if the video is rejected using a re-INVITE error response, or a new SDP offer? 
 
If users use other codecs than have been negotiated in the SDP I think is out of the scope of this discussion.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, February 27, 2009 12:07 PM
To: Christer Holmberg
Cc: [email-masked]; [email-masked]; Gonzalo Camarillo
Subject: [Sipping] 答复: RE: RE: Re: ??: Re: ??: Re: ??: Re: ??: Re: ??: Re: ??: Re: ??: Re: Closing the offer/answer rollback issue

I just mean that B can pretend to reject the adding vedio modification request. But A and B use vedio after the rejecting 4xx. 

2009-02-27 18:02 

收件人
<[email-masked]> 
抄送
"Gonzalo Camarillo" <[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

Hi, 

  

Regards, 
  
Christer 

2009-02-27 17:31 

收件人

Hi, 

Regards, 
 
Christer 

Hi Gonzalo Camarillo, 

regards, 
Eric 

2009-02-27 17:10 

收件人
[email-masked] 
抄送

Hi,

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 18:16:03 +0800

I see, hehe(in chinese it means just as :))

2009-02-27 18:10

收件人
<[email-masked]>
抄送
<[email-masked]>, "Gonzalo Camarillo" 
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>
主题
RE: RE: RE: Re: ??: Re: [Sipping] ??: Re:  ??: Re: ??: Re: ??: Re: ??: Re: 
??: Re:  Closing the offer/answer rollback issue

"In other words"

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 27, 2009 12:09 PM
To: Christer Holmberg
Cc: [email-masked]; Gonzalo Camarillo; [email-masked]; 
[email-masked]; [email-masked]
Subject: 答复: RE: RE: Re: ??: Re: [Sipping] ??: Re: ??: Re: ??: Re: ??: 
Re: ??: Re: ??: Re: Closing the offer/answer rollback issue

收件人

Hi, 

  
Regards, 
  
Christer 

收件人

Hi, 

Regards, 
 
Christer 

Hi Gonzalo Camarillo, 

And if UE-B never send his video although the pre-conditions are met, then 
UE-A will be puzzled why 

regards, 
Eric 

收件人
[email-masked] 
抄送

Hi,

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 27 Feb 2009 12:22:39 +0200

Hi,

UEB would have rejected the video stream in the 183 response.

Gonzalo

[email-masked] wrote:
> 	Re: 答复: Re: ??: Re: [Sipping] ??: Re:  ??: Re: ??: Re: ??: Re: ??:

---

From: [email-masked]
Date: Fri, 27 Feb 2009 18:30:02 +0800

2009-02-27 18:13

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>, "Gonzalo Camarillo" 
<[email-masked]>
主题
RE: [Sipping] 答复: RE: RE: Re: ??: Re:  ??: Re:  ??: Re: ??: Re: ??: Re: 
??: Re: ??: Re:  Closing the offer/answer rollback issue

So, what is the difference if the video is rejected using a re-INVITE 
error response, or a new SDP offer? 

The difference is that:

"Late commitment", if user reject it, any mid-box knows the modification 
should be discarded. And the two sides have no way to use it anymore.
And everything is clear.

"If in use, let it alone", if user reject it, any mid-box let the 
modification alone. And the two sides can use it (illegal).
And you may say the mid-box can close the gate. Then which case should be 
close? I think the classfication would be the same as (which case 
should)rollback.

If users use other codecs than have been negotiated in the SDP I think is 
out of the scope of this discussion.

Subject: [Sipping] 答复: RE: RE: Re: ??: Re: ??: Re: ??: Re: ??: Re: ??: 

收件人
<[email-masked]> 
抄送

Hi, 

times :)   

  
  
Regards, 
  
Christer 

收件人

Hi, 

Regards, 
 
Christer 

Hi Gonzalo Camarillo, 

regards, 
Eric 

收件人
[email-masked] 
抄送

Hi,

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 18:32:15 +0800

Yes. I think it is can, not MUST.

And with precondition, the user can be hinted the new modification just 
after Offer/Answer pairs.

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

Hi,

Gonzalo

system.

---

From: Eric wang <[email-masked]>
Date: Fri, 27 Feb 2009 18:42:17 +0800

hi,

  If the sdp is negotiated , there maybe a "MRFC" to allow the caller and
callee only can use
the nogotiated codecs and disable the un-negotiated ones, and UEs cannot use
other codecs.
There must be ways to solve this problem as we distinguish the
successful negotiation from
fail ones.
 But if we consider the sdp ,whose precondition is ok but rejected at last,
as successful negotiation,
then it's hard to find a way to solve the illegal communications.

Eric

2009/2/27, Christer Holmberg <[email-masked]>:
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of [email-masked]
> *Sent:* Friday, February 27, 2009 12:07 PM
> *To:* Christer Holmberg
> *Cc:* [email-masked]; [email-masked]; Gonzalo Camarillo
> *Subject:* [Sipping] 答复: RE: RE: Re: ??: Re: ??: Re: ??: Re: ??: Re: ??:
>   *"Christer Holmberg" <[email-masked]>*
>
> 2009-02-27 18:02
>    收件人
> <[email-masked]>  抄送
> <[email-masked]>, <[email-masked]>  主题
>   *"Christer Holmberg" <[email-masked]>*
>
> 2009-02-27 17:31
>
>   收件人
> <[email-masked]>, "Gonzalo Camarillo" <
> [email-masked]>  抄送
> <[email-masked]>, <[email-masked]>, <[email-masked]>  主题
> he doesn't want to video, an alternative to "late commitment" is for UE-B to
> send a new re-INVITE/offer to UE-A and remove the video.
>
> Regards,
>
> Christer
>
> ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *
> Sent:* Friday, February 27, 2009 11:25 AM*
> To:* Gonzalo Camarillo*
> Cc:* Christer Holmberg; [email-masked]; [email-masked];
> [email-masked]*
> Subject:* 答复: Re: ??: Re: [Sipping] ??: Re: ??: Re: ??: Re: ??: Re: ??:
> [email-masked]  抄送
> [email-masked]  主题
> are not permitted to disclose the contents of this communication to others.
> 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.
> are not permitted to disclose the contents of this communication to others.
> 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: Gonzalo Camarillo <[email-masked]>
Date: Fri, 27 Feb 2009 12:38:14 +0200

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:
> 	Re: 答复: Re: 答复: Re: ??: Re: [Sipping] ??: Re:  ??: Re: ??: Re: ??:

---

From: [email-masked]
Date: Fri, 27 Feb 2009 18:45:49 +0800

Some personal attitudes:

In my mind, signalling is the thing we use to control media level.
But if we give up it: while user rejected a new modification, we wait for 
the user(or UA automatical) itself to send the Re-INVITE to make the 
session into the state the user once(the once means the user have show the 
rejecting desire) prefer.

And in fact, after some times of modification, the user itself can not 
know how to rebuild it. And after rejecting, the user will ask "Where is 
the original session", if he can not rebulit it. Some rich media usage, 
can be especially having this problem.

收件人
<[email-masked]>
抄送

收件人
<[email-masked]> 
抄送

Hi, 

times :)   

  
  
Regards, 
  
Christer 

收件人

Hi, 

Regards, 
 
Christer 

Hi Gonzalo Camarillo, 

regards, 
Eric 

收件人
[email-masked] 
抄送

Hi,

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 18:49:34 +0800

You are at home now?

I think "MRFC" what you mentioned is the RACS like one.

I guess :)

Eric wang <[email-masked]> 
2009-02-27 18:42

收件人
Christer Holmberg <[email-masked]>
抄送
[email-masked], [email-masked], [email-masked], Gonzalo 
Camarillo <[email-masked]>
主题
Re: [Sipping] 答复: RE: RE: Re: ??: Re: ??: Re: ??: Re: ??: Re: ??: Re: 
??: Re: ??: Re: Closing the offer/answer rollback issue

hi,
 
  If the sdp is negotiated , there maybe a "MRFC" to allow the caller and 
callee only can use 
the nogotiated codecs and disable the un-negotiated ones, and UEs cannot 
use other codecs.
There must be ways to solve this problem as we distinguish the successful 
negotiation from 
fail ones.
 But if we consider the sdp ,whose precondition is ok but rejected at 
last, as successful negotiation,
then it's hard to find a way to solve the illegal communications.
 
Eric

收件人
<[email-masked]> 
抄送

Hi, 

times :)   

  
  
Regards, 
  
Christer 

收件人
[email-masked]> 

Hi, 

Regards, 
 
Christer 

Hi Gonzalo Camarillo, 

regards, 
Eric 

收件人
[email-masked] 
抄送

Hi,

Cheers,

Gonzalo

---

From: Eric wang <[email-masked]>
Date: Fri, 27 Feb 2009 18:55:00 +0800

hi,

Yes. I'm home now.
RACS is right ,I forget the name and use MRFC "MEDIA CONTROL FUNCTION"
instead:)

Eric

2009/2/27, [email-masked] <[email-masked]>:
>   *Eric wang <[email-masked]>*
>
> 2009-02-27 18:42
>    收件人
> Christer Holmberg <[email-masked]>  抄送
> Camarillo <[email-masked]>  主题
> Re: [Sipping] 答复: RE: RE: Re: ??: Re: ??: Re: ??: Re: ??: Re: ??: Re: ??:
> 2009/2/27, Christer Holmberg <[email-masked]*<[email-masked]>>:
>
> *From:* [email-masked]* <[email-masked]> [mailto:*
> [email-masked]* <[email-masked]>] *On Behalf Of **
> [email-masked]* <[email-masked]>*
> Sent:* Friday, February 27, 2009 12:07 PM*
> To:* Christer Holmberg*
> Cc:* [email-masked]* <[email-masked]>; *
> [email-masked]* <[email-masked]>; Gonzalo Camarillo*
> Subject:* [Sipping] 答复: RE: RE: Re: ??: Re: ??: Re: ??: Re: ??: Re: ??:
>   *"Christer Holmberg" <[email-masked]*<[email-masked]>
> *>*
>
> 2009-02-27 18:02
>
>   收件人
> <[email-masked]* <[email-masked]>>  抄送
> "Gonzalo Camarillo" <[email-masked]*<[email-masked]>>,
> <[email-masked]* <[email-masked]>>, <[email-masked]*<[email-masked]>>,
> <[email-masked]* <[email-masked]>>  主题
>   *"Christer Holmberg" <[email-masked]*<[email-masked]>
> *>*
>
> 2009-02-27 17:31
>
>   收件人
> <[email-masked]* <[email-masked]>>, "Gonzalo Camarillo" <*
> [email-masked]* <[email-masked]>>  抄送
> <[email-masked]* <[email-masked]>>, <[email-masked]*<[email-masked]>>,
> <[email-masked]* <[email-masked]>>  主题
> *
> From:* [email-masked]* <[email-masked]> [mailto:*
> [email-masked]* <[email-masked]>] *
> Cc:* Christer Holmberg; [email-masked]* <[email-masked]>; *
> [email-masked]* <[email-masked]>; [email-masked]*<[email-masked]>
> *
>   *Gonzalo Camarillo <[email-masked]*<[email-masked]>
> *>*
>
> 2009-02-27 17:10
>
>   收件人
> [email-masked]* <[email-masked]>  抄送
> [email-masked]* <[email-masked]>, *
> [email-masked]* <[email-masked]>, [email-masked]*<[email-masked]>,
> [email-masked]* <[email-masked]>  主题
> Sipping mailing list  *https://www.ietf.org/mailman/listinfo/sipping*<https://www.ietf.org/mailman/listinfo/sipping>
> Use [email-masked]* <[email-masked]>for questions on current sip
> Use [email-masked]* <[email-masked]> for new developments of core SIP
>
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 27 Feb 2009 11:57:31 +0100

If UE-B does not want to use video, he would have to send a new SDP offer, where video is removed. Mid-boxes etc would then remove the video.
 
If UE-B does not remove the video, he will be charged for it etc. There is nothing "illegal" about that.

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 27, 2009 12:30 PM
To: Christer Holmberg
Cc: Gonzalo Camarillo; [email-masked]; [email-masked]
Subject: 答复: RE: [Sipping] 答复: RE: RE: Re: ??: Re: ??: Re: ??: Re: ??: Re: ??: Re: ??: Re: ??: Re: Closing the offer/answer rollback issue

2009-02-27 18:13 

收件人
<[email-masked]> 
抄送
<[email-masked]>, <[email-masked]>, "Gonzalo Camarillo" <[email-masked]> 
主题
RE: [Sipping] 答复: RE: RE: Re: ??: Re:  ??: Re:  ??: Re: ??: Re: ??: Re: ??: Re: ??: Re:  Closing the offer/answer rollback issue

The difference is that: 

"Late commitment", if user reject it, any mid-box knows the modification should be discarded. And the two sides have no way to use it anymore. 
And everything is clear. 

"If in use, let it alone", if user reject it, any mid-box let the modification alone. And the two sides can use it (illegal). 
And you may say the mid-box can close the gate. Then which case should be close? I think the classfication would be the same as (which case should)rollback. 

2009-02-27 18:02 

收件人
<[email-masked]> 
抄送

 
Hi, 

 

Regards, 
 
Christer 

2009-02-27 17:31 

收件人

Hi, 

Regards, 

Christer 

Hi Gonzalo Camarillo, 

regards, 
Eric 

2009-02-27 17:10 

收件人
[email-masked] 
抄送

Hi,

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 18:57:59 +0800

I am not sure media synchronization you mentioned is the same as I talked.

I said two:

1. some precondition case, UAC and UAS can have inconsistent session 
state.

2. we let the session state user rejected alone, and can be illegal used.

And I really want to know why solution in my draft without considering. It 
is on January 8, 2009

2009-02-27 18:38

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

Hi,

Thanks for your input,

Gonzalo

[email-masked] wrote:
>  >                  Re: 答复: Re: ??: Re: [Sipping] ??: Re:  ??: Re: ??: 

> Re: ??: Re: ??:

system.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 27 Feb 2009 13:01:49 +0200

Hi,

> *And I really want to know why solution in my draft without considering. 

we have had a huge thread considering and discussing those issues. If by
considering you mean accepting whatever you propose discarding WG
consensus, then that is impossible.

Thanks,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 19:00:52 +0800

If the new Re-INVITE is mandatory one, it is OK from the solution itself.

But I think it is heavy one :)

As there is light one, why not.

2009-02-27 18:57

收件人
<[email-masked]>
抄送
"Gonzalo Camarillo" <[email-masked]>, <[email-masked]>, 
<[email-masked]>
主题
RE: RE: [Sipping] 答复: RE: RE: Re: ??: Re:  ??: Re:  ??: Re: ??: Re: ??: 
Re: ??: Re: ??: Re:  Closing the offer/answer rollback issue

If UE-B does not want to use video, he would have to send a new SDP offer, 
where video is removed. Mid-boxes etc would then remove the video.
 
If UE-B does not remove the video, he will be charged for it etc. There is 
nothing "illegal" about that.

Subject: 答复: RE: [Sipping] 答复: RE: RE: Re: ??: Re: ??: Re: ??: Re: ??: 

收件人
<[email-masked]> 
抄送

The difference is that: 

收件人
<[email-masked]> 
抄送

Hi, 

times :)   

 
 
Regards, 
 
Christer 

收件人

Hi, 

Regards, 

Christer 

Hi Gonzalo Camarillo, 

regards, 
Eric 

收件人
[email-masked] 
抄送

Hi,

Cheers,

Gonzalo

---

From: [email-masked]
Date: Fri, 27 Feb 2009 19:17:33 +0800

I did not see any discussion of "in use" proposal (including the 
Archives).

There was just Holmberg's "commit by Offer/Answer"(Mutli-O/A was not 
discussed further).

3GPP is waiting. But I think we should collect every meaningful proposal.

And I think, it should be public as draft.

If adding my way is so painful, I prefer to stop talking here!

2009-02-27 19:01

收件人
[email-masked]
抄送
[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked]
主题
Re: [Sipping] ??: Re:  ??: Re: ??: Re: ??: Re: ??: Re: ??: Re:  Closing 
the offer/answer rollback issue

Hi,

Thanks,

Gonzalo

---

From: Tom Taylor <[email-masked]>
Date: Fri, 27 Feb 2009 16:43:18 -0500

I'm still reading this lengthy stream of messages, but I can see point being
made. It's like the old system of ringing home when you have successfully
completed a flight, with the understanding that your wife will get the message
of safe arrival but not pick up the phone and get charged for it. So similarly
the two users could agree (with the help of UAs containing hacked software) to
exchange SDP, reject the addition of video at the signalling level, then carry
on with video anyway.

The service provider obviously has to protect its interests by monitoring the
media streams being exchanged.There's nothing you can do at the SIP level to
defend against deliberate violation of the semantics of the protocol.

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 27 Feb 2009 21:00:44 +0100

Hi,

>I did not see any discussion of "in use" proposal (including the Archives).  
> 
>There was just Holmberg's "commit by Offer/Answer"(Mutli-O/A was not discussed further). 
> 
 
3GPP is not waiting, because we already informed them about the current agreement. 

>And I think, it should be public as draft.  
 
The agreement is that there will be an "essential correction" draft which, corrects whatever text/RFC that needs to be fixed, based on the agreed outcome.
 
Regards,
 
Christer 

2009-02-27 19:01 

收件人
[email-masked] 
抄送
[email-masked], [email-masked], [email-masked], [email-masked], [email-masked] 
主题
Re: [Sipping] ??: Re:  ??: Re: ??: Re: ??: Re: ??: Re: ??: Re:  Closing the offer/answer rollback issue

Hi,

Thanks,

Gonzalo

---

From: gaoyang <[email-masked]>
Date: Sat, 28 Feb 2009 02:24:44 +0000

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

_________________________________________________________________
MSN安全保护中心，免费修复系统漏洞，保护MSN安全！
http://im.live.cn/safe/

---

From: [email-masked]
Date: Sat, 28 Feb 2009 16:09:33 +0800

hi，

 This two cases are different.
 
 The first case,as they never communicate with each other, the service 
provider has no reason to charge,
 but the second case, they truely communicate by vedio,and there are rules 
to let service provider 
 determine whether to charge for vedio.

Tom Taylor <[email-masked]> 
发件人:  [email-masked]
2009-02-28 05:43

收件人
[email-masked]
抄送
[email-masked], Gonzalo Camarillo <[email-masked]>, 
Christer Holmberg <[email-masked]>
主题
Re: [Sipping] 答复: RE: RE: Re: ??: Re:  ??: Re:  ??: Re: ??: Re: ??: Re: 
??: Re: ??: Re:  Closing the offer/answer rollback issue

I'm still reading this lengthy stream of messages, but I can see point 
being
made. It's like the old system of ringing home when you have successfully
completed a flight, with the understanding that your wife will get the 
message
of safe arrival but not pick up the phone and get charged for it. So 
similarly
the two users could agree (with the help of UAs containing hacked 
software) to
exchange SDP, reject the addition of video at the signalling level, then 
carry
on with video anyway.

The service provider obviously has to protect its interests by monitoring 
the
media streams being exchanged.There's nothing you can do at the SIP level 
to
defend against deliberate violation of the semantics of the protocol.

> Gonzalo Camarillo <[email-masked]> 
is 

> This email and any files transmitted with it are confidential and 
intended 

> This message has been scanned for viruses and Spam by ZTE Anti-Spam 
is 

> This email and any files transmitted with it are confidential and 
intended 

system.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 28 Feb 2009 10:25:31 -0500

Is there an email in this long thread that summarizes the issues?
It's impossible to follow this thread. :)

I'm not clear on what the issues are with pre-conditions that make failed offers concept break.  To me, pre-conditions are basically not real SDP offers; they're conditional offers.  Until the *all* the conditions are met, it's not "committed".  You continue using the last committed state.  I know there are race conditions, but considering how rare pre-conditions are in the real world (especially in re-Invite's), that I'm having trouble imagining why we should care about corner cases of such.  Regardless, I vote for any fixing that needs to happen because of pre-conditions should be around changing pre-condition logic, even if it means completely re-writing how pre-conditions works - don't change normal SIP or SDP. (not that anyone is proposing it, I just can't tell form this thread)

Re-Invites and SDP offer/answer have so many interop issues in the wild even without pre-conditions, that this whole thread scares me. :(

-hadriel

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 28 Feb 2009 20:54:22 +0200

Hi Hadriel,

as I stated in one of the emails in that thread, I will be summarizing 
the whole thread as soon as I have a minute. I do not expect folks to 
read and follow the whole thread :o)

Cheers,

Gonzalo

> Re-Invites and SDP offer/answer have so many interop issues in the wild even without pre-conditions, that this whole thread scares me. :(

Date: Tue, 03 Feb 2009 20:13:01 +0000
From: "Elwell, John" <[email-masked]>
To: Salvatore Loreto <[email-masked]>, Paul Kyzivat <[email-masked]>
Content-class: urn:content-classes:message
Cc: SIPPING <[email-masked]>
Subject: Re: [Sipping] Commentsondraft-loreto-sipping-context-id-requirements-00

Sal,

It should be possible to express requirements without referring to
dialogs. Any reference to dialogs seems to make some assumption about
solution.

John

> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Salvatore Loreto
> Sent: 03 February 2009 20:03
> To: Paul Kyzivat
> Cc: SIPPING; Elwell, John
> Subject: Re: [Sipping]=20
> Commentsondraft-loreto-sipping-context-id-requirements-00
>=20
> <snip>
> >>> Req A:  It must be possible, when establishing a dialog,=20
> to specify=20
> >>> that
> >>> it be correlated with one or more already existing dialogs, which
> >>> dialogs, at the time they were created, did not need to=20
> specify that
> >>> they might be correlated with in the future.
> >> [JRE] I don't think this is a valid requirement, because it has a
> >> particular class of solutions in mind. In my opinion the basic
> >> requirement should be something along the lines of "It=20
> must be possible
> >> to establish, modify and clear down a multimedia session=20
> between two
> >> parties, one or both of which use different devices for different
> >> media."
> >>
> >> John
> >
> > I agree with John.
> >
> >     Paul
> I agree on the fact that the requirements have to be as=20
> general as possible.
> In fact if you read my mail "Correlate sip sessions/dialogs"=20
> you can see
> we have already have two requirements that are similar=20
> (almost equal) to=20
> the one suggested by John.
>=20
> The requirement in this mail was about the possibility to create the=20
> initial dialog without knowing
> in advance whether another dialog will want to correlate with it.
> We can generalize it:
>=20
> "It must be possible to create a dialog without knowing in advance=20
> whether or not
> another dialog will want to correlate with it"
>=20
> Maybe it is a redundant  requirement  but at this stage there are =20
> people that think it should be specified.
>=20
> Sal
>=20

Date: Wed, 4 Feb 2009 12:18:18 +1100
From: Hisham Khartabil <[email-masked]>
To: [email-masked]
Subject: [Sipping] Comments on draft-niemi-sipping-event-throttle-07.txt

--000e0cd29a5214208904620d908d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

- Section 3 talks about presence, location and tracking applications. I was
confused reading those sections the first time thinking the presence
application sits on the server. Can you replace the word "application" with
"client"? As a suggestion, I would say the whoel document needs to be
updated with this suggestion

- Section 3.2 talks about filters. A reference is needed to filters RFC.
Also, more text is needed around how this Force extention overrides a filter
criteria and why would someone set a filter only to override it with a
Force.

- Figure 1 needs to be modified to show how filters are affected

- Section 4.3: Need to expand on how the client can reject the notifier's
adjusted intervals?

- I think its a good idea to talk about how a notifier can suggest to the
client the throttling mechanism and throttle interval without the client
asking for it. At least the draft can talk about how if a notifier has a
policy to limit notifications according to admin throttling settings, those
can/cannot be applied without the client requesting them. That's something
that we need to decide, although it is difficult to mandate that a notifier
cannot apply throttles unless it is asked to do so.

- "average" I dont understand what that is? is it the average interval
between notifications sent so far? How is that value decided? is average the
wrong word to use here. More explanation is needed.

Regards,
Hisham

--000e0cd29a5214208904620d908d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>- Section 3 talks about presence, location and tracking applications. =
I was confused reading those sections the first time thinking the presence =
application sits on the server. Can you replace the word &quot;application&=
quot; with &quot;client&quot;? As a suggestion, I would say the whoel docum=
ent needs to be updated with this suggestion</div>

<div>&nbsp;</div>
<div>- Section 3.2 talks about filters. A reference is needed to filters RF=
C. Also, more text is needed around how this Force extention overrides a fi=
lter criteria and why would someone set a filter only to override it with a=
 Force.</div>

<div>&nbsp;</div>
<div>- Figure 1 needs to be modified to show how filters are affected</div>
<div>&nbsp;</div>
<div>- Section 4.3: Need to expand on how the client can reject the notifie=
r&#39;s adjusted intervals?</div>
<div>&nbsp;</div>
<div>- I think its a good idea to talk about how a notifier can suggest to =
the client the throttling mechanism and throttle interval without the clien=
t asking for it. At least the draft can talk about how if a notifier has a =
policy to limit notifications according to admin&nbsp;throttling settings, =
those can/cannot be applied without the client requesting them. That&#39;s =
something that we need to decide, although it is difficult to mandate that =
a notifier cannot apply throttles unless it is asked to do so.</div>

<div>&nbsp;</div>
<div>- &quot;average&quot; I dont understand what that is? is it the averag=
e interval between notifications sent so far? How is that value decided? is=
 average the wrong word to use here. More explanation is needed.</div>

<div>&nbsp;</div>
<div>Regards,</div>
<div>Hisham</div>

--000e0cd29a5214208904620d908d--

Content-class: urn:content-classes:message
Date: Wed, 4 Feb 2009 11:44:08 +0100
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sipping] Correlate sip sessions/dialogs

Hi Sal,

Here my opinion on your proposals. =20

	>=20
	> My proposal here is to keep, in the merged document, distinct=20
	> this two=20
	> requirements as they seems to be semantically different.
	> I propose to have a set of requirements for "media session=20
	> correlation"=20
	> and a set of requirements for "dialog correlation".
	> Please comment!

I  agree with your proposal. I suppose using the same identifier for
both "media session=20
 correlation"  and "dialog correlation" could lead to failures. =20

	>=20
	>=20
	> One second issue, that it is IMO common, is to discuss and
decide=20
	> whether we can create the initial dialog without knowing
	> in advance whether another dialog will want to correlate with=20
	> it (as I=20
	> think we should)//
	>=20
	>     Req A: It must be possible, when establishing a dialog,=20
	> to specify that
	>     it be correlated with one or more already existing
dialogs, which
	>     dialogs, at the time they were created, did not need to=20
	> specify that
	>     they might be correlated with in the future.

I agreee. We have to consider older end devices which will not support
the new extension.=20
It must be possible to correlate dialogs with dialogs already
established by these older devices.=20
It is a necessary requirement at least for "dialog correlation", but I
think it make sense as a common requirement.=20
It would add flexibility to the mechanism.=20
 =20
>=20
>=20
	> Please comment, if you think this requirement can be
considered in=20
	> common or not.
	>=20
	> then draft [3] there is a requirement related to=20
	> out-of-dialog request,=20
	> that I don't know (I don't have a strong
	> opinion on it) if we can be consider in common or not:
	>=20
	>    REQ[3].2: It must be possible for a SIP device to use the=20
	> identifier in=20
	>    out-of-dialog requests, to match existing dialogs at=20
	> B2BUA's and/or=20
	>    UAS's, if the Call-ID and tags the device believes are
correct do=20
	>    not in fact match, with as high a probability as possible.=20

I don't have an opinion about this.=20

regards
laura

Date: Wed, 04 Feb 2009 15:58:43 +0200
From: Salvatore Loreto <[email-masked]>
To: "Elwell, John" <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>, SIPPING <[email-masked]>
Subject: Re: [Sipping] Commentsondraft-loreto-sipping-context-id-requirements-00

John,

as you can read on the "Correlate sip sessions/dialogs" mail thread we 
are trying to merge in one draft
all the different requirements currently spread in three drafts.
In that draft we will have two separate set of requirements one for 
"media session correlation" and another
for "dialog correlation".
So it could be hard not to refer to dialogs at all.

However as I said we will do our best to make the requirement as general 
as possible

Sal

Elwell, John wrote:
> Sal,
>
> It should be possible to express requirements without referring to
> dialogs. Any reference to dialogs seems to make some assumption about
> solution.
>
> John
>
>   
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Salvatore Loreto
>> Sent: 03 February 2009 20:03
>> To: Paul Kyzivat
>> Cc: SIPPING; Elwell, John
>> Subject: Re: [Sipping] 
>> Commentsondraft-loreto-sipping-context-id-requirements-00
>>
>> <snip>
>>     
>>>>> Req A:  It must be possible, when establishing a dialog, 
>>>>>           
>> to specify 
>>     
>>>>> that
>>>>> it be correlated with one or more already existing dialogs, which
>>>>> dialogs, at the time they were created, did not need to 
>>>>>           
>> specify that
>>     
>>>>> they might be correlated with in the future.
>>>>>           
>>>> [JRE] I don't think this is a valid requirement, because it has a
>>>> particular class of solutions in mind. In my opinion the basic
>>>> requirement should be something along the lines of "It 
>>>>         
>> must be possible
>>     
>>>> to establish, modify and clear down a multimedia session 
>>>>         
>> between two
>>     
>>>> parties, one or both of which use different devices for different
>>>> media."
>>>>
>>>> John
>>>>         
>>> I agree with John.
>>>
>>>     Paul
>>>       
>> I agree on the fact that the requirements have to be as 
>> general as possible.
>> In fact if you read my mail "Correlate sip sessions/dialogs" 
>> you can see
>> we have already have two requirements that are similar 
>> (almost equal) to 
>> the one suggested by John.
>>
>> The requirement in this mail was about the possibility to create the 
>> initial dialog without knowing
>> in advance whether another dialog will want to correlate with it.
>> We can generalize it:
>>
>> "It must be possible to create a dialog without knowing in advance 
>> whether or not
>> another dialog will want to correlate with it"
>>
>> Maybe it is a redundant  requirement  but at this stage there are  
>> people that think it should be specified.
>>
>> Sal

From: "Glen Zorn" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Tue, 3 Feb 2009 13:08:00 +0700
Organization: Network Zen
Cc: [email-masked], [email-masked], 'Glen Zorn' <[email-masked]>
Subject: Re: [Sipping] I-D Action:draft-gurbani-sipping-clf-00.txt

A possibly stupid question: is there some reason why this couldn't/shouldn't
be done w/syslog?

> From: [email-masked] [mailto:i-d-announce-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, February 03, 2009 2:15 AM
> To: [email-masked]
> Subject: I-D Action:draft-gurbani-sipping-clf-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 	Title           : The Common Log File (CLF) format for the
> Session Initiation Protocol (SIP)
> 	Author(s)       : V. Gurbani, et al.
> 	Filename        : draft-gurbani-sipping-clf-00.txt
> 	Pages           : 17
> 	Date            : 2009-02-02
> 
> Well-known web servers such as Apache and web proxies like Squid
> support event logging using a common log format.  The logs produced
> using these de-facto standard formats are invaluable to system
> administrators for trouble-shooting a server and tool writers to craft
> tools that mine the log files and produce reports and trends.
> Furthermore, these log files can also be used to train anomaly
> detection systems and feed events into a security event management
> system.  The Session Initiation Protocol does not have a common log
> format, and as a result, each server supports a distinct log format
> that makes it unnecessarily complex to produce tools to do trend
> analysis and security detection.  We propose a common log file format
> for SIP servers that can be used uniformly for proxies, registrars,
> redirect servers as well as back-to-back user agents.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-gurbani-sipping-clf-00.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.

From: "Dale Worley" <[email-masked]>
To: "Vijay K. Gurbani" <[email-masked]>
Organization: Nortel Networks
Date: Wed, 04 Feb 2009 16:25:16 -0500
Cc: sipping <[email-masked]>
Subject: Re: [Sipping] SIP CLF Format

On Mon, 2009-02-02 at 16:39 -0600, Vijay K. Gurbani wrote: 
> > - What exactly are the events that are logged?  E.g., section 4.1.2 
> > refers to a "method event", which is a phrase I've never heard 
> > before. Does it refer to SIP requests?
> 
> Ah, yes; another good catch.  Method event refers to SIP requests.
> I will make this more clear in a subsequent revision.

It would help if you replace "method" with "request" throughout, since
"method" seems to be normally used to refer to only the method specified
in a request, not the request as a whole.

> > In which case, does it mean the *reception* of a SIP request or the
> > *sending* of a SIP request? Or is the intention to log the
> > request/response pair as one line (as would make sense in an HTTP
> > server, but less sense in a SIP proxy that implements forking)?
> 
> For SIP proxies you cannot log the request/response pair in one
> line. That is where S4.2 comes in. The directives in S4.2
> allow the representation of a [request] arriving at a proxy as 
> well as departing from the proxy (or B2BUA).

That makes sense, but I don't see a statement up front saying "one CLF
line is generated upon the receipt of each SIP message (request or
response) and one CLF is generated upon the transmission of each SIP
message".  One has to deduce from various examples that these are the
events that generate CLF lines.

I am assuming here that all provisional responses (received and sent)
are to be logged.

But perhaps I am running up against a philosophical problem -- Is the
intention to log SIP *messages*, or to log *transactions*?  In the
former case, it's unambiguous what events generate log lines and what
the lines mean.  But in the latter case, much more care needs to be
taken to specify what is logged and when, as there isn't a one-to-one
correspondence between SIP events (transmission and receipt of messages)
and transactions.

I suspect the intention is that for UAS transactions, you want CLF to
log transactions (and thus always fold the transmitted response into the
received request), but that for UAC transactions, and the server/client
transactions of proxies/B2BUAs, you want to log each sent and received
message separately.

The idea of using one line to give both request and response data is
natural for an HTTP server, where both happen at nearly the same moment.
But in SIP, in at least half its actions, even a UA will be a client,
where the request and response may be separated by a substantial time.

> > - In regard to the remotehost (%h) field, does "upstream" mean (as it
> >  usually does) "the source if the request that initiated this 
> > processing"?  
> 
> Yes.
> 
> > In which case, there seems to be no place to identify 
> > the host/address to which an outgoing request is sent, or the 
> > host/address from which an incoming response is received (since that 
> > is a "downstream" host).
> 
> That is captured in S4.2.  The entity to which a request is
> sent downstream is identified by the R-URI (see top of page
> 13.)  I agree this is a bit hard to follow until you sit down
> and work it out, but that is the nature of the complexity.
> Any suggestions to make it less complex would be greatly
> welcome.

The entity to which a request is sent downstream is not reliably
identified by the R-URI, due to all the rules in RFC 3263.  (Consider an
element sending a request sequentially to several different resolutions
of the R-URI in attempt to find a server that is functioning.)  Given
our experience with sipX, I would strongly recommend that the triple
"transport/host IP address/port" be logged for all sent messages.
Otherwise CLF will be useless for diagnosing routing actions at the RFC
3263 level.

> > - Some care needs to be taken to describe how CANCEL and ACK are 
> > logged. (E.g., ACK for success and ACK for failure *might* be logged 
> > differently -- what is intended?)  This need is discussed in section 
> > 1, but I don't see clear prescriptions of what is to be done.
> 
> There is an example in S4.1.4; CANCEL is discussed in detail
> there.  Regarding ACK for 2xx and ACK for non-2xx, I believe
> that they ought to be logged similarly but the interpretation of
> them is different (i.e., the automata reading the CLF file will
> trigger different states based on whether or not the ACK is
> for a 2xx or non-2xx.)

I think you've got the right idea, but I would much prefer that clear
specifications be laid out in addition to the examples.

> > - Are the "..." around %c really necessary?  Or is that a legacy of 
> > the Apache format?  (And if so, does the Apache format allow %c to 
> > contain spaces?  How does that affect the identification of fields?)
> 
> Apache, of course, does not have a "%c"; it does, however, have
> a "%r", which represents the request line as it comes in from
> a browser.  The Apache CLF encloses this in a pair of braces
> since the "%r" represents three different tokens in Apache:
> the method (GET), the resource (/index.html) and the protocol
> version ("HTTP/1.0").
> 
> "%c" for SIP CLF was put in braces just to include any LWS (and
> I will probably have to look at this in more detail as the work
> moved ahead.)

(I assume you mean "quotes" there.)

Though it doesn't seem that %c can contain whitespace, since it is a
comma-separated list of URIs, or else is "-".  

I also notice that despite that %c is always enclosed in quotes, if
there are not contacts, %c is represented by a single hyphen, which
would appear as quote-hyphen-quote in a CLF line.  It would be more
uniform to turn "%c" to "", and the fields could still be parsed.  Even
better, eliminate the quotes entirely, and use hyphen if there are no
contacts.

But it doesn't look like %c is the contact URIs, but rather the contact
name-addrs, based on the second example in section 4.1.4.  In that case,
there is a lot more trouble, because a name-addr can contain a quote.

Consider the particularly ugly example:

Contact: <sip:[email-masked]>;param=" value1 value2 "

Embedded into the second example of section 4.1.4:

1230756560 192.168.1.2 alice REGISTER sip:example.com sip:[email-masked];tag=iu8u76 sip:[email-masked];tag=yh78 [email-masked] 200 "<sip:[email-masked]>;param=" value1 value2 "" serverid -

(I hope that comes through OK.)  A parser that looks for the end of the
quote-%c-quote field by looking for quote-space will stop after
";param=", and will take "value1" as the server transaction id and
"value2" as the client transaction id, whereas the real server
transaction id is "serverid".

> > - What are the extension mechanisms (other than additional fields at 
> > the ends of the two line formats)?  Is there any way to identify 
> > which software version generated a particular log file, so that the 
> > reader can unambiguously determine how to interpret the extension 
> > fields?
> 
> Excellent question.  There isn't a versioning system for the
> SIP CLF itself; however, the extension mechanism is rather
> simple: you can include any other field you want besides the
> fields that constitute the CLF.  We do not restrict this,
> subject to the discussion in S5 (Security Considerations.)
> Of course, what we want to standardize are the fields we
> have listed and in the order that we have listed them in.
> These constitute the canonical definition of a "SIP CLF".
> Implementations are free to add other fields as long as they
> provide/maintain updated SIP CLF parsers.

But there is no way for a CLF parser that supports extensions to
determine which extensions are present, other than heuristically.
Maybe that this is particularly important.  Perhaps we could require
that extensions start with a field formatted "token[" and end with a
field "]", so a parser could identify the start, end, and type of each
extension without specific knowledge of all extensions?

> > - Why is the to-URI (%t) present in the response format?  It's 
> > redundant with the same information in the corresponding request 
> > format.  And if we want such redundant information, why not provide 
> > %f as well?
> 
> There is a discussion of this in S4.1.3.  Should we embellish
> the discussion in there some more?

Given that %x and %y are present in response lines, and those identify
the other requests/responses in the transaction, and indirectly the
dialog, why is the to-tag (in %t) needed?

Looking at %x and %y, the server and client transaction identifiers, I
see six cases:

Line for message                %x                      %y

Incoming requests (server)      server trans id         -
or                              server trans id         FORK/-

Outgoing responses (server)     server trans id         -
or                              server trans id         FORK/-

Outgoing requests (client)      server trans id         CLIENT/client trans id

Incoming responses (client)     server trans id         CLIENT/client trans id

Based on this, it seems like the "FORK/" and "CLIENT/" are redundant,
and %y could be defined as "'-' for server transactions and the
transaction identifier for client transactions".

Also, the definitions given in 4.1.1 aren't quite correct.  E.g., one
example shows a REGISTER server transaction with no server transaction
id given (because the transmitted response is folded into the same CLF
line that logs the request), but the description of %x doesn't say that
it can be omitted in that circumstance.

Dale

From: "gaoyang" <[email-masked]>
To: <[email-masked]>
Date: Wed, 4 Feb 2009 23:08:54 +0800
Subject: [Sipping] Support "draft-gaoyang-sipping-session-state-criterion-00.txt", and some questions.

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C9871D.8D22A8B0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

------=_NextPart_000_000B_01C9871D.8D22A8B0
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

------=_NextPart_000_000B_01C9871D.8D22A8B0--

From: "gaoyang" <[email-masked]>
To: <[email-masked]>
Date: Wed, 4 Feb 2009 23:30:08 +0800
Subject: [Sipping] Fw: Support "draft-gaoyang-sipping-session-state-criterion-00.txt", and some questions.

This is a multi-part message in MIME format.

------=_NextPart_000_0035_01C98720.8441AE50
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

------=_NextPart_000_0035_01C98720.8441AE50
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

------=_NextPart_000_0035_01C98720.8441AE50--

Date: Thu, 05 Feb 2009 14:55:15 -0600
From: "Vijay K. Gurbani" <[email-masked]>
Organization: Bell Labs Security Technology Research Group
To: Dale Worley <[email-masked]>
Cc: sipping <[email-masked]>
Subject: Re: [Sipping] SIP CLF Format

Dale Worley wrote:
> It would help if you replace "method" with "request" throughout,
> since "method" seems to be normally used to refer to only the method
> specified in a request, not the request as a whole.

Dale: Sure, that is a good suggestion (and I must really thank
you for going through the draft with a fine toothcomb.  More inline.)

> That makes sense, but I don't see a statement up front saying "one
> CLF line is generated upon the receipt of each SIP message (request
> or response) and one CLF is generated upon the transmission of each
> SIP message".  One has to deduce from various examples that these are
> the events that generate CLF lines.

Hmm ... our operating model was that a CLF generated by
UASes (i.e., not proxies or proxy-like B2BUAs) will result in one
line that contains all the necessary information elements (including
the response.  This, of course means, that for an INVITE, the
UAS may not generate a CLF until a final response is sent out;
and a UAC may not generate a CLF until a final response is
received.)

Practically, this means that a UAC that received multiple
provisional responses for an INVITE will not log these individually,
and a UAS that sends multiple provisional responses for an
INVITE will not log these individually.  I think it is a safe
bet to go this route and reduce some complexity when a CLF
for a UAC or UAS is being produced.  What do others think?

> I am assuming here that all provisional responses (received and sent)
>  are to be logged.

For a proxy or proxy-like B2BUA, yes; all provisionals are
logged, as are all final responses received in case of forking.

> But perhaps I am running up against a philosophical problem -- Is the
>  intention to log SIP *messages*, or to log *transactions*?  In the

Ah, good question.  Our intent was that for UAC and UAS, we will
log *messages*.  Because a proxy (or a proxy-like B2BUA) is a
transactional entity, and because such an entity may not know
the exact nature of the response until some transformation on
the request has been made, they have to be *transactional*
entities.

> The idea of using one line to give both request and response data is 
> natural for an HTTP server, where both happen at nearly the same
> moment. But in SIP, in at least half its actions, even a UA will be a
> client, where the request and response may be separated by a
> substantial time.

Right; but this is true only for the INVITE request; it is this
request that is allowed to pend in SIP.  The remaining requests
elicit a quick final response; thus for UAS and UAC, it makes sense
to use one line for the request and response (and take a bit of a
hit in form of a delay for the INVITE request.)

> The entity to which a request is sent downstream is not reliably 
> identified by the R-URI, due to all the rules in RFC 3263.

True, and it gets even murkier than this when you consider that
the topmost Route -- if present -- is used to route the requests,
thereby by-passing the R-URI completely.   But regardless, we
felt that logging the R-URI is sufficient since it demonstrates
the intent of where the request was destined to.  Presumably
to figure out the problem you mention below ...

> (Consider an element sending a request sequentially to several
> different resolutions of the R-URI in attempt to find a server that
> is functioning.)  Given our experience with sipX, I would strongly
> recommend that the triple "transport/host IP address/port" be logged
> for all sent messages. Otherwise CLF will be useless for diagnosing
> routing actions at the RFC 3263 level.

there would be some other debugging hooks in the code.  In other
words, I don't think that it is fruitful to turn the CLF in a
debugging aid.  What do you think?  Other opinions?

> But it doesn't look like %c is the contact URIs, but rather the
> contact name-addrs, based on the second example in section 4.1.4.  In
> that case, there is a lot more trouble, because a name-addr can
> contain a quote.
> 
> Consider the particularly ugly example:
> 
> Contact: <sip:[email-masked]>;param=" value1 value2 "

Hmmm ... yes, you are right.  One way would be to use other
symbols in the CLF to delimit %c.  [ and ] come to mind.

> But there is no way for a CLF parser that supports extensions to 
> determine which extensions are present, other than heuristically. 
> Maybe that this is particularly important.  Perhaps we could require 
> that extensions start with a field formatted "token[" and end with a 
> field "]", so a parser could identify the start, end, and type of
> each extension without specific knowledge of all extensions?

If it is deemed that adding other fields to the CLF is required,
and that a off-the-shelf CLF parser should not choke on these
fields, then we could certainly do what you suggest.  I would
go further and say that such "extensions" should appear after
the the normal CLF fields have taken up their positions on a
line.

> Given that %x and %y are present in response lines, and those
> identify the other requests/responses in the transaction, and
> indirectly the dialog, why is the to-tag (in %t) needed?

Because it may not be the case that the To-tag has been set
when the provisional response is sent out.  Thus we cannot
always depend on the To-tag being part of the request CLF
line if the request CLF line only contains a provisional.

> Looking at %x and %y, the server and client transaction identifiers,
> I see six cases:
[...]
> Based on this, it seems like the "FORK/" and "CLIENT/" are redundant,
> and %y could be defined as "'-' for server transactions and the 
> transaction identifier for client transactions".

I believe that retaining FORK and CLIENT directive make the intent
apparent for a human reader.  The syntax, if not the intent, of
these are modeled after the Squid web proxy CLF format.

> Also, the definitions given in 4.1.1 aren't quite correct.  E.g., one
> example shows a REGISTER server transaction with no server
> transaction id given (because the transmitted response is folded into
> the same CLF line that logs the request), but the description of %x
> doesn't say that it can be omitted in that circumstance.

OK ... we can tighten up the text to say that %x can be omitted
if the final response is on the request-CLF line.

Thanks, once again, Dale for your thorough read-through.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

From: "Dale Worley" <[email-masked]>
To: "Vijay K. Gurbani" <[email-masked]>
Organization: Nortel Networks
Date: Thu, 05 Feb 2009 16:02:27 -0500
Cc: sipping <[email-masked]>
Subject: Re: [Sipping] SIP CLF Format

On Thu, 2009-02-05 at 14:55 -0600, Vijay K. Gurbani wrote:
> Ah, good question.  Our intent was that for UAC and UAS, we will
> log *messages*.

I'm getting confused here.  You say that you want to log messages, which
means that requests and responses would be logged separately.  But in
other places you talk about using one log line to represent both the
request and the response.

> Right; but this is true only for the INVITE request; it is this
> request that is allowed to pend in SIP.  The remaining requests
> elicit a quick final response; thus for UAS and UAC, it makes sense
> to use one line for the request and response (and take a bit of a
> hit in form of a delay for the INVITE request.)

Non-INVITE requests are *supposed* to elicit a quick final response, but
there are many circumstances when they don't -- especially transport
errors requiring fallback.

> In other
> words, I don't think that it is fruitful to turn the CLF in a
> debugging aid.  What do you think?  Other opinions?

Then what is its purpose?

> > Consider the particularly ugly example:
> > 
> > Contact: <sip:[email-masked]>;param=" value1 value2 "
> 
> Hmmm ... yes, you are right.  One way would be to use other
> symbols in the CLF to delimit %c.  [ and ] come to mind.

All printable ASCII characters can appear in a field-parameter.

> > Given that %x and %y are present in response lines, and those
> > identify the other requests/responses in the transaction, and
> > indirectly the dialog, why is the to-tag (in %t) needed?
> 
> Because it may not be the case that the To-tag has been set
> when the provisional response is sent out.  Thus we cannot
> always depend on the To-tag being part of the request CLF
> line if the request CLF line only contains a provisional.

Good point.

Dale

Date: Thu, 05 Feb 2009 16:56:18 -0600
From: "Vijay K. Gurbani" <[email-masked]>
Organization: Bell Labs Security Technology Research Group
To: Dale Worley <[email-masked]>
Cc: sipping <[email-masked]>
Subject: Re: [Sipping] SIP CLF Format

Dale Worley wrote:
> I'm getting confused here.  You say that you want to log messages, which
> means that requests and responses would be logged separately.  But in
> other places you talk about using one log line to represent both the
> request and the response.

That is because, given how SIP works, for a proxy we simply do
not have the luxury of using the same line to log a request
and a response.

>> In other
>> words, I don't think that it is fruitful to turn the CLF in a
>> debugging aid.  What do you think?  Other opinions?
> 
> Then what is its purpose?

It's purpose is much the same as the Apache CLF format: it is
not used as much to debug as it is used for trend analysis and
anomaly detection.

>>> Consider the particularly ugly example:
>>>
>>> Contact: <sip:[email-masked]>;param=" value1 value2 "
>> Hmmm ... yes, you are right.  One way would be to use other
>> symbols in the CLF to delimit %c.  [ and ] come to mind.
> 
> All printable ASCII characters can appear in a field-parameter.

Sigh -- yes, true.  Something else needs to be thought about
here.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

From: "Dale Worley" <[email-masked]>
To: SIPPING <[email-masked]>
Organization: Nortel Networks
Date: Thu, 05 Feb 2009 17:13:07 -0500
Subject: [Sipping] Comments on draft-niemi-sipping-event-throttle-07.txt

--=-TvMQYbiqojDBYv0v6f2Q
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

The concept is interesting.  I think that the draft could be improved in
some ways:

- The names of the parameters are not so easy to remember.  I would
suggest "min", "max", and "average".

- More thought probably needs to be put into the real algorithm, which
accommodates possibly having all 3 parameters set, as well as various
subsets.

- I expect it would be useful to have more explicit language specifying
how the subscriber requests particular parameters, how the notifier
agrees or not to those values, how they get un-set, etc.  It seems that
a request/response negotiation is expected, and there are a lot of grey
areas, but I think it would help to explicate the possibilities.

- Similarly, language should be added to make it clear that the notifier
SHOULD do what is asked, and the subscriber needs to be prepared for
behavior much different from what is asked.

- In regard to averaging, it turns out that you can make a spreadsheet
to apply the average rule.  For example, the attached spreadsheet (if it
comes through), is the case:  average = 10 sec, period = 100 sec, an
initial event at 0 sec.  The graph panel shows the successive timeout
values.  You can change the average and period values and the
spreadsheet will update the results.

- A little fiddling suggests that setting period to 10*average gives
good results -- the timeout values quickly converge to the desired
interval.  Plugging that into the formula of section 6.2 gives

timeout = average * (count of notifications in last 10*average) / 10

- Brian Rosen suggests a moving average instead of the interval-count.
But an easier formula to implement is an exponential-smoothing formula:

timeout =
     (1 + alpha - beta) * (last timeout value)
     - alpha * (interval since last notification)
     + beta * average

That has the same general properties -- if a stimulated event causes the
interval since the last notification to be small, it increases timeout
for the next few notifications.  But it requires remembering only two
numbers about the past:  the last timeout and the time of the last
notification.

Dale

--=-TvMQYbiqojDBYv0v6f2Q
Content-Disposition: attachment; filename=tick.xls
Content-Type: application/vnd.ms-excel; name=tick.xls
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAACAAAA/gAAAAAAAAAA
EAAASgAAAAEAAAD+////AAAAAAAAAACAAAAA////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////hkUA////////////////////////////////AP//
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////AAAA////AAAA////////////////////////////////////////////////////
////////////////AAAA////AAAA////////AAAA////AAAAAAAA////AAAA////AAAA////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//8AAAAAAAD///8AAAD/////////////////////////////////////////////////////////
//////8AAAAAAAD///8AAAD///8AAAD///8AAAAAAAD///8AAAD///8AAAD/////////////////
//////////////8AAAD///////////8AAAD///8AAAD///8AAAD///8AAAD///////+GRQD/////
//////////////////////////8A////////////////////////////////////////////////
////AAAA////AAAAAAAAAAAAAAAA////AAAA////AAAAAAAA////AAAAAAAA////AAAA////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////+GRQD///////////////////////////////8A////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////8AAAAAAAD///8AAAD/////////////////////////////////////////////////////
//////////8AAAAAAAD///8AAAD///8AAAD///8AAAAAAAD///8AAAD///8AAAD/////////////
//////////////////////////////////////////////////////////////////////+GRQD/
//////////////////////////////8A////////////////////////////////////////////
////////AAAA////AAAA////AAAAAAAA////AAAA////AAAAAAAA////AAAAAAAA////AAAA////
////////////////////////////////////////////////////////////////////////////
////////////////////AAAAAAAA////AAAA////////////////////////////////////////
////////////////////////AAAAAAAA////AAAA////AAAA////AAAAAAAA////AAAA////AAAA
////////////////////////////////////////////////////////////////////////////
////////hkUA////////////////////////////////AP//////////////////////////////
/////////////////////wAAAAAAAAAAAP///wAAAP///////wAAAAAAAP///wAAAAAAAP///wAA
AAAAAP//////////////////////////////////////////////////////////////////////
/////////////////////////////////wAAAAAAAAAAAP//////////////////////////////
/////////////////////////////////////wAAAAAAAAAAAP///////wAAAAAAAP///wAAAAAA
AAAAAAAAAP//////////////////////////////////////////////////////////////////
/////////////////////4ZFAP///////////////////////////////wD/////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////8AAAAAAAD///8AAAD/////////////////////////////////////////////////
//////////////8AAAAAAAD///8AAAD///8AAAD///8AAAAAAAD///8AAAD///8AAAD/////////
//////////////////////////////////////////////////////////////////////////+G
RQD///////////////////////////////8A////////////////////////////////////////
////////////AAAA////AAAA////AAAA////////AAAAAAAA////AAAAAAAA////AAAAAAAA////
////////////////////////////////////////////////////////////////////////////
////////////////////////AAAAAAAAAAAA////////////////////////////////////////
////////////////////////////AAAAAAAAAAAA////////AAAAAAAA////AAAAAAAAAAAAAAAA
////////////////////////////////////////////////////////////////////////////
////////////hkUA////////////////////////////////AP//////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////4ZFAP///////////////////////////////wD/////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/wAAAAAAAP///wAAAP//////////////////////////////////////////////////////////
/////wAAAAAAAP///wAAAP///wAAAP///wAAAAAAAP///wAAAP///wAAAP//////////////////
/////////////////////////////////////////////////////////////////4ZFAP//////
/////////////////////////wD/////////////////////////////////////////////////
//8AAAD///////8AAAAAAAAAAAD///8AAAD///8AAAAAAAD///8AAAAAAAD///8AAAD/////////
////////////////////////////////////////////////////////////////////////////
//////////////8AAAAAAAD///8AAAD/////////////////////////////////////////////
//////////////////8AAAAAAAD///8AAAD///8AAAD///8AAAAAAAD///8AAAD///8AAAD/////
////////////////////////////////////////////////////////////////////////////
//+GRQD///////////////////////////////8A////////////////////////////////////
////////////////AAAA////AAAA////AAAA////////AAAAAAAA////AAAAAAAA////AAAAAAAA
////////////////////////////////////////////////////////////////////////////
////////////////////////////AAAAAAAAAAAA////////////////////////////////////
////////////////////////////////AAAAAAAAAAAA////////AAAAAAAA////AAAAAAAAAAAA
AAAA////////////////////////////////////////////AAAAAAAA////AAAA////AAAA////
AAAA////s7Ozs7OzhkUAs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7OzAP//////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////wAAAAAAAP///wAAAP//////////////////////////////////////////////////////
/////////wAAAAAAAP///wAAAP///wAAAP///wAAAAAAAP///wAAAP///wAAAP//////////////
/////////////////////////////////////////////////////////////////////4ZFAP//
/////////////////////////////wD/////////////////////////////////////////////
//////8AAAAAAAD///////8AAAD///////8AAAAAAAD///8AAAAAAAD///8AAAAAAAD/////////
////////////////////////////////////////////////////////////////////////////
//////////////////8AAAAAAAAAAAD/////////////////////////////////////////////
//////////////////////8AAAAAAAAAAAD///////8AAAAAAAD///8AAAAAAAAAAAAAAAD/////
////////////////////////////////////////////////////////////////////////////
//////+zs7OGRQD///////////////////////////8A////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////s7OzhkUA////////////////////////////AP//////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////AAAA////////////////////////////////////////////////////////////////
////////////AAAA////AAAA////AAAAAAAA////AAAA////AAAA////////////////////////
////////////////////////////////////////////////////////////s7OzhkUA////////
////////////////////AP///////////////////////////////////////////////////wAA
AP///wAAAAAAAP///////wAAAAAAAP///wAAAAAAAP///wAAAAAAAP///wAAAP//////////////
////////////////////////////////////////////////////////////////////////////
/////////////////wAAAAAAAP//////////////////////////////////////////////////
/////////////////////wAAAAAAAP///wAAAP///wAAAAAAAP///wAAAP///wAAAP//////////
/////////////////////////////////////////////////////////////////////////7Oz
s4ZFAP///////////////////////////wD/////////////////////////////////////////
//////////8AAAD///////8AAAD///8AAAD///8AAAAAAAD///8AAAAAAAD///8AAAAAAAD/////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////8AAAAAAAD/////////////////////////////////////
//////////////////////////////////8AAAAAAAD///8AAAAAAAD///8AAAAAAAAAAAAAAAD/
////////////////////////////////////////////////////////////////////////////
//////////+zs7OGRQD///////////////////////////8A////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////AAAAAAAA////////////////////////////////////////////////////////////
////////////AAAAAAAA////AAAA////AAAAAAAA////AAAA////AAAA////////////////////
////////////////////////////////////////////////////////////////s7OzhkUA////
////////////////////////AP//////////////////////////////////////////////////
/wAAAP///wAAAAAAAP///wAAAP///wAAAAAAAP///wAAAAAAAP///wAAAAAAAP//////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////wAAAAAAAP//////////////////////////////////////////////
/////////////////////////wAAAAAAAP///wAAAAAAAP///wAAAAAAAAAAAAAAAP//////////
////////////////////////////////////////////////////////////////////////////
/7Ozs4ZFAP///////////////////////////wD/////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////+zs7OGRQD///////////////////////////8A////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////AAAAAAAA////AAAA////////////////////////////////////////////////////////
////////AAAAAAAA////AAAA////AAAA////AAAAAAAA////AAAA////AAAA////////////////
////////////////////////////////////////////////////////////////////s7OzhkUA
////////////////////////////AP//////////////////////////////////////////////
/////wAAAP///wAAAAAAAP///wAAAP///wAAAAAAAP///wAAAAAAAP///wAAAAAAAP//////////
////////////////////////////////////////////////////////////////////////////
/////////////////wAAAAAAAAAAAP//////////////////////////////////////////////
/////////////////////wAAAAAAAAAAAP///////wAAAAAAAP///wAAAAAAAAAAAAAAAP//////
////////////////////////////////////////////////////////////////////////////
/////7Ozs4ZFAP///////////////////////////wD/////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////AAAAAAAAAAAA////////////////////////////////////////////////////////
////////////AAAAAAAAAAAA////////AAAAAAAA////AAAAAAAAAAAAAAAA////////////////
////////////////////////////////////////////////////////////////////////s7Oz
hkUA////////////////////////////AP//////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////7Ozs4ZFAP///////////////////////////wD/////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////AAAAAAAAAAAA////////////////////////////////////////////////////
////////////////AAAAAAAAAAAA////////AAAAAAAA////AAAAAAAAAAAAAAAA////////////
////////////////////////////////////////////////////////////////////////////
s7Oz////hkUA////////////////////////AP//////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//8AAAD///////8AAAD/////////////////////////////////////////////////////////
//////8AAAD///////8AAAD///8AAAAAAAD///8AAAAAAAAAAAAAAAD/////////////////////
//////////////////8AAAAAAAD///////8AAAAAAAAAAAAAAAAAAAAAAAAAAAD///+zs7P///+G
RQD///////////////////////8A////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////s7Oz////hkUA////////////////////////AP//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////8AAAAAAAAAAAD/////////////////////////////////////////////////////////
//////////8AAAAAAAAAAAD///////8AAAAAAAD///8AAAAAAAAAAAAAAAD/////////////////
//////////////////////////////////////////////////////////////////////+zs7P/
//+GRQD///////////////////////8A////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////7Oz
s////////4ZFAP///////////4ZFAP///wD/////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
AAAA////AAAA////////////////////////////////////////////////////////////////
////AAAA////AAAA////////AAAAAAAA////AAAAAAAAAAAAAAAA////////////////////////
////////////AAAAAAAA////AAAA////AAAA////AAAA////AAAA////AAAA////s7Oz////////
hkUA////////hkUA////////AP//////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////wAAAAAAAAAAAAAAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAP//
/7Ozs////////4ZFAP///////4ZFAP///////wD/////////////////////////////////////
//////////////////////////8AAAAAAAAAAAAAAAAAAAAAAAD///8AAAAAAAD///8AAAAAAAD/
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////s7Oz////
////hkUA////////hkUA////////AP//////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//8AAAAAAAD/////////////////////////////////////////////////////////////////
//////8AAAAAAAD///8AAAAAAAD///8AAAAAAAAAAAAAAAD/////////////////////////////
//////////////////////////////////////////////////////////+zs7P///////+GRQD/
//////+GRQD///////8A////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////s7Oz
////////hkUA////////hkUA////////AP//////////////////////////////////////////
/////////////wAAAP///////wAAAAAAAAAAAAAAAAAAAP///wAAAAAAAP///wAAAAAAAP//////
////////////////////////////////////////////////////////////////////////////
/////////////////////////wAAAAAAAP//////////////////////////////////////////
/////////////////////////////wAAAAAAAP///wAAAAAAAAAAAP///wAAAAAAAAAAAAAAAP//
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////8AAAAAAAD///////////8AAAD///8AAAD///8AAAD///8AAAD///////+zs7P/////////
//+GRQD///+GRQD///////8A////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////AAAA////AAAA////////AAAA////AAAA////AAAA////AAAAs7Ozs7Oz
s7Ozs7Ozs7Ozs7OzhkUAs7OzhkUAs7Ozs7OzAP//////////////////////////////////////
/////////////////////wAAAP///////wAAAAAAAAAAAAAAAP///wAAAAAAAP///wAAAAAAAP//
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////+zs7P/////
//////+GRQD///+GRQD///////8A////////////////////////////////////////////////
////////////AAAA////AAAAAAAAAAAAAAAAAAAA////AAAAAAAA////AAAAAAAA////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////AAAAAAAA////////////////////////////////////////////
////////////////////////////AAAAAAAAAAAAAAAAAAAA////AAAAAAAAAAAAAAAA////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////7Ozs////////////4ZF
AIZFAP///////////wD/////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////+zs7P/
//////////+GRQCGRQD///////////8A////////////////////////////////////////////
////////////////AAAA////AAAAAAAAAAAAAAAAAAAA////AAAAAAAA////AAAAAAAA////////
////////////////////////////////////////////////////////////////////////////
////////////////////////AAAAAAAA////////////////////////////////////////////
////////////////////////////AAAAAAAA////AAAAAAAAAAAA////AAAAAAAAAAAAAAAA////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////7Ozs///////////
/////4ZFAP///////////wD/////////////////////////////////////////////////////
//////////////////8AAAAAAAAAAAAAAAD///8AAAAAAAD///8AAAAAAAD/////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////8AAAD/////////////////////////////////////////////////
//////////////////////////8AAAAAAAAAAAAAAAD///8AAAAAAAAAAAAAAAD/////////////
//////////////////////8AAAD///8AAAAAAAD///8AAAD///8AAAD///8AAAD///8AAAD///+z
s7P///////////////+GRQD///////////8A////////////////////////////////////////
////////////////////////////////AAAAAAAAAAAA////AAAAAAAA////AAAAAAAA////AAAA
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////s7Oz////////////////////
////////////AP//////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////7Ozs///////
/////////////////////////wD/////////////////////////////////////////////////
//////////////////8AAAAAAAAAAAAAAAAAAAD///8AAAAAAAD///8AAAAAAAD/////////////
////////////////////////////////////////////////////////////////////////////
//////////////////8AAAAAAAD/////////////////////////////////////////////////
//////////////////////8AAAAAAAD///8AAAAAAAAAAAD///8AAAAAAAAAAAAAAAD/////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////s7Oz////////////////
////////////////AP//////////////////////////////////////////////////////////
/////////////wAAAAAAAAAAAAAAAP///wAAAAAAAP///wAAAAAAAP//////////////////////
////////////////////////////////////////////////////////////////////////////
/////////wAAAP//////////////////////////////////////////////////////////////
/////////////wAAAP///////wAAAAAAAAAAAP///wAAAAAAAAAAAAAAAP//////////////////
/////////////////////////////////////////////////////////////////////7Ozs///
/////////////////////////////wD/////////////////////////////////////////////
//////////////////////////8AAAD///8AAAD///8AAAAAAAD///8AAAAAAAD///8AAAD/////
////////////////////////////////////////////////////////////////////////////
//////////////////////////8AAAD/////////////////////////////////////////////
//////////////////////////////8AAAD///////8AAAD///8AAAAAAAD///8AAAD///8AAAD/
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////+zs7P/////////////////////////
//////8A////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////s7Oz////////////
////////////////////AP//////////////////////////////////////////////////////
/////////////wAAAAAAAAAAAAAAAAAAAP///wAAAAAAAP///wAAAAAAAP//////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////wAAAP//////////////////////////////////////////////////////
/////////////////////wAAAP///wAAAAAAAAAAAP///wAAAAAAAAAAAAAAAP//////////////
/////////////////////////////////////////////////////////////////////////7Oz
s////////////////////////////////wD/////////////////////////////////////////
//////////////////////////8AAAD///8AAAAAAAD///8AAAAAAAD///8AAAAAAAD///8AAAD/
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////8AAAAA////////////AAAA////AAAA////AAAA////AAAAAAAA////AAAAAAAAAAAA
////AAAA////AAAA////////////////////////////////////////////AAAAAAAAAAAA////
AAAAAAAA////AAAA////AAAAAAAA////////////////////////////////////////////////
////////////////////////AAAA////AAAAAAAA////AAAAAAAAAAAA////AAAA////AAAAAAAA
////AAAA////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////AAAAAAAAAAAAAAAAAAAAAP///wAAAAAAAAAAAP///wAAAAAAAP//
/wAAAAAAAAAAAP///wAAAP///wAAAAAAAP///////////////////////////////////wAAAP//
/////wAAAP///wAAAAAAAP///wAAAP///wAAAAAAAP//////////////////////////////////
/////////////////////////////////////wAAAP///wAAAAAAAP///wAAAAAAAAAAAP///wAA
AP///wAAAAAAAP///wAAAP//////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////wAAAAD///////8AAAD///////8AAAAAAAAAAAAA
AAAAAAAAAAD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/////////////////////////////
//////8AAAD///////8AAAAAAAAAAAAAAAD///8AAAAAAAAAAAAAAAD/////////////////////
//////////////////////////////////////////////////8AAAD///8AAAAAAAAAAAAAAAAA
AAAAAAD///8AAAAAAAAAAAAAAAD///8AAAD/////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////8AAAAAAAAA////////////////
////////////////////AAAA////AAAA////////////////////////////////////////////
////////////////////////AAAAAAAA////////////////////////////////AAAA////////
////////////////////////////////////////////////////////////////AAAA////////
////////////////////////////////////////////AAAA////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////AP//////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/wD/////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////8A////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////AP//////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////wD/////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////8A////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////AP//////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////wAAAAD///////////8AAAD///8AAAD///8AAAAAAAD///8AAAD///8AAAD/////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////8AAAAAAAAAAAD///8A
AAAAAAD/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////8AAAAAAAAA////////AAAAAAAAAAAA////AAAAAAAA////AAAA////AAAA
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////AAAA
AAAA////AAAAAAAA////AAAA////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////AAAAAP///wAAAP///wAAAAAAAAAAAP///wAAAAAAAAAA
AAAAAAAAAAAAAP//////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////wAAAAAAAP///wAAAAAAAP///wAAAP//////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////wAAAAAAAAAAAAD/////////////////
//////////////////////8AAAD/////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////8AAAAAAAAAAAD///8AAAAAAAD/////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////8A////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////AP//
/////////////////////////////////////////////////wAAAAAAAAAAAP//////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////wAAAAD///////////////8AAAAAAAD///////8AAAD///////8AAAAAAAD///8AAAAA
AAD/////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////8A
AAAAAAAAAAD/////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////8A////AAAAAAAA////AAAAAAAAAAAAAAAA////AAAA////AAAAAAAA
AAAA////AAAAAAAAAAAA////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////AAAAAAAA////AAAA////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////AAAAAAAAAP///////wAAAP///wAAAAAAAP///wAA
AP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////wAAAAAAAP///wAAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////wD///8AAAD/////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////8AAAAAAAAAAAD/////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////

--=-TvMQYbiqojDBYv0v6f2Q--

From: "Dale Worley" <[email-masked]>
To: "Vijay K. Gurbani" <[email-masked]>
Organization: Nortel Networks
Date: Thu, 05 Feb 2009 18:21:55 -0500
Cc: sipping <[email-masked]>
Subject: Re: [Sipping] SIP CLF Format

On Thu, 2009-02-05 at 16:56 -0600, Vijay K. Gurbani wrote:
> It's purpose is much the same as the Apache CLF format: it is
> not used as much to debug as it is used for trend analysis and
> anomaly detection.

Which means that the intended consumer of CLF is software, not humans.
In that case, I would recommend making CLF as *uniform* as possible,
which suggests that it *always* log either transactions (one line
documenting request and final response), or messages (one line for each
request and response).  Allowing two varieties increases the complexity
of the consumer.

Dale

Date: Wed, 4 Feb 2009 16:52:05 +0800 (CST)
From: wei you <[email-masked]>
To: SIPPING <[email-masked]>, [email-masked]
Subject: [Sipping] Comments on "draft-gaoyang-sipping-session-state-criterion-00.txt"

--0-1755152902-1233737525=:8108
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 8bit

I approve the points in this paper. It could avoid the dispute about the session state after unsuccessful re-INVITE, especially in precondition case in rfc 3312.

---------------------------------
  ºÃÍæºØ¿¨µÈÄã·¢£¬ÓÊÏäºØ¿¨È«ÐÂÉÏÏß£¡
--0-1755152902-1233737525=:8108
Content-Type: text/html; charset=gb2312
Content-Transfer-Encoding: 8bit

<div>I approve the points in this paper. It could avoid the dispute about the session state after unsuccessful re-INVITE, especially in precondition case in rfc 3312.</div>  <div>&nbsp;</div><p>&#32;

      <hr size=1><a href="http://cn.rd.yahoo.com/mail_cn/tagline/card/*http://card.mail.cn.yahoo.com/">  ºÃÍæºØ¿¨µÈÄã·¢£¬ÓÊÏäºØ¿¨È«ÐÂÉÏÏß£¡</a>
--0-1755152902-1233737525=:8108--

Date: Fri, 06 Feb 2009 08:53:01 -0600
From: "Vijay K. Gurbani" <[email-masked]>
Organization: Bell Labs Security Technology Research Group
To: Dale Worley <[email-masked]>
Cc: sipping <[email-masked]>
Subject: Re: [Sipping] SIP CLF Format

Dale Worley wrote:
> On Thu, 2009-02-05 at 16:56 -0600, Vijay K. Gurbani wrote:
>> It's purpose is much the same as the Apache CLF format: it is
>> not used as much to debug as it is used for trend analysis and
>> anomaly detection.
> 
> Which means that the intended consumer of CLF is software, not humans.

Dale: I will agree that the preponderance of usage will be for
automata, but it benefits the human user as well to see the CLF
entries being produced in real-time.  IT departments routinely
keep a (human) eye on the Apache CLF as a sanity check, if not
anything else.

> In that case, I would recommend making CLF as *uniform* as possible,
> which suggests that it *always* log either transactions (one line
> documenting request and final response), or messages (one line for each
> request and response). 

But this is hard to do given how SIP works.  For instance, if an
automata is being trained, it helps to have the provisional
responses being logged before a final is seen.  In the event that
we use a one line documenting request and final response, we
loose this critical piece of state machinery.  Likewise, for a
proxy that forks, representing the forked branches and their
machinations in one line is near impossible.

> Allowing two varieties increases the complexity
> of the consumer.

I do agree, but unfortunately the complexity is unavoidable
given how the protocol works.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

From: Eric Burger <[email-masked]>
To: Dale Worley <[email-masked]>, Vijay Gurbani <[email-masked]>
Date: Fri, 6 Feb 2009 09:41:04 -0500
Cc: sipping <[email-masked]>
Subject: Re: [Sipping] SIP CLF Format

--Apple-Mail-206-73510989
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Agreed.

On Feb 5, 2009, at 6:21 PM, Dale Worley wrote:

> On Thu, 2009-02-05 at 16:56 -0600, Vijay K. Gurbani wrote:
>> It's purpose is much the same as the Apache CLF format: it is
>> not used as much to debug as it is used for trend analysis and
>> anomaly detection.
>
> Which means that the intended consumer of CLF is software, not humans.
> In that case, I would recommend making CLF as *uniform* as possible,
> which suggests that it *always* log either transactions (one line
> documenting request and final response), or messages (one line for  
> each
> request and response).  Allowing two varieties increases the  
> complexity
> of the consumer.
>
> Dale
>
>

--Apple-Mail-206-73510989
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

--Apple-Mail-206-73510989--

From: "Brian Rosen" <[email-masked]>
To: "'Dale Worley'" <[email-masked]>, "'SIPPING'" <[email-masked]>
Date: Mon, 9 Feb 2009 19:26:04 -0500
Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-07.txt

I'd be okay with exponential-smoothing.  It's better than what is there.
Not quite as good as moving average.  

Brian

> Behalf Of Dale Worley
> Sent: Thursday, February 05, 2009 5:13 PM
> To: SIPPING
> Subject: [Sipping] Comments on draft-niemi-sipping-event-throttle-
> 07.txt
> 
> The concept is interesting.  I think that the draft could be improved
> in some ways:
> 
> - The names of the parameters are not so easy to remember.  I would
> suggest "min", "max", and "average".
> 
> - More thought probably needs to be put into the real algorithm, which
> accommodates possibly having all 3 parameters set, as well as various
> subsets.
> 
> - I expect it would be useful to have more explicit language specifying
> how the subscriber requests particular parameters, how the notifier
> agrees or not to those values, how they get un-set, etc.  It seems that
> a request/response negotiation is expected, and there are a lot of grey
> areas, but I think it would help to explicate the possibilities.
> 
> - Similarly, language should be added to make it clear that the
> notifier SHOULD do what is asked, and the subscriber needs to be
> prepared for behavior much different from what is asked.
> 
> - In regard to averaging, it turns out that you can make a spreadsheet
> to apply the average rule.  For example, the attached spreadsheet (if
> it comes through), is the case:  average = 10 sec, period = 100 sec, an
> initial event at 0 sec.  The graph panel shows the successive timeout
> values.  You can change the average and period values and the
> spreadsheet will update the results.
> 
> - A little fiddling suggests that setting period to 10*average gives
> good results -- the timeout values quickly converge to the desired
> interval.  Plugging that into the formula of section 6.2 gives
> 
> timeout = average * (count of notifications in last 10*average) / 10
> 
> - Brian Rosen suggests a moving average instead of the interval-count.
> But an easier formula to implement is an exponential-smoothing formula:
> 
> timeout =
>      (1 + alpha - beta) * (last timeout value)
>      - alpha * (interval since last notification)
>      + beta * average
> 
> That has the same general properties -- if a stimulated event causes
> the interval since the last notification to be small, it increases
> timeout for the next few notifications.  But it requires remembering
> only two numbers about the past:  the last timeout and the time of the
> last notification.
> 
> Dale

Content-class: urn:content-classes:message
Date: Tue, 10 Feb 2009 11:03:45 -0600
From: "Mary Barnes" <[email-masked]>
To: "IETF Sipping List" <[email-masked]>
Cc: Gonzalo Camarillo <[email-masked]>
Subject: [Sipping] SIPPING WG Status - 10 February 2009

 Hi all,=20

The spreadsheets tracking the SIPPING WG chartered items have been
updated:
http://www.softarmor.com/sipping/process/wg-review/sipping-rt.html
(sorted by Review due date - most useful for WG to know what they should
be reviewing now)=20

http://www.softarmor.com/sipping/process/wg-review/sipping-rt-rev-due.ht
ml
(sorted by revision due date - most useful for doc editors to know when
their next update is expected). =20

The milestones for many of the docs have been changed to account for
additional delays in updates post-IETF 73. I will post a summary of the
new proposed milestones shortly.

Regards,
Mary
SIPPING WG co-chair

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Docs with WG reviews completed (since Dec 4, 2008):=20
------------------------------------------------------------------------
Note: plans/status of docs is given in subsequent section

- draft-johnston-sipping-cc-uui (pre-WGLC ended on 22 Dec 2008)
Editor: Alan Johnston
Reviewers: Vijay Gurbani, Keith Drage, Laura Liess, Spencer Dawkins

- draft-ietf-sipping-presence-scaling-requirements-02 (post-WGLC ended
19 Dec 2008)
Editor: Avshalom Houri
Reviewers:  Vijay Gurbani, Jean-Francois Mule, Hisham Khartibil
(RAI/SIMPLE WG), Christian Schmidt

- draft-sinnreich-sip-tools (Expert Re-Review ended on 31 December 2008)
Editor: Henry Sinnreich
(Expert) Reviewer: Paul Kyzivat

- draft-ietf-sipping-update-pai (2nd WGLC ended on 19 Jan 2009)
Editor: John Elwell
Token: AD
Reviewers: Vijay Gurbani, Paul Kyzivat, Francois Audet, Thomas Stach
Proto: Gonzalo/Mary

- draft-niemi-sipping-event-throttle  (Pre-WGLC ended on 5 Feb 2009 )
Editor: Salvatore Loreto=20
Reviewers:  Brian Rosen, Hisham Khartabil, Dale Worley

Docs forwarded to IESG(since Dec 4):=20
--------------------------------------
- draft-andreasen-sipping-rfc3603bis  (in RFC Editor Q)=20
Editor: Fleming Andreasen
(Expert) Reviewer: Miguel Garcia
Token: AD (Cullen)
Proto: Mary

- draft-ietf-sipping-update-pai
Editor: John Elwell
Token: AD
Reviewers: Vijay Gurbani, Paul Kyzivat, Francois Audet, Thomas Stach
Proto: Gonzalo/Mary

Docs under review/discussion:
--------------------------------------------
- draft-ietf-sipping-nat-scenarios-09 (post-WGLC Review ended: 15
October 2008, extended to acct for TURN WGLC ending 27 November 2008)
Editor: Chris Boulton
Token: Reviewers to provide feedback and editor to respond to feedback
(currently remaining feedback is due from TURN experts - TURN WGLC ended
27 November)
Reviewers:  Vijay Gurbani, Francois Audet, Remi Denis-Courmant, Ali
Keranen, Jerry Yin, Dan Wing, Philip Matthews
Proto: Mary

- draft-wing-sipping-srtp-key-04 (Security directorate early review ends
31 Dec 2008)
Editor: Dan Wing
Reviewer: Eric Rescorla
Token: Reviewer to provide feedback on the specific solution proposals,
WG to provide any relevant feedback - based feedback from WG had
indicated general support for this doc
Chair prime: Gonzalo

- draft-ietf-sipping-presence-scaling-requirements-03 (post-WGLC
re-review ends on 23 Feb 2009)
Editor: Avshalom Houri
Token: Editor to ensure all post-WGLC comments are addresed and doc is
updated.=20
- Once doc is updated and reviewers are satisfie Proto write-up will be
completed and doc forwarded to AD (by 31 Dec 2008)
Reviewers:  Vijay Gurbani, Jean-Francois Mule, Hisham Khartibil
(RAI/SIMPLE WG), Christian Schmidt
Proto: Gonzalo

Doc revisions awaited:
-------------------------------------------

- draft-johnston-sipping-cc-uui (WGLC targeted for 16 Feb 2009)
Editor: Alan Johnston
Token: Editor to incorporate feedback based on pre-WGLC reviews. Update
due on or before 13 Feb 2009.=20
Reviewers: Vijay Gurbani, Keith Drage, Laura Liess, Spencer Dawkins
Proto: Gonzalo=20

- draft-ietf-sipping-profile-datasets  (Pre-WGLC review re-targeted to
start 23 February 2009, WGLC review retargeted to start 30 April 2009)
Editor: Martin Dolly and Dale Worley
Token: Editors to update doc on or before 20 Feb 2009, incorporating WG
feedback from past reviews and ML.=20
Reviewers:  Dale Worley, Jean-Luc Bakker, Andrew Hutton
Proto: Mary
Note: we need two more reviewers for this doc, including an XML schema
expert, as well as someone who is very familiar with SIP device
configuration.=20

- draft-niemi-sipping-event-throttle  (Pre-WGLC re-review targeted to
start 27 February 2009, WGLC review retargeted to start 20 April 2009)
Editor: Salvatore Loreto
Token: Editor to update doc on or before 20 Feb 2009, incorporating WG
feedback from past reviews and ML.=20
Reviewers:  Brian Rosen, Hisham Khartabil, Dale Worley
Proto: Mary
Note: WG needs to consider readiness for this doc as a WG item
considering that it was originally discussed in the WG in 2004 and got
lost (likely in the leadership transition in 2006).  It is also an OMA
dependency.=20

- draft-ietf-sipping-overload-design  (Initial Review retargeted to
start 16 March 2009, WGLC retargeted to start 23 May 2009)
Editor: Volker Hilt
Token: Editor to update doc, before 9 March 2009, based on initial
feedback and IETF-73 discussion
Reviewers:  None=20
Proto: Mary
Note: We need volunteers for this doc! We can't progress work unless we
get at least 3 comprehensive reviews, otherwise we assume no one cares

- draft-sinnreich-sip-tools=20
Editor: Henry Sinnreich
(Expert) Reviewer: Paul Kyzivat
Token: Editor to update doc based on -04 feedback
- Once reviewers are okay with doc, it will be forwarded to AD for
progression (Ind/AD).=20
Proto: Mary
Note: also captured as a RAI area review

Additional WG docs:
-----------------------------
- draft-ietf-sipping-sip-offeranswer (Doc being work post-Pub-Req to
work out solutions to problems ID'ed in section 6 - solutions will be
progressed in SIP WG and this doc updated to be a comprehensive guide. )
Editor: Paul Kyzivat
Token: Editor to update document once solutions agree in SIP WG - likely
in the latter half of 2009.
Reviewers: (Past) Byron Campen, Jonathan Rosenberg, Rajeev Seth, B.
Nataraju  - addt'l reviewers welcome.=20

Content-class: urn:content-classes:message
Date: Tue, 10 Feb 2009 11:22:53 -0700
From: "Daryl Malas" <[email-masked]>
To: "Gerald Q. Maguire Jr." <[email-masked]>
Cc: [email-masked], Al Morton <[email-masked]>, [email-masked]
Subject: [Sipping] [PMOL]  RE: draft-ietf-pmol-sip-perf-metrics-02

Gerald,

Thank you for the review and detailed feedback.  I made changes in the
draft per all of your suggestions; however, I modified some of them.
See commments in-line...

Regards,

Daryl

----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:[email-masked]
=20

> From: Gerald Q. Maguire Jr. [mailto:[email-masked]]=20
> Sent: Tuesday, November 11, 2008 9:02 AM
> To: Daryl Malas
> Subject: draft-ietf-pmol-sip-perf-metrics-02
>=20
> http://tools.ietf.org/html/draft-ietf-pmol-sip-perf-metrics-02
>=20
> When measurement results will be correlated with other results or
>    information using time-of-day stamps, then the time clock that
>    supplies T1 SHOULD be synchronized to a primary time source, to
>    minimize the time offset.
> should be:
>=20
> When measurement results will be correlated with other results or
>    information using time-of-day stamps, then the time clock that
>    supplies T1 SHOULD be synchronized to a primary time source, to
>    minimize the error in the time offset.
>=20
> This change is important as otherwise you have used "time=20
> offset" in a different meaning that you defined it in the=20
> prior paragraph.

After considering your suggestion, I modified the paragraph to read:

When measurement results will be correlated with other results or
    information using time-of-day stamps, then the time clock that
    supplies T1 SHOULD be synchronized to a primary time source, to
    minimize the error in the time offset. The time offset MUST be
    reported with each measurement.

>=20
> --
> =20
> The accuracy of the T4-T1 interval is also critical to maintain and
>    report. The relevant definition from [12=20
> <http://tools.ietf.org/html/draft-ietf-pmol-sip-perf-metrics-0
> 2#ref-12>] is "skew": the difference
>    between time offsets at T1 and T4 is the error for the measurement
>    interval associated with the clock's skew.
> should be:
>=20
> The accuracy of the T4-T1 interval is also critical to maintain and
>    report. The difference in errors=20
>    between the the time offsets at T1 and T4 is associated=20
> with the clock's skew[12=20
> <http://tools.ietf.org/html/draft-ietf-pmol-sip-perf-metrics-0
> 2#ref-12>].

I used the above paragraph suggestion.

>=20
> Skew is according to the definition you cite in [12] related=20
> to the difference in clock frequency between a true clock and=20
> the local clock.
> ("A clock's "skew" at a particular moment is the frequency difference
>    (first derivative of its offset with respect to true time) between
>    the clock and true time.[12])
>=20
> More properly the statement might be:
> The accuracy of the measurement of the T4-T1 interval is critical and
>    should be reported. The difference in errors=20
>    between the the time offsets at T1 and T4 is associated=20
> with the clock's skew[12=20
> <http://tools.ietf.org/html/draft-ietf-pmol-sip-perf-metrics-0
> 2#ref-12>] and the clock's "drift".
>=20
> Even more formally this is because the (local) clock's=20
> "offset" at T1 and the (local) clock's "offset" at T4 are not=20
> the same, due to the (local) clock's skew and drift (the 1st=20
> and 2nd derivatives of the clock's frequency).
>=20
> Here I have used "clock's offset" as defined in [12].
>=20
> ---
>=20
> The clock error SHOULD
>    be constrained to less than +/- 1 ms, implying 1 part per 1000
>    frequency accuracy for a 1 second interval.
> should be:
> The clock error SHOULD
>    be constrained to less than +/- 1 ms. This implies a=20
> frequency stability of greater 1 part per 1000
>    for a 1 second interval. This implies greater stability is=20
> required as the length of the T4-T1 increases,
>    in order to constrain the error to be less than +/- 1 ms.
>=20
> ---
> The following statement, seems to imply that reading the time=20
> from a clock requires interrupt processing and this need not=20
> be the case.
>=20
> The physical operation of reading time from a clock may be
>    constrained by the delay to service the interrupt. Therefore, the
>    accuracy of the time stamp read at T1 or T4 always includes the
>    interrupt delay, and this source of error SHOULD be known and
>    included in the error assessment.
> =20
> It would be better to say:
> The physical operation of reading time from a clock may be
>    constrained by the delay to service the interrupt.=20
> Therefore, if the
>    accuracy of the time stamp read at T1 or T4 includes
>    interrupt delay, then this source of error SHOULD be known and
>    included in the error assessment.
>=20
> ---
>=20
> There is also some confusion when you introduce the statement:
> =20
> 2. If a free-running clock is used to make the time interval
>       measurement, then value of T1 reported SHOULD be derived from a
>       different clock that meets the time of day accuracy requirements
>=20
> Since if you are measuring the T1 to T4 interval using such a=20
> clock, then there need not be a time of day measurement for=20
> T4, but rather an estimate of T4 based upon the measured=20
> intervals (measured using the free running clock) described=20
> above. Thus it is quite common today to measure a short time=20
> interval using the CPU's internal counter driven by the CPU=20
> clock (often as a RTC), this time interval can often be much=20
> higher resolution and have a much higher stability that the=20
> time of day clock.
> Additionally this clock generally is accessed by a read=20
> register operation and not an interrupt. (Note that you still=20
> have to state the relationship between this clock and the=20
> time of day clock in order to specify when the measurement=20
> occurred - the time of day of T1.)
>=20

I modified the paragraph to read:

 If a free-running clock is used to make the time interval measurement,
then the time of day reported with the measurement (which is normally
timestamp T1) SHOULD be derived from a different clock that meets the
time of day accuracy requirements...

> ---
>=20
> I do not think that the following statement is correct - from=20
> a statistical data analysis point of view:
> =20
> In regards to all of the metrics, the output values are directly
>    related to the accuracy and the equivalent level of granularity of
>    the input values.
>=20
> The word "directly" is not strictly true. Perhaps the=20
> following might be better:
>=20
> In regards to all of the metrics, the accuracy and=20
> granularity of the output values are
>    related to the accuracy and granularity of
>    the input values.
>=20
> ---
> Registration Request Delay is utilized to detect failures or
>    impairments causing delays in responding to a UAC REGISTER request.
>    RRD SHALL be measured and reported only for successful REGISTER
>    requests, and Ineffective Registration Attempts (Section=20
> 4.2=20
> <http://tools.ietf.org/html/draft-ietf-pmol-sip-perf-metrics-0
> 2#section-4.2>) SHALL
>    be reported for failures.  This metric is measured at the UAC.  The
>    output value of this metric is numerical and SHOULD be adjusted to
>    indicate milliseconds.  The following represents the=20
> calculation for
>    this metric:
> should be:
>=20
> Registration Request Delay is a measurement of the delay in=20
> responding to a UAC REGISTER request.
>    RRD SHALL be measured and reported only for successful REGISTER
>    requests, while Ineffective Registration Attempts (Section=20
> 4.2=20
> <http://tools.ietf.org/html/draft-ietf-pmol-sip-perf-metrics-0
> 2#section-4.2>) SHALL
>    be reported for failures.  This metric is measured at the UAC.  The
>    output value of this metric is numerical and SHOULD be=20
> stated in units of milliseconds.
>    The following represents the calculation for this metric:
>=20
> The changes are necessary since:
> 1. RRD does not provide any information in the case of failures!
> 2. The measured value is stated in milliseconds - since you=20
> have previously
>    stated that the clock error should be less than +/- 1=20
> millisecond. Of course from
>    a statistical point of view - the measured value can only=20
> be considered to be in units
>    of 2 milliseconds - since if you want to have 1=20
> millisecond accuracy, then the clock
>    has to be accurate to better than +/- 0.5 milliseconds=20
> (since the measurement is an
>    interval between to clock values).
>=20
> Note that throughout the text you should be stating that it=20
> is not an adjustment to milliseconds, but rather that this is=20
> simply the units used for this measurement.
>=20
> ---
> In a successful registration attempt, RRD is defined as the time
>    interval from the moment the initial REGISTER message=20
> containing the
>    necessary information is passed by the originating UAC to the
>    intended registrar until the 200 OK is received indicating the
>    registration attempt has completed successfully.  This dialog
>    includes an expected authentication challenge prior to=20
> receiving the
>    200 OK as describe in the following registration flow examples.
>=20
> In a successful registration attempt, RRD is defined as the time
>    interval from the first bit of the initial REGISTER message being
>    transmitted by the originating UAC to the
>    intended registrar until the 200 OK is last bit of the=20
> response indicating the
>    registration attempt has completed successfully has been=20
> received.  This dialog
>    includes any expected authentication challenge prior to=20
> receiving the
>    200 OK as describe in the following registration flow examples.
>=20
> I think that the above changes are necessary because of the=20
> way you defined T1 and T4; and the fact that an challenge=20
> might not occur (or even need to occur) - thus the interval=20
> only includes the challenge and response if they are expected.

Taking into consideration your suggestion, I have modified the paragraph
to read:

In a successful registration attempt, RRD is defined as the time=20
   interval from the first bit of the initial REGISTER message
containing the=20
   necessary information is passed by the originating UAC to the=20
   intended registrar until the last bit of the 200 OK is received
indicating the=20
   registration attempt has completed successfully.  This dialog=20
   includes an expected authentication challenge prior to receiving the=20
   200 OK as describe in the following registration flow examples.

I also updated all other metrics with a result of time to align with
this.

> ---
>=20
>=20
>  Ineffective registration attempts are utilized to detect failures or
>    impairments causing an inability for a registrar to receive or
>    respond to a UAC REGISTER request.  This metric is measured at the
>    UAC.  The output value of this metric is numerical and SHOULD be
>    adjusted to indicate a percentage of registration attempts.
> should be:
>  Ineffective registration attempts are utilized to monitor=20
> registration failures,
>    i.e. the inability for a registrar to receive or
>    respond to a UAC REGISTER request.  This metric is measured at the
>    UAC.  The output value of this metric is numerical and SHOULD be
>    reported as a percentage of registration attempts.
> ---
> You say:
> IRA may be
>    used to detect problems in downstream signaling functions,=20
> which may
>    be impairing the REGISTER message from reaching the intended
>    registrar; or, it may indicate a registrar has become=20
> overloaded and
>    is unable to respond to the request.
>=20
> However, I would think of the first problem being upstream=20
> signaling - affecting the REGISTER message from reaching the=20
> registration, while downstream signaling problems would be=20
> reflected in the register's response not being able to reach the UAC.
>=20

This was not worded well in the last revision and was noted to create
confusion during the last working group session, so I have modified the
paragraph to read:

Ineffective registration attempts are utilized to detect failures or=20
   impairments causing an inability for a registrar to receive a UAC
REGISTER request.
   This metric is measured at the UAC.  The output value of this metric
is numerical
   and SHOULD be reported as a percentage of registration attempts.

> ---
>=20
> There should also be a statement with regard to the first=20
> figure on page 8 of if the Total number of REGISTER Requests=20
> increases by 3 or if these 3 attempts at transmission are=20
> part of a single registration attempt.

I agree this is confusing.  I have added the following paragraph under
the signaling flow example:

In the previous message flow the UAC retries a REGISTER request multiple
times
     before the timer, indicating the failure, expires.  Only the first
REGISTER request MUST
     used for input to the calculation and an IRA.  Subsequent REGISTER
retries are identified
     by the same Call-ID and MUST be ignored for purposes of metric
calculation.  This ensures
     an accurate representation of the metric output.=20

>=20
> ---
>=20
>=20
>       Session Request Delay (SRD)is not a metric, but rather a set of
>       metrics. This is the case because you do not combine successful
>       and failed responses in the same result. Thus any=20
> result has to be
>       reported also stateing which type of SRD it is.

The following sentence has been added to the SRD introduction paragraph:

The output value of this metric=20
   MUST indicate whether the output is for successful or failed session
requests and
   SHOULD be stated in units of seconds.

>=20
> ---
>=20
> The output value of this metric is
>    numerical and SHOULD be adjusted to indicate seconds.
> should be:
>=20
> The output value of this metric is
>    numerical and SHOULD be reported in units of seconds.=20
>=20
> ---
>=20
> Regards,
> G. Q. "Chip" Maguire Jr.
>=20
>=20
>=20

Content-class: urn:content-classes:message
Date: Tue, 10 Feb 2009 13:01:26 -0600
From: "Mary Barnes" <[email-masked]>
To: "IETF Sipping List" <[email-masked]>
Cc: [email-masked], sipping chairs <[email-masked]>
Subject: [Sipping] IETF-74 Deadlines/agenda, new document template (RFC 5378) and RAI restructuring.

This is a multi-part message in MIME format.

------_=_NextPart_001_01C98BB1.A039E2D4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi folks,

I have 4 items of note below:

1) Deadlines for IETF-74 are very near:
http://www.ietf.org/meetings/74/cutoff-dates.html

-00 docs must be submitted by March 2, 2009 Monday (< 3 weeks) -
Internet Draft Cut-off for initial document (-00) submission by 17:00
PST (01:00 Tuesday, March 3 UTC/GMT), (and please) upload using IETF ID
Submission Tool <https://datatracker.ietf.org/idst/upload.cgi> . =20

-01+ docs must be submitted by March 9, 2009 Monday (< 4 weeks) -
Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC/GMT)=20

2)  New Template requirements. =20
New template text is required for any submissions per the recently
published RFC 5378 (Contributor's rights).   There has been LOTS (more
than a few threads, days and pages) of discussion on the IETF list about
these new requirements:
https://www1.ietf.org/mailman/listinfo/ietf

I won't try to summarize all the issues highlighted (nor the proposed
resolution) as I've honestly had to talk to corporate lawyers to
understand what it means to me in terms of submitting documents. One
thing I do understand is that an editor MUST ensure that the statement
is appropriate for ALL authors/contributors.  This means that you may
have difficulty getting your documents submitted in time IF you don't
try to get the approval from your co-authors sooner rather than later -
i.e., there is no reason why you can't shoot that email off today.
And, you may need to talk to your lawyers before you submit a document
as well - in my experience this can take some time.=20

3) Agenda Requests.
As usual, please send any agenda requests to chairs and Oscar (cc'ed
above) - all 3 please, otw we end up forwarding to one another and we
each get 3 copies. =20

The deadline for the preliminary agenda is March 11, 2009, with the
final/updated agenda due on March 16, 2009.  Please note that as usual,
agenda time is first given to WG items, then to items based upon the
level of discussion. Thus, waiting until March 2nd or 9th to submit a
contribution and elicit feedback is not particularly effective. =20

Here's the usual template that makes things easier in creating the
agenda - it also ensures that we don't make clerical errors in the
process:

<tr>
         <td><a href=3D"mailto:[email-masked]">
Gonzalo Camarillo</a></td>
         <td>Exploders</td>
         <td><center>5</center></td>
         <td>
<a
href=3D"http://www.ietf.org/internet-drafts/draft-camarillo-sipping-explo=
d
ers-02.txt">
draft-camarillo-sipping-exploders-02.txt</a></td>
       </tr>

4) RAI restructuring.=20
If you're not on the RAI area mailing list, you might want to at least
review the archives as there is ongoing discussion wrt RAI area
restructuring:
https://www1.ietf.org/mailman/listinfo/rai

If you don't want to bother with that, you should at least look at the
proposed changes to the "SIP change" process:
http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-peterson-rai-rfc
3427bis-01a.txt

Note that Jon has not yet submitted due to 2) above.  This is your
chance as contributors and participants to provide input to make our
work more effective and meet the requirements of the constituency.
Please direct any feedback to the RAI area list ONLY.=20

Regards,
Mary
SIPPING WG co-chair

------_=_NextPart_001_01C98BB1.A039E2D4
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>IETF-74 Deadlines/agenda, new document template (RFC 5378) and =
RAI restructuring. </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi folks,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I have 4 items of note below:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1) Deadlines for IETF-74 are very =
near:</FONT>

<BR><A =
HREF=3D"http://www.ietf.org/meetings/74/cutoff-dates.html"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://www.ietf.org/meetings/74/cutoff-dates.html</FONT></=
U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-00 docs must be submitted by</FONT> =
<FONT SIZE=3D2 FACE=3D"Arial">March 2, 2009 Monday (&lt; 3 weeks) - =
Internet Draft Cut-off for initial document (-00) submission by 17:00 =
PST (01:00 Tuesday, March 3 UTC/GMT), (and please) upload using =
</FONT><A HREF=3D"https://datatracker.ietf.org/idst/upload.cgi"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">IETF ID Submission =
Tool</FONT></U></A><FONT SIZE=3D2 FACE=3D"Arial">.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-01+ docs must be submitted by March 9, =
2009 Monday (&lt; 4 weeks) - Internet Draft final submission cut-off by =
17:00 PDT (24:00 UTC/GMT) </FONT></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">2)&nbsp; New Template =
requirements.&nbsp; </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">New template text is required for any =
submissions per the recently published RFC 5378 (Contributor's =
rights).&nbsp;&nbsp; There has been LOTS (more than a few threads, days =
and pages) of discussion on the IETF list about these new =
requirements:</FONT></P>

<P><A HREF=3D"https://www1.ietf.org/mailman/listinfo/ietf"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">https://www1.ietf.org/mailman/listinfo/ietf</FONT></U></A>=

</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I won't try to summarize all the issues =
highlighted (nor the proposed resolution) as I've honestly had to talk =
to corporate lawyers to understand what it means to me in terms of =
submitting documents. One thing I do understand is that an editor MUST =
ensure that the statement is appropriate for ALL =
authors/contributors.&nbsp; This means that you may have difficulty =
getting your documents submitted in time IF you don't try to get the =
approval from your co-authors sooner rather than later - i.e., there is =
no reason why you can't shoot that email off today.&nbsp;&nbsp; And, you =
may need to talk to your lawyers before you submit a document as well - =
in my experience this can take some time. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">3) Agenda Requests.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">As</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">usual, please send any agenda requests to chairs and =
Oscar (cc'ed above) - all 3 please, otw we end up forwarding to one =
another and we each get 3 copies.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The deadline for the preliminary agenda =
is March 11, 2009, with the final/updated agenda due on March 16, =
2009.&nbsp; Please note that as usual, agenda time is first given to WG =
items, then to items based upon the level of discussion. Thus, waiting =
until March 2nd or 9th to submit a contribution and elicit feedback is =
not particularly effective.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Here's the usual template that makes =
things easier in creating the agenda - it also ensures that we don't =
make clerical errors in the process:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&lt;tr&gt;</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;td&gt;&lt;a href=3D&quot;<A =
HREF=3D"mailto:[email-masked]">mailto:Gonzalo.Camarillo@e=
ricsson.com</A>&quot;&gt;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Gonzalo =
Camarillo&lt;/a&gt;&lt;/td&gt;</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;td&gt;Exploders&lt;/td&gt;</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;td&gt;&lt;center&gt;5&lt;/center&gt;&lt;/td&gt;</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;td&gt;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&lt;a</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">href=3D&quot;<A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-camarillo-sipping-explo=
d">http://www.ietf.org/internet-drafts/draft-camarillo-sipping-explod</A>=
</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">ers-02.txt&quot;&gt;</FONT>

<BR><FONT SIZE=3D2 =
FACE=3D"Arial">draft-camarillo-sipping-exploders-02.txt&lt;/a&gt;&lt;/td&=
gt;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;/tr&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">4) RAI restructuring. </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">If you're not on the RAI area mailing =
list, you might want to at least review the archives as there is ongoing =
discussion wrt RAI area restructuring:</FONT></P>

<P><A HREF=3D"https://www1.ietf.org/mailman/listinfo/rai"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">https://www1.ietf.org/mailman/listinfo/rai</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If you don't want to bother with that, =
you should at least look at the proposed changes to the &quot;SIP =
change&quot; process:</FONT>

<BR><A =
HREF=3D"http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-peterson-=
rai-rfc3427bis-01a.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-pe=
terson-rai-rfc3427bis-01a.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Note that Jon has not yet submitted due =
to 2) above.&nbsp; This is your chance as contributors and participants =
to provide input to make our work more effective and meet the =
requirements of the constituency. Please direct any feedback to the RAI =
area list ONLY. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Mary</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">SIPPING WG co-chair</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C98BB1.A039E2D4--

Date: Tue, 10 Feb 2009 21:10:07 +0200
From: Valentin Nechayev <[email-masked]>
To: [email-masked]
Subject: [Sipping] late OAM consistency question
Reply-To: [email-masked]

Hi,
There is late offer-answer model (offer in 200, answer in ACK)
according to RFC3261 par.13 and RFC3264. In it, if the transaction
requester don't accept the offer, the only correct action is to
confirm transaction (sending ACK) but then immediately stop the
call with BYE. Am I right in this? If yes, I have the question _why_
this approach was selected among another possible ones:

1. Send ACK without SDP leaving UAs in state "established dialog, but
no session" with need to negotiate session;
2. Send negative opposition of ACK (name it here "NAK"); this also
would be useful in some other cases not related to session itself
(want to cancel request when final response is unacceptable);
3. Send ACK but with special rejecting description (this is kind
of merge of 1 and 2);
4. Disable responding with ACK totally, causing here UAS timeout
trigger and stopping the call on opposite side;
5. Require 100rel to work with late OAM, send offer SDPs only in
1xx and respond with answer in PRACK;
6. something else?

The problem I need to solve is to embed late OAM implementation
properly into existing stack with own complex processing which
doesn't restore after misconfirmed offers...

-- 
Valentin Nechayev
PortaOne Inc., Software Engineer
mailto:[email-masked]

From: "Steve Young" <[email-masked]>
To: <[email-masked]>
Date: Tue, 10 Feb 2009 11:14:38 -0800
Subject: [Sipping] This is a test, please ignore

This is a multipart message in MIME format.

------=_NextPart_000_003F_01C98B70.C41183D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Steve

------=_NextPart_000_003F_01C98B70.C41183D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"Trebuchet MS";
	panose-1:2 11 6 3 2 2 2 2 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Trebuchet MS","sans-serif";
	color:#002060;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Trebuchet MS","sans-serif";
color:#002060'>Steve<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Trebuchet MS","sans-serif";
color:#002060'><o:p>&nbsp;</o:p></span></p>

</div>

</body>

</html>

------=_NextPart_000_003F_01C98B70.C41183D0--