Subject: [Sip] Some comments on rfc2543bis-05

From: Terry L Anderson <[email-masked]>
Date: Thu, 29 Nov 2001 17:09:20 -0500

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.

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

What is the behavior when receiving an ACK with an unsupported option
tag in Require.  There is no response to an ACK so there is no way to
indicate that the tag is unsupported.  Does one ignore the ACK and thus
consider the INVITE response un-ACKed and so close the call? or accept
in spite of the unsupported option?  Perhaps, this should be specified
here.

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.

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

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?

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?

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

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.  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.  So it appears that UAC will only
use CANCEL between receipt of 100 (if received) and some other 1xx.  Is
this correct?  Perhaps, stating that here would make it clearer.

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?

--

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla