[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sip at ietf.org 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
tu-sawada at kddi.com
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP