Subject: RE: VS: VS: [Sipping]FW: I-DACTION:draft-sawada-sipping-sip-offeranswer-01.txt(Comments 4 to 6)

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 30 Jun 2006 09:19:38 +0200

Hi,

I can understand if we don't want to change the existing rules in this draft, so as far as I am concerned we don't need to discuss that.

HOWEVER, I still DO think it would be very important to DOCUMENT the ISSUES (for example how to reject an offer in a PRACK, and why one MUST send an offer in the first reliable provisional response to an empty INVITE) we've been discussing, and maybe even give some "hints" on how they COULD be solved (and/or which RFCs they would impact). The actual changes we can then do as a separate work.

Otherwise, the same questions will come up over and over again on the list(s), and on the interop events...

When it comes to the issue about what to send in the offer to an empty re-INVITE, I think that is something we SHALL document. Because, it does NOT change any existing rules - it clarifies a behavior.

Regards,

Christer

-----Original Message-----
From: Takuya Sawada [mailto:[email-masked]] 
Sent: 30. kesäkuuta 2006 10:08
To: [email-masked]; Christer Holmberg (JO/LMF)
Cc: [email-masked]; [email-masked]
Subject: Re: VS: VS: [Sipping]FW: I-DACTION:draft-sawada-sipping-sip-offeranswer-01.txt(Comments 4 to 6)

Hi,

> Takuya has been very quiet during this conversation. The draft is 
> really his, with me as secondary collaborator. So he should get final 
> say in what goes into the draft.

Let me excuse myself first.
I took days off early in this week. After coming back work, I have been busy to catch up my daily work (and world-cup games, too).
Then I have not yet followed the discussion so far.
I will take time this weekend to follow up and make some comments on the issues next week.
Basically, I will try to incorporate the discussed issues into the draft.

Also, it may be more imporatnt, I would like to see how this draft goes for the next step.
We should ask the chairs and make consensus in the list. But before doing that, probably we must make it clear what is the scope of the draft.
That is, whether we intend to change the rules described in the existing RFCs, or just to summarize the rules and recommend something within the rules. My first intention was the latter, and is still the same so far.
Let us confirm.
I believe that many feel it is useful information and worth considering whether it should become a working group item.

Regards,
Takuya

> 
> Christer Holmberg (JO/LMF) wrote:
> > Hi Paul,
> > 
> > Thanks for your clarifications! I think we're getting in on the same 
> > frequency - at least on this issue :)
> 
> Yes, I think we more or less have been all along - just using 
> different words.
> 
> >>> Now, my question: since "Called party" may have no clue about the
> > scenario, and no clue about all the other entities
> >>> involved, how does it know that it "wants" to send such offer at 
> >>> this
> > point?
> > 
> >> This idea of what the UA "wants" to do is a nebulous one, but I 
> >> think
> > it can be determined without regard to the intent
> >> of the other party.
> >>
> >> Roughly speaking, I think "want" means "what the UA is *capable* of
> > doing. For example, if the UA is capable of using 5
> >> codecs, then it *ought* to list all five, even though in a prior
> > exchange four of them had been rejected by the other
> >> party. (That covers your case here.)
> > 
> > 
> > [CHH] Yes. I have used the sentence "creat an offer as for a new 
> > call", but I guess we mean the same thing. [/CHH]
> 
> Its almost the same. There are some subtle potential differences. For 
> instance, the numbers assigned to the codec types are supposed to 
> remain unchanged. They might differ from what the UA would put into an 
> initial invite. In all cases the constraints applied by 3264 need to 
> be followed. They aren't very severe for subsequent offers, but they exist.
> 
> >> But it isn't quite that simple in all cases. Consider a UA that has
> > both audio and video capabilities. Whether the UA
> >> "wants" to use video may change over time depending on options in 
> >> the
> > UI of the UA. This could change mid-call.
> > 
> > [CHH] Correct. And, IF the user is able to interact with the UA it 
> > may not be a problem. But, in the case of an interworking node that 
> > may not be possible. [/CHH]
> 
> If the user isn't able to interact then what is wanted just doesn't change.
> 
> For a UA like a gateway, the "user" is the PSTN, and indicates what it 
> wants via ISUP or whatever.
> 
> >> Similarly for "hold". There is typically a control in the UI which
> > indicated the user's desire to hold the call. And each
> >> end has such an option. In each offer/answer, the decision of 
> >> whether
> > to offer sendonly, recvonly, sendrecv, or inactive
> >> is determined by the *local* state, not anything learned about the
> > remote party in a prior exchange.
> >> (Some UAs may not have a local control of HOLD. If not, then they
> > probably always offer sendrecv.)
> >> If each end asserts its own interests, as well as following the 
> >> rules
> > of offer/answer, then the most acceptable mutual
> >> agreement will be reached.
> > 
> > 
> > [CHH] In the example "called party" had not been on hold. But, if 
> > "called party" would have been put on hold, prior to receiving the 
> > empty re-INVITE, the question would have been: when "called party" 
> > generates the capable-of-doing offer to be sent in the 200 OK, shall 
> > it also un-hold the call (even if "controller" initially initiated the hold)?
> 
> Yes. If the controller still wants the call on hold then it is 
> perfectly free to do so in the answer.
> 
> > In the example, IF "called party" would have been on hold when 
> > receiving the empty re-INVITE, and would NOT un-hold when sending 
> > the new offer in 200 OK, "controller" would have to understand that 
> > IT must send an un-hold offer before "called party" and "pre-paid 
> > user" can start to communicate. It could become rather complicated...
> 
> Nor would it have any reason to believe that would work. For hold, 
> things become a mess if the UAs don't behave this way.
> 
> In particular, if both parties put the call on hold, then if you 
> aren't careful, there is no way to get out of hold.
> 
> > So, whatever "solution" we come up with, I think we shall describe 
> > in the offeranswer draft. [/CHH]
> 
> Takuya has been very quiet during this conversation. The draft is 
> really his, with me as secondary collaborator. So he should get final 
> say in what goes into the draft.
> 
> But I do agree with you now that his is another of those pieces of 
> folk wisdom that needs to be written down somewhere.
> 
> 	Paul
> 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> > 
> 
> _______________________________________________
> Sipping mailing list  https://www1.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

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi,
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
[email-masked]

_______________________________________________
Sipping mailing list  https://www1.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