Subject: Re: [Sip] Some comments on rfc2543bis-05

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 05 Jan 2002 03:13:31 -0500

Thanks for your comments. Responses inline.

Terry L Anderson wrote:

> Some comments on rfc2543bis-05.  Most are minor editorial issues (I
> believe).  Perhaps, some have been discuss earlier but I could not find
> them.
> 
> Issue 1:     Section 6 Definitions
> It might be nice to define "Request" and "Response" here.  "Message"
> appears to be used occasionally and I believe means either Request or
> Response but maybe "Message" should also be defined.  And 12.2 defines
> "Refresh Request".  It would be nice to have it included here as well,
> for convenient reference.

Will do. Thanks.

> 
> Issue 2: Section 8.2.3.2 Require
> I just want to confirm that the intention is that even an ACK, BYE or
> CANCEL containing a Require header with option tags that the recipient
> does not support should be rejected with a 420 response. 

BYE, most definitely.

ACK can never be responded to. I would probably argue that ACK should 
never contain a Require or Proxy-Require that wasn't in the request, and 
furthermore that ACK for 420 never contain Require or Proxy-Require with 
option tags not listed in Supported in the 420. The result of these two 
requirements is that you will never get an ACK you need to reject. The 
alternative would be to disallow REquire in ACK altogether. Whilst I 
wouldn't object to that too much for non-2xx, I think it could easily be 
needed in ACK for 2xx, and am reluctant to disallow it.

So, to keep it simple, I think its easiest to disallow Require or 
Proxy-Require in ACK for non-2xx, and allow in in 2xx only for values 
also present in the request. This text would go in section 8.2.3.2.

As for CANCEL, it will NEVER be useful, since responses are hop by hop, 
and you can never resubmit a CANCEL if you are wrong. Therefore, I think 
we should forbid it in CANCEL.

Objections?

> I would assume
> that Require would most often be used in INVITE or REGISTER, but is
> allowed in ACK, BYE and CANCEL.   Should we refuse to BYE or CANCEL the
> call?  I guess this requires the sender to resend without the option tag
> in Require or the call will not be cleaned up.

Correct.

> Issue 3: Section 23 Header Fields: Table 3
> Require has a 'g' in the where column and To has a 'gc(1)'.  I believe
> that the 'g's are left over from bis-04; the meaning for this and the
> other instances have been removed in bis-05.

Good catch, thanks.

> 
> Issue 4: Section 8.2.7
> The last paragraph states: "The same tag MUST be used for all responses
> to that request, both provisional and final".  But since the tag is used
> as part of the dialog ID, isn't it required to be used in subsequent
> requests in the dialog?  This is probably clear from statements
> elsewhere, but since this sentence could be read as implying the
> lifetime of the tag it might be clearer if it read something like "...
> all responses to that request, both provisional and final (and any later
> requests in the same dialog)."

The section at hand is on generation of responses, so it only makes 
sense to have normative behavior for response generation in here. So, 
although it is required to be used in subsequent requests in the dialog, 
that is also clearly described elsewhere. Thus, I think the text is OK 
as it stands.

> 
> Issue 5: Section 9.2
> Related to my issue 2 above.  The last paragraph of 9.2 states that "The
> CANCEL request itself is answered with a 200 (OK) in either case."  This
> might be read to mean in "every" case, but might the response be 420 if
> the CANCEL contained an unsupported option tag in Require?

Based on the above, no. However, CANCEL itself should undergo the 
general uas processing rules first, which would have handled the case of 
generation of 420. Only once that processing is passed, is the cancel 
specific processing here applied. This needs to be stated. I will add that.

> 
> Issue 6: Section 15.1.2
> Similar to issue 5, this section states that "The UAS core MUST generate
> a 2xx response to the BYE", but should it rather generate a 420 if the
> BYE contained an unsupported option tag in Require?

As above, it needs to follow the general UAS processing first. We'll add 
a sentence.

> 
> Issue 7: Section 16.1, 16.6 and 8.2.7
> I am trying to understand if there are cases where a final, non-200
> response received by UAC might contain NO To-tag.  Section 8.2.7 appears
> to require a UAS to add a To-tag to ALL responses.  Section 16.6 appears
> to states that a proxy MUST NOT insert a To-tag into a forwarded
> response that does not have one, but from 8.2.7, it must always have one
> (unless it is received from a non-complying UAS).  I assume that the
> proxy is NOT permitted to remove the tag.  Section 16.1 requires that a
> proxy that is responding directly (generates a response rather than
> forwards one) must behave as a UAS including section 8.2 and so
> apparently must add a To-tag.  So it would seem that a response received
> by the UAC will always have one, except for the case there the UAS in
> non-complying.  Am I missing a case?  (We have seen 4xx's from proxies
> with no To-tag and am trying to determine if this should be expected in
> some cases).

The only case is going to be older rfc2543 proxies, which may not insert 
them. Its not clear from rfc2543 whether proxies need to insert them 
when they generate their own response. Another case is a direct UAC to 
UAS request; there, the response need not have a tag according to 
rfc2543. However, I think rfc2543 is pretty clear that UAS inserts tags 
into all responses if there is more than one via.

> 
> Issue 8:  Section 15
> If I understand this section, a caller should use a BYE to terminate an
> early dialog (rather than a CANCEL) but must not use a CANCEL until some
> response is received. 

Yes.

> Since UAS must add a To-tag to all responses, any
> provisional response other than 100, received by UAC should contain a
> To-tag and hence establish a dialog. 

Yes.

> So it appears that UAC will only
> use CANCEL between receipt of 100 (if received) and some other 1xx.  Is
> this correct?

No. BYE is used to terminate a specific early dialog. If, however, the 
caller wants to end the call, it wants to terminate all dialogs, and so 
would send a CANCEL.

>  Perhaps, stating that here would make it clearer.

Definitely. I see how you would interpret the text this way.

> 
> Issue 9: Early media
> If a proxy forks an INVITE containing SDP, the UAC may receive
> provisional responses from more than one UAS, establishing more than one
> dialog.  If more than one of these contains SDP this would appear to
> establish more than one media stream that might be used to send early
> media to the UAC on the same port.  For example, more than one UAS may
> be sending ringback tones in a media stream and one or more may contain
> a special information tone or voice message.  The RTP packets can be
> distinguished by the source addresses in the headers, but is it stated
> anywhere what the expected behavior of the UAC is?  Should it mix these
> and play all of these to the calling party?  If not, how can it choose
> which to present to the calling party?  Or is early media outside the
> scope of 2543bis?

At the moment, outside the scope of bis. Its documented in 
draft-rosenberg-sip-early-media, which discusses the "legacy" 
implementation you describe above. Note that this document is not stable 
yet. The issue you raise above about disambiguating media from multiple 
sources is one of the problems that draft tries to address.

Thanks for your comments,

Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

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