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

From: Miguel Garcia <[email-masked]>
Date: Wed, 28 Nov 2007 10:40:09 +0200

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.

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: Wed, 28 Nov 2007 08:28:32 -0500

Miguel,

>    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