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