Kasturi Narayanan wrote:
> I agree with you with regards to the mode of the connection.
> Basically it should return what it can support based on its own state
> not the state it was driven to because of a Re-invite (send-only in the
> example).
>
> For example if the Application Server initially answered the call from
> an UA-A and later put it on hold while establishing the call towards a
> remote user UA-B. After the call with the remote user is answered, the
> AS initiates a Re-Invite with No SDP towards UA-A. In this case if the
> UA-A returns recv-only (instead of send-recv), the AS forwards it to
> UA-B which will result in a Held call between UA-A and UA-B.
> You may recommend that AS shld remove the call from Hold before sending
> the Re-invite with "No-SDP".
OK. I think we are in agreement, except perhaps about the language used
to describe it.
> Also my question was with regards to other capabilities as well.
Yes, the issue does apply to other things. But its easy to discuss
relative to hold because that is familiar.
I think the same general philosophy applies to other aspects of offers
and answers, but perhaps with some nuances.
> Like for example if Video is supported by an UA and initially it got an
> invite with audio media only and later if it gets a Re-invite with "No
> SDP" should it not return the Video Capability as well in the 200 ok so
> that Video also can be re-negotiated if possible.
I think the answer will sometimes be YES, but maybe not always,
depending on device resource management and UI.
If the device has dedicated video resources, and normally uses both
audio and video in all calls if it can, then yes I think it should offer
video in the case you cite.
But the device might be more careful in its use of video. For instance,
when a call is alerting, the user of the device may have the option of
enabling or disabling video before answering. If a call comes in with
only audio, that won't be an issue, but it will still be an issue for
subsequent offers made by the device within the call. To get this right
I think there needs to be local state in the device about whether to use
video or not.
If the call was initially established without video, and there is a
subsequent reinvite that again offers video, the device has two options:
it can alert the user again, giving the user the option to enable video,
or it can simply respond based on local state. A similar choice is
available if an offerless reinvite is received.
Note that the introduction of multiple media into calls adds a lot of
complexity compared to the case where voice is the only medium. We have
been able to avoid a lot of this until now, but it is starting to be the
time when these issued need to be addressed.
Some interesting questions:
- does "hold" apply to a call, or to a particular medium within a call?
(At the signaling level it is per medium, but at the UI level it could
be either way.)
- if I want to "hold" one medium in a multimedia call, is it better to
keep the stream and set it to inactive, or to remove the stream from
the call?
- if its ok to drop one stream from a multimedia call to put it on hold,
is it only to drop the *only* stream from call to put it on hold?
(Leaving a dialog with no media.)
Paul
> But your conclusion answers all the above questions
> Summarizing:
>> - an offer always contains what the offerer *wants*.
>> - an answer is computed as follows:
>> . select the answers that are consistent with the offer
>> . choose the one of those that is closest to what the
>> answerer *wants"
>>
> Kasturi
>
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 17, 2006 9:35 AM
> To: Kasturi Narayanan
> Cc: kaojohnny; Sip-implementors
> Subject: Re: [Sip-implementors] INV without sdp
>
>
>
> Kasturi Narayanan wrote:
>> Paul,
>> Your examples are very specific to the Hold Scenario.
>> But in the case of Third-party call flow using Re-Invites, the
>> Application Server prefers a full capability to be returned so that it
>
>> can pass it along to the other party.
>> This enables the remote users to re-negotiate the Media based on their
>
>> capabilities.
>
> I'm not sure I understand you, but as best I do I think I disagree.
>
> The 3pcc use cases are one of the compelling reasons for using this
> approach, because it makes extensive use of offerless INVITEs.
>
> In the 3pcc case the controller is likely not to know the state of
> either UA. Having the UA respond with what it "wants" at the time (a
> reflection of *its* state) will do the right thing in all the cases I am
>
> aware of.
>
> If a user has pushed the hold button on their phone and walked away, and
>
> then the phone receives an offerless invite, what good thing will result
>
> by it responding with "sendrecv"? The user of the phone expects it to
> stay on hold until he does something to take it out of that state.
>
>> Yes this needs to be clarified addressing all the requiremets.
>
> Yes, i agree. The fuzzy part in my approach is how to determine what a
> UA "wants".
>
> Paul
>
>> Thanks
>> Kasturi
>>
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, November 16, 2006 1:46 PM
>> To: Kasturi Narayanan
>> Cc: kaojohnny; Sip-implementors
>> Subject: Re: [Sip-implementors] INV without sdp
>>
>>
>>
>> Kasturi Narayanan wrote:
>>> Two interpretations are around for Re-invite without SDP.
>>> 1) Return the Currently Negotiated SDP which is recv only
>>> 2) Treat that as a new SDP negotiation and return the full
>> capabilities
>>> (with send-recv etc).
>>>
>>> I think the second option is more generic.
>> You don't want to return "full capabilities" if you don't *want* that.
>>
>> In particular consider a variation on your scenario:
>>
>> After Caller A and Callee B construct a dialog,
>> A sends a re-invite request with sdp indicates "sendonly" to hold
> B.
>> B responses 200 OK with sdp indicated "recvonly" correctly.
>> If at this moment, *B* sends a re-invite again but without sdp,
>> how does *A* response in sdp? sendreccv? recvonly?
>>
>> In this case, A should respond not with its "full capabilities", but
>> rather with "its desired state". It had previously wanted to have the
>> call held, so it presumably should offer sendonly again. However, it
> is
>> possible that it was just toggled off hold but received the reinvite
>> before it could send its own. In that case it can offer sendrecv.
>>
>> The general rule that always works if for the offerer to always offer
>> the state *it* desires, without regard for what it thinks the answerer
>
>> might prefer. This preserves the options for the answerer.
>>
>> Consider yet another case:
>> - A and B have a dialog
>> - A reinvites with offer of sendonly to establish hold
>> - B answers with recvonly to acknowledge the hold
>> - B also decides to hold the call, so reinvites with offer
>> of sendonly. (What it wants.)
>> - A still wishes hold on its end, so doesn't want to answer
>> recvonly. The only valid answer consistent with what it wants
>> to do and with the offer is inactive, so it answers that.
>> - For some reason, B later sends an offerless reinvite to A.
>> A still wants a hold initiated by its end, but doesn't care
>> that call is held from other end. So it offers sendonly.
>> If B still wants the call held from its end as well, it will
>> answer with inactive. So the state stays as it was.
>> - Later A wants to go off hold. So it sends a reinvite with
>> an offer of sendrecv.
>> - B still wants the call held, so it answers with sendonly.
>> - Later, B wants to go off hold too, so it sends reinvite with
>> offer of sendrecv.
>> - A also wants to be off hold, so it answers with sendrecv.
>>
>> Summarizing:
>> - an offer always contains what the offerer *wants*.
>> - an answer is computed as follows:
>> . select the answers that are consistent with the offer
>> . choose the one of those that is closest to what the
>> answerer *wants"
>>
>> We intend to write something about this in the offeranswer draft, but
>> haven't yet.
>>
>> Paul
>>
>>> Kasturi
>>>
>>> -----Original Message-----
>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>>> Sent: Wednesday, November 15, 2006 8:47 PM
>>> To: [email protected]
>>> Subject: [Sip-implementors] INV without sdp
>>>
>>> Hi ALL:
>>>
>>> I'm a newbie of sip implementation. Here is a question about invite
>>> request
>>> without sdp.
>>>
>>> After Caller A and Callee B construct a dialog, A sends a re-invite
>>> request
>>> with sdp indicates "sendony" to hold B. B responses 200 OK with sdp
>>> indicated "receonly" correctly. If at this moment, A sends a
>> re-invite
>>> again but without sdp, how does B response in sdp? sendrece?
> receonly?
>>> Is there any sections in any RFCs defines the behavior described
> here?
>>> Thanks you all.
>>>
>>> BR,
>>> Johnny
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> [email protected]
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>>>
>>> _______________________________________________
>>> Sip-implementors mailing list
>>> [email protected]
>>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
