Subject: [SIP] More inconsistencies and questions

From: Peter Kjellerstedt <[email-masked]>
Date: Thu, 03 Aug 2000 18:08:36 +0200

Here are a couple of more inconcistencies and questions,
this time vs the 2543bis-01 draft (July 26).

1) In 2 (SIP Uniform Resource Locators):

   The "np-queried" value for the user parameter is no longer
   present in the SIP-URL syntax, but it is still referenced
   in the text about telephone-subscriber.

2) In 6.38 (Route):

   The syntax for Route was not uppdated along the changes
   made to the syntax of Record-Route.

3) In 6.47.1 (Via: Requests):

   It is stated that the port specified is the port where the
   user agent wishes to receive responses.  But what if TCP is used
   as transport protocol.  Should it be the port of the local end
   of the TCP connection, or the master TCP port of the user agent?
   I assume it is the latter as the client would otherwise be
   required to open the connection before being able to create the
   message.

4) In 6.47.4 (Via: User Agent and Redirect Servers):

   Is it not better to use the existing TCP connection also if
   the address in the "sent-by" value differs from the source
   address of the packet (i.e., the same as mentioned under the
   third bullet)?  This would effectivly result in adding a
   new bullet after the first stating to use the existing TCP
   connection if available (and removing that text from the
   third bullet).

5) In 6.47.5 (Via: Syntax):

   Should not SCTP and TLS be specified for the transport
   rule too (they are after all defined for the SIP-URL)?

6) In 10.1 (Behavior of SIP Clients and Servers: General Remarks):

   Should not SCTP and TLS be mentioned too, or maybe this
   needs a total check throughout the draft?

7) In 10.3 (Behavior of SIP Clients and Servers: TCP):

   "If the client closes or resets the TCP connection prior to
   receiving the first final response, the server treats this
   action as equivalent to a CANCEL request."

   What if there has been multiple requests for different calls
   over this connection that has not yet received their first
   final response.  Should all of them be cancelled (I suppose so)?

I would like to receive an answer for this before I leave on Monday
for the SIP Bake-Off (if possible :)

//Peter

------------------------------------------------------------
Peter Kjellerstedt       E-Mail: [email-masked]
Axis Communications AB   Phone:  +46 46 272 18 69
Scheelevagen 34          Fax:    +46 46 13 61 30
SE-223 63 LUND           URL:    http://www.axis.com/

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Aug 2000 13:48:12 -0400

>    required to open the connection before being able to create the

No, its the former. The spec says that if TCP is used, the response goes
over the same connection as the request. It is only if the server needs
to reopen a connection to send a response, that it would use the port
number in the Via header.

>    connection if available (and removing that text from the

I agree.

>    final response.  Should all of them be cancelled (I suppose so)?

Yes.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 06 Aug 2000 17:28:20 -0400

> this time vs the 2543bis-01 draft (July 26).

Thanks for your comments.

>    in the text about telephone-subscriber.

Removed.

>    made to the syntax of Record-Route.

Fixed.

>    rule too (they are after all defined for the SIP-URL)?

Added.

>    needs a total check throughout the draft?

Generalized in Section 10.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 06 Aug 2000 17:30:13 -0400

Jonathan Rosenberg wrote:

> >    connection if available (and removing that text from the

Text reworded. Please check the August 6 edition of the spec, available
later today.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Aug 2000 21:46:53 -0400

I still find this text confusing, since it refers to second vias and
isn't really ordered according to what you would do. How about:

1. If sent-protocol indicates TCP, send the response using an existing
TCP connection to the source of the original request.

2. Otherwise, if the Via header field contains a “maddr” parameter,
forward the response to the address listed there,
using the port indicated in “sent-by”, or port 5060 if none is present.
If the address is a multicast
address, the response SHOULD be sent using the TTL indicated in the
“ttl” parameter, or with a TTL
of 1 if that parameter is not present.

3. Otherwise, if it is a receiver-tagged field (Section 6.46.2), send
the response to the address in the “received”
parameter, using the port indicated in the “sent-by” value, or using
port 5060 if none is present.

4. Otherwise, send the response to the address indicated by the
“sent-by”, using the port indicated by "sent-by", or port 5060 if none
is present.

Note that the response to a UDP request is NOT sent back to the port
from which the request came from.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 23 Aug 2000 13:38:17 -0400

> TCP connection to the source of the original request.

Reworded, again.

This leaves out the case 'TCP' and 'no existing connection'.

I also generalized from TCP to 'reliable transport protocol
such as TCP, TLS or SCTP' in line with earlier discussions.