Subject: [Sipping] Re: Call Hold in draft-ietf-sipping-sip-offeranswer-04.txt

From: Miguel Garcia <[email-masked]>
Date: Mon, 03 Dec 2007 17:28:05 +0200

Paul:

RFC 3264 has been out there a few years, so I suspect there are multiple 
implementations that implement hold as informatively indicated in RFC 
3264, because this has been the best description so far.

An Internet-Draft that describes yet another way of doing hold that does 
not follow that informative way will certainly break existing 
implementations. Thus, if something ought to be done, I am leaning 
towards making normative what is the current practice.

/Miguel

Paul Kyzivat wrote:
> Miguel,
> 
> Miguel Garcia wrote:
>> While reading draft-ietf-sipping-sip-offeranswer-04.txt I found 
>> difficult an apparent contradiction in the 6th paragraph in Section 
>> 5.3, which is about Hold and Resume. The text says:
>>
>>    If UA2 has previously been "placed on hold" by UA1, via receipt of
>>    "a=sendonly", then it may initiate its own hold by sending a new
>>    offer containing "a=sendonly" to UA1. Upon receipt of that, UA1 will
>>    answer with "a=inactive" because that is the only valid answer that
>>    reflects its desire not to receive media.
>>
>> My problem is that the first sentence contradicts RFC 3264 Section 
>> 8.4, that says:
>>
>>    If the stream to be placed on hold was previously a sendrecv media
>>    stream, it is placed on hold by marking it as sendonly.  If the
>>    stream to be placed on hold was previously a recvonly media stream,
>>    it is placed on hold by marking it inactive.
> 
> I find nothing normative in the above paragraph. This is in a document 
> that is *laced* with normative language about the same topic in other 
> places. So, IMO the lack of normative language means this is not normative.
> 
> Its actually lacking in normative language about what directionality 
> attributes can be in an offer and what the corresponding response should 
> be in the answer. It ought to have had more of that, which is distinct 
> from how to handle "hold". Lacking that, I think the best that can be 
> done is to infer the rules are the same as for initial offers and answers.
> 
> An option would be to conclude that this paragraph is normative. That 
> would mean that if the stream was previously recvonly then making a new 
> offer of sendonly or sendrecv would be invalid. But that would leave the 
> issue open of what should happen in that case. It is really harmless 
> since it can be adjusted to the answerer's needs in the answer, so it is 
> pointless to declare it invalid.
> 
> Personally I view this as a defect in 3264, but since it is in 
> non-normative language it isn't urgent to do anything about it.
> 
> In general conditioning your subsequent offer on what you *think* that 
> other party wants, based on its prior behavior, is counterproductive.
> 
> (Note that -offeranswer- is not saying what must be in the offer - just 
> offering best practice. So offering what is recommended(?) in this 
> section of 3264 is also ok if not best practice.)
> 
> This is a pretty fundamental part of this section in -offeranswer- so I 
> am not inclined to change it without full airing and guidance from the 
> WG. If this is viewed as a normative change then I guess we will have to 
> discuss if/how to deal with that.
> 
>     Thanks,
>     Paul
> 
>> So, the case that the draft discusses is that the media stream was 
>> previously in recvonly mode. So, according to RFC 3264 it should be 
>> put on hold by setting it to inactive rather than sendonly like the 
>> draft sasy.
>>
>> Can this be fixed?
>>
>> Regards,
>>
>>        Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

_______________________________________________
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: Tue, 04 Dec 2007 13:09:38 -0500

There is no intent (or words) here saying that a UA must do as 
recommended. A UA doing it as specified in 3264 is still permissible. 
However, if both ends implement according to 3264 then it will be 
impossible to get off hold, which is clearly undesirable.

Yes, I am sure that when a UA implements according to the recommendation 
in this draft there will be *some* peer implementations that will 
malfunction. That is a bug, even according to 3264. It needs to be fixed.

	Thanks,
	Paul

Miguel Garcia wrote:
>> attributes can be in an offer and what the corresponding response 
>> should be in the answer. It ought to have had more of that, which is 
>> distinct from how to handle "hold". Lacking that, I think the best 
>> that can be done is to infer the rules are the same as for initial 
>> offers and answers.
>>
>> would mean that if the stream was previously recvonly then making a 
>> new offer of sendonly or sendrecv would be invalid. But that would 
>> leave the issue open of what should happen in that case. It is really 
>> harmless since it can be adjusted to the answerer's needs in the 
>> answer, so it is pointless to declare it invalid.
>>
>> (Note that -offeranswer- is not saying what must be in the offer - 
>> just offering best practice. So offering what is recommended(?) in 
>> this section of 3264 is also ok if not best practice.)
>>
>> This is a pretty fundamental part of this section in -offeranswer- so 
>> I am not inclined to change it without full airing and guidance from 
>> the WG. If this is viewed as a normative change then I guess we will 
>> have to discuss if/how to deal with that.
>>
>>     Thanks,
>>     Paul
>>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 4 Dec 2007 18:03:45 -0600

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> 
> There is no intent (or words) here saying that a UA must do 
> as recommended. A UA doing it as specified in 3264 is still 
> permissible. 
> However, if both ends implement according to 3264 then it 
> will be impossible to get off hold, which is clearly undesirable.

What? Why? You just send a=sendrev, no?

> Yes, I am sure that when a UA implements according to the 
> recommendation in this draft there will be *some* peer 
> implementations that will malfunction. That is a bug, even 
> according to 3264. It needs to be fixed.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Dec 2007 20:03:48 -0500

> What? Why? You just send a=sendrev, no?

I just reviewed this again with Miguel. 3264 actually doesn't exactly 
say what to do to exit hold in this case.

What 3264, section 8.4, says is:

    If a party in a call wants to put the other party "on hold", i.e.,
    request that it temporarily stops sending one or more unicast media
    streams, a party offers the other an updated SDP.

Note that the above says: "If the stream to be placed on hold *was 
previously* a recvonly media stream". Its not entirely clear if "was 
previously" means "was send in the last offer or answer by this UA", or 
it it means "was what this UA desired before deciding to go on hold.

It seems clear that at least some people think this means "was send in 
the last offer or answer by this UA".

The RFC continues:

    This means that a stream is placed "on hold" separately in each
    direction.  Each stream is placed "on hold" independently.  The
    recipient of an offer for a stream on-hold SHOULD NOT automatically
    return an answer with the corresponding stream on hold.  An SDP with
    all streams "on hold" is referred to as held SDP.

If the earlier thing meant "was send in the last offer or answer by this 
UA", then it is inconsistent with this latter statement, because the 
prior answer is dependent on what the other end offered, and so the new 
offer isn't *separate* from the hold in the other direction.

I probably overstated the case by saying it is impossible to get off 
hold. One has to infer what the intended behavior is in this case when 
it isn't stated, based on the stated behaviors in other cases.

The case where you can't get off hold is:

1) Alice and Bob are in a call with sendrecv media.
2) Alice selects hold, sends offer with sendonly.
    Bob answers with recvonly
3) Bob selects hold, sends offer with inactive
    (as stated in 3264), and Alice answers with inactive.
4) Alice deselects hold. What does she offer?

To work this out, I tried to figure out what logic results in offering 
inactive in step (3). At step (3) Bob didn't *want* inactive - he 
presumably wanted sendonly because he doesn't want to receive. Sending 
inactive is an act of self censorship based on what Bob thinks Alice 
wants based on Alice's last offer in step (2). Alice didn't want to 
receive, and Bob doesn't want to receive so the only direction 
compatible with both is inactive.

If that is what UAs are supposed to do, then in step (4) Alice will 
herself want to send and receive, but will want to self censor based on 
what she thinks Bob wants to do. If she bases her assumption of what Bob 
wants to do on what she received in the last offered, then she will not 
that bob didn't want to send or receive, and so she will conclude that 
she must offer inactive.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 4 Dec 2007 19:18:30 -0600

Paul, 

I think we should use common sense.

Alice would just send a=sendrev. If Bob still wants to "not send" he will just "not send". It is not like Alice is forcing Bob to send something. Alice is just saying that she is willing to send and receive.

This paragraph in RFC 3264 IMHO has caused more harm then good. 

It works a lot better if the UAs don't try to "memorize" the state of the previous answer.
I do not think the intent of RFC 3264 was to imply that one should have this bizarre
state changing usage of sendrecv/sendonly/receonly/inactive.

If a UA just sends whatever it is willing to do, without regards to the previous state, I
think it's a lot easier and doesn't suffer from the problems that are pointed out.

It's almost like an errata (or clarification) to RFC 3264.

> Sent: Tuesday, December 04, 2007 17:04
> To: Audet, Francois (SC100:3055)
> Cc: Miguel Garcia; Takuya Sawada; [email-masked]
> Subject: Re: [Sipping] Re: Call Hold in 
> draft-ietf-sipping-sip-offeranswer-04.txt
> 
> 
> 
> Francois Audet wrote:
> >  
> > 
> I just reviewed this again with Miguel. 3264 actually doesn't 
> exactly say what to do to exit hold in this case.
> 
> previously* a recvonly media stream". Its not entirely clear 
> if "was previously" means "was send in the last offer or 
> answer by this UA", or it it means "was what this UA desired 
> before deciding to go on hold.
> 
> It seems clear that at least some people think this means 
> "was send in the last offer or answer by this UA".
> 
> The RFC continues:
> 
> If the earlier thing meant "was send in the last offer or 
> answer by this UA", then it is inconsistent with this latter 
> statement, because the prior answer is dependent on what the 
> other end offered, and so the new offer isn't *separate* from 
> the hold in the other direction.
> 
> I probably overstated the case by saying it is impossible to 
> get off hold. One has to infer what the intended behavior is 
> in this case when it isn't stated, based on the stated 
> behaviors in other cases.
> 
> To work this out, I tried to figure out what logic results in 
> offering inactive in step (3). At step (3) Bob didn't *want* 
> inactive - he presumably wanted sendonly because he doesn't 
> want to receive. Sending inactive is an act of self 
> censorship based on what Bob thinks Alice wants based on 
> Alice's last offer in step (2). Alice didn't want to receive, 
> and Bob doesn't want to receive so the only direction 
> If that is what UAs are supposed to do, then in step (4) 
> Alice will herself want to send and receive, but will want to 
> self censor based on what she thinks Bob wants to do. If she 
> bases her assumption of what Bob wants to do on what she 
> received in the last offered, then she will not that bob 
> didn't want to send or receive, and so she will conclude that 
> she must offer inactive.
> 
> 	Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Dec 2007 21:58:44 -0500

Francois,

We are in violent agreement. What you say is exactly what I wrote in the 
o/a draft. I was just trying to deal with Miguel's complaint that it 
*conflicted* with 3264. It does seemingly conflict, but IMO the text it 
conflicts with is non-normative. What we have agreed to do is let the 
text in the o/a draft stand, add another issue to the list of issues in 
that draft that 3264 should be fixed, and then move on.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 4 Dec 2007 21:16:01 -0600

Good.

For the record: I've had developpers who also did the "bad reading" of 
RFC 3264, and ended up with something that just plainly didn't work. And
the solution was the "enlightened" reading.

So I support Paul.

> Sent: Tuesday, December 04, 2007 18:59
> We are in violent agreement. What you say is exactly what I 
> wrote in the o/a draft. I was just trying to deal with 
> Miguel's complaint that it
> *conflicted* with 3264. It does seemingly conflict, but IMO 
> the text it conflicts with is non-normative. What we have 
> agreed to do is let the text in the o/a draft stand, add 
> another issue to the list of issues in that draft that 3264 
> should be fixed, and then move on.
> 
> 	Paul
> 
> Francois Audet wrote:
> > Paul,
> > 
> > Alice would just send a=sendrev. If Bob still wants to "not 
> send" he will just "not send". It is not like Alice is 
> forcing Bob to send something. Alice is just saying that she 
> is willing to send and receive.
> > 
> > I do not think the intent of RFC 3264 was to imply that one should 
> > have this bizarre state changing usage of 
> sendrecv/sendonly/receonly/inactive.
> > 
> > If a UA just sends whatever it is willing to do, without regards to 
> > the previous state, I think it's a lot easier and doesn't 
> suffer from the problems that are pointed out.
> > 
> >> previously" means "was send in the last offer or answer by 
> this UA", 
> >> or it it means "was what this UA desired before deciding to go on 
> >> hold.
> >>
> answer by 
> >> this UA", then it is inconsistent with this latter 
> statement, because 
> >> the prior answer is dependent on what the other end 
> offered, and so 
> >> the new offer isn't *separate* from the hold in the other 
> direction.
> >>
> >> hold. One has to infer what the intended behavior is in this case 
> >> when it isn't stated, based on the stated behaviors in other cases.
> >>
> >> offering inactive in step (3). At step (3) Bob didn't 
> *want* inactive 
> >> - he presumably wanted sendonly because he doesn't want to 
> receive. 
> >> Sending inactive is an act of self censorship based on what Bob 
> >> thinks Alice wants based on Alice's last offer in step (2). Alice 
> >> didn't want to receive, and Bob doesn't want to receive so 
> the only 
> >> direction compatible with both is inactive.
> >>
> Alice will 
> >> herself want to send and receive, but will want to self 
> censor based 
> >> on what she thinks Bob wants to do. If she bases her assumption of 
> >> what Bob wants to do on what she received in the last 
> offered, then 
> >> she will not that bob didn't want to send or receive, and 
> so she will 
> >> conclude that she must offer inactive.
> >>
> >> 	Paul
> >>