Subject: [Sipping] call-flows remarks.

From: Aymeric MOIZARD <[email-masked]>
Date: Tue, 02 Jul 2002 15:25:30 +0200

Hi Robert,

Here is a set of remarks and errors I met
while reading the beginning of the
draft-ietf-sipping-call-flows-00.txt.

most remarks are redundant...

Do you want me to merge my possible change in
the original draft. I do not want to
make it if it's not usefull as time is
hard to find!

Aymeric

Comment 1:
++++++++++    line 589:

The To header is the 200 OK for the register does not contains
a tag.

But: (from section 8.2.6.2 Headers and Tags)

"additionally, the UAS MUST add a tag to the To header field in
the response (with the exception of the 100 (Trying) response, in
which a tag MAY be present)."

I see nowhere something saying an exception for this 'tag addition'
can occurs! (well, the 100 Trying...) Also, the registration sample
provided line 12212 of the rfc2543bis-09 does not add a tag! (Figure 9: SIP
Registration Example) I think this is an error in the rfc?

The same apply for the other scenarii.

Comment 3:
++++++++++    line 1235:

Here is the Via header from the ACK for a 200 OK to INVITE!
The branch parameter is the same than the INVITE but the
response was 200 OK! It should be different!

   Via: SIP/2.0/UDP here.com:5060;branch=z9hG4bK74bf9 

Also, I would find it more appropriate to use a higer CSeq
in the INVITE than in the BYE. A higher value for the
first transaction will show users that CSeq is incremented
independantly in each direction. Anyway...

Comment 4:
++++++++++    line 1385:

Situation:

The scenario is the following:
INVITE     CSeq=cseq1 Callid=callid1
407        CSeq=cseq1 Callid=callid1
ACK        CSeq=cseq1 Callid=callid1

re-INVITE  CSeq=cseq1+1 Callid=callid1

The spec recommends to use a CSeq+1 in the RE-INVITE.
I can't find a recommendation on using the same call-id?
is it mandatory?

Comment 5:
++++++++++    line 1690 & 1703 & 1723

Again, the Via in ACK for 200 OK contains the same branch than the 200 OK!
...

Comment 6:
++++++++++    line 1740:

From the darft, line 1740:
"   /* Again, note that the CSeq is NOT 2.  User A and User B maintain 
      their own separate CSeq counts */ "

I think it should be "NOT 3" instead of "NOT 2". (the last request has
a cseq=2)

Comment 7:
++++++++++    line 1759:

The BYE's via contains the same branch used in previous INVITE request!
This is probably a copy paste mistake!

Comment 8:
++++++++++    line ????:

For ACK and request within dialogs, the call-flows draft never
follow one of the rfc recomendation:

line 5711 of the draft-09:

"If this request is already part of a dialog, the proxy
SHOULD insert a Record-Route header field value if it
wishes to remain on the path of future requests in the
dialog.  In normal endpoint operation as described in
Section 12 these Record-Route header field values will not
have any effect on the route sets used by the endpoints."

I guess this is usefull for crash recovery mechanism?

It would be a good idea to always add those "record-route"
headers in ACK, BYE... and any request within dialogs.

Comment 9:
++++++++++    line 2512:

  "After sending a CANCEL to Proxy 1, User A then completes the call to 
   User B using Proxy 2."

In this situation, the proxy 1 is unreachable and no informational
response has been received. In this case, the proxy should not send
a CANCEL. It would be great to inform the reader!

Comment 10:
+++++++++++    line 2586:

It's kind of strange to increment the Call-ID... even if this
is not an error. Woudn't it be better to start with random CSeq
and random Call-ID to avoid users' possible confusion?

Comment 11:
+++++++++++    line 2816:

Again, the ACK has the same branch than the 200 OK.

Comment 12:
+++++++++++    line 2847:

Oups! The BYE forwarded from proxy 2 to User A has the SAME
via-branch than the previous INVITE/200 (and ACK!)

Comment 12:
+++++++++++    line 2959:

In this scenario, the initial INVITE is not sent to a proxy
responsible for the Request-URI.

The spec propose to use a Pre-Route-set in this situation which
appears to never exist in most UAs. I think this scneario should
speak about it and the initial INVITE should contains a pre-route
set:
Route: <sip:alg1.here.com;lr>

Comment 13:
+++++++++++    line 3009:

   Content-Length: 149 

This content length has been modified (147 to 149) but is the
same minus 1 character: it should be changed to 146...

Comment 14:
+++++++++++    line 3009:

---

From: Alan Johnston <[email-masked]>
Date: Mon, 08 Jul 2002 11:04:22 -0500

Hi Aymeric,

Thanks for your comments.  I'm currently working on a version that has 
fixed most of these errors.  The other  that I have comments on are  below.

Thanks,
Alan.

>    Via: SIP/2.0/UDP here.com:5060;branch=z9hG4bK74bf9

I have reused branch IDs, as I have Call-IDs, tags, etc throughout the 
document for ease of editing.  I have placed a more prominent note at the 
start of the document.

>I can't find a recommendation on using the same call-id?

It is not mandatory, but it is a very good idea as nonces can be tied to 
Call-IDs.

>headers in ACK, BYE... and any request within dialogs.

No, if a proxy recognizes a method (such as BYE) and knows that it does not 
establish a dialog, it should not Record-Route.  However, a re-INVITE is a 
different story, as it can be used as a crash recovery mechanism to 
discover a route set.

_______________________________________________
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