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: Thu, 29 Jun 2006 15:56:27 +0200

Hi Paul, 

Thanks for your clarifications! I think we're getting in on the same
frequency - at least on this issue :)

>>I had a look at chapter 10.2 of RFC 3725, and I think I found an
example to explain my issue.
>> 
>>Look at message 14, where "Called party" sends an offer in the 200 OK
response. This SDP is then forwarded by the 
>>controller as an offer towards "Pre-paid user".
>> 
>>Now, the previous active local SDP of "Called party" (sent as an
answer to "Controller" in message 2) contained the 
>>negotiated codecs between "Controller" and "Called party". If "Called
party" would simply send that SDP as an offer in 
>>the 200 OK it is not sure that the session with "Pre-paid user" would
succeed, because it may not support the codec set 
>>which was used before. So, in this case I guess it is assumed that
"Called party" will send an offer as for a new call, 
>>including all codecs it supports.
>> 
>>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?

>[I got off to a bad start at the very beginning of this exchange by
initially suggesting that the "prior" SDP should be 
>sent in response to an offerless invite. That was a screw up,
inconsistent with my long running position, and I've been 
>trying to dig out of that ever since on this thread.]
>
>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]

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

>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)?

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

So, whatever "solution" we come up with, I think we shall describe in
the offeranswer draft. [/CHH]

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Jun 2006 10:53:46 -0400

> frequency - at least on this issue :)

Yes, I think we more or less have been all along - just using different 
words.

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

> not be a problem. But, in the case of an interworking node that may not

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.

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

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

> 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

---

From: Takuya Sawada <[email-masked]>
Date: Fri, 30 Jun 2006 16:08:15 +0900

Hi,

> 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

> wisdom that needs to be written down somewhere.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Jun 2006 10:10:07 -0400

> busy to catch up my daily work (and world-cup games, too).

We are not going to fault you for that.

> the rules. My first intention was the latter, and is still the same so far.

IMO it would be best for this draft to summarize the rules and possibly 
make some recommendations (best practices) about how to do things. It 
can also identify issues that require changes to be resolved. Then it 
might take one or more standards track drafts to fix those issues.

> whether it should become a working group item.

Given the frequency with which questions come up about this subject, I 
think it important that it end up somewhere permanent where it can be 
referenced. Perhaps as a BCP. I guess maybe it doesn't ever have to 
become a WG document for that to happen. But we need some guidance on that.

	Paul