[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,
>>>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.
[CHH] That's true, yes - and important to document :)
Especially if a codec has been "used" (i.e. BOTH ends have indicated
support of it in previous offer/answer transactions) in the session
prior to the re-INVITE the PT number should be the same. If the codec
has NOT been used (i.e. both ends have NOT indicated support of it) I
guess it's not that critical if the PT number is the same on not, but
using the same number could still be recommended even in that case.
[/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]
>If the user isn't able to interact then what is wanted just doesn't
change.
[CHH] That is true - IF we now will document what "wants" means, and how
the generated offer shall look like. The initial issue was that today it
is NOT documented anywhere how the offer shall look like, but STILL a
specific behavior IS assumed/expected in certain use-cases. [/CHH]
>For a UA like a gateway, the "user" is the PSTN, and indicates what it
wants via ISUP or whatever.
[CHH] No. A re-INVITE may trigger a hold/un-hold CPG, but nothing else
(there is no "negotiation"). Also, the ISUP side has no clue about which
codecs etc are used on the SIP side, because most likely the same codec
will be used on the ISUP side in any case, so it probably wouldn't be
able to give any useful instructions.
>>[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.
[CHH] I have no problem with that. But - needs to be documented :)
>>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.
[CHH] Bueno :)
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