RE: VS: VS: [Sipping] FW: I-DACTION:draft-sawada-sipping-sip-offeranswer-01.txt (Comments 4 to 6)

["Christer Holmberg \(JO/LMF\)" <christer.holmberg at ericsson.com>]

Hi, 

>>> that you should always offer (or answer) what *you* want the state
of 
>>> the session to be, to the extent that it is permitted. (There are 
>>> constraints - many for answerers, but also some for re-offerers in a
>>> dialog.)
>>> 
>> [CHH] Yes, but in some of the re-INVITE-without-SDP scenarios the UAS

>> is supposed to send an offer according to what the UAC (the one 
>> sending the empty re-INVITE) wants. So, the UAC has to assume the UAS

>> knows what the UAC wants
>>
>> What scenarios require a particular kind of behavior?
> 
>> [CHH] In some of the 3PCC scenaios, where the UAC assumes, in orde to
make the scenario work, that the UAS will send a certain type of offer
(in the 
>> 200 response). Again, in those cases I don't think it's about what
the one sending the offer wants - it's about what the one receiving the
offer 
>>wants...
>
>Precisely which scenarios do you mean. It is pretty crazy to expect
such behavior, but I am not too surprised if there are scenarios like
that.
>
>I think there are a cases that require a UAS to be psychic. (Those
related to REFER often feel that way. Dale has recently written
something on that.)

[CHH] It's quite a while since we discussed this, but hopefully those
who pushed for the specfic behavior can correct me if I'm wrong. The
scenario was something like the following:

User A receives an hold re-INVITE. Later (when some transfer functions
have taken place) user A receives an empty re-INVITE. Now, in order to
make things work, user A is supposed to un-hold the session and send an
SDP offer as for a new session - not simply return the SDP from the
previous offer/answer transaction.

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