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: Wed, 28 Jun 2006 00:04:38 +0200

Hi, 

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

I am not sure I understand. What other side? And what interactions? Do
you mean, in case of an ISUP/SIP MGC, the ISUP side, and ISUP
interactions?

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

I am not sure I understand, but HOW would the MGC know that? All it has
is a remote SDP...

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

In the SIP/ISUP case that won't help, because there will be no ISUP
signalling. 

Yes, IF the MGC decides to change the hold state it may send a CPG
towards ISUP, but first it would need to decided whether to change that
hold state in the first place...

Chris, I appologize if I remember wrong, but didn't you at one point
have strong opinions on how an SDP offer to an empty re-INVITE should
look like?

Regards,

Christer

_______________________________________________
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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 30 Jun 2006 10:00:29 +0200

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