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

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 29 Jun 2006 12:21:19 +0200

Hi,

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?

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 27. kesäkuuta 2006 16:46
To: Christer Holmberg (JO/LMF)
Cc: Takuya Sawada; [email-masked]
Subject: Re: VS: VS: [Sipping] FW: I-DACTION:draft-sawada-sipping-sip-offeranswer-01.txt (Comments 4 to 6)

Christer Holmberg (JO/LMF) wrote:
> Hi,
> 
>>>> 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.
>> This doesn't require User A to be psychic - only to keep stating its
> desires at each opportunity.
>> In this scenario I believe User A was *put on hold* - he didn't 
>> *want*
> to be on hold. So at each opportunity (like the offerless reinvite) it 
> simply
>> states what it wants - which is *not* to be on hold.
>>
>> If, after A had been put on hold it decided to initiate its own hold
> action (perhaps because another call was received), then when the 
> reinvite is
>> received it might indeed specify SENDONLY. That wouldn't be what the
> sender of the reinvite wants to hear, but it is the current situation.
> (Of course
>> when A decided to do it own hold it probably should have done its own
> reinvite specifying INACTIVE.)
> 
> Ok, so what is the "desire" of an MGC (or any other entity without 
> direct user control)? How does an MGC know whether he "wants" to be on 
> hold or not?

It needs to figure it out based on interactions with the other side.

For a "regular" UA, I think a reasonable way to make the determination is based on whether the media stream(s) are connected to a primary local source, sink, or both, or neither. I think the same works for an MGC.

Signaling on the non-sip side might influence this state.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Jun 2006 09:33:29 -0400

> 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.)

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.

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.

	Paul