[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 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP