Subject: [SIP] inconsistency in rfc2543bis

From: Lars Berggren <[email-masked]>
Date: Fri, 28 Apr 2000 11:41:27 +0200 (CEST)

Section 10.2.1 :
>10.2.1 Unicast UDP
>Responses are returned to the network address and port listed in the Via
>header field (Section 6.45), not the source address of the request.

While this is true for proxies forwarding a response, it contradicts what
is stated for UA and redirect servers in 6.45.4 :

>   A UAS or redirect server sends a response based on one of the
>   following rules:
>
>        o  If the first Via header field in the request contains a
>          "maddr" parameter, send the response to the multicast address
>          listed there, using the port indicated in "sent-by", or port
>          5060 if none is present. 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. For robustness, responses MUST
>          be sent to the address indicated in the "maddr" parameter even
>          if it is not a multicast address.
>
>        o  If the address in the "sent-by" value of the first Via field
>          differs from the source address of the packet, send the
>          response to the actual packet source address, similar to the
>          treatment for receiver-tagged Via header fields (Section
>          6.40.2).
>
>        o  If neither of these conditions is true, send the response to
>          the address contained in the "sent-by" value. If the request
>          was sent using TCP, use the existing TCP connection if
>          available.

If the intention is that 10.2.1 only applies to proxies forwarding a
response, I think 10.2.1 should be updated to explicitly say that.

/Lars

--
Lars Berggren       <mailto:[email-masked]>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Apr 2000 12:53:37 -0400

I agree this statement in 10.2.1 is very confusing, and probably
incorrect given the most obvious interpretation. It was pointed out to
me during the bakeoff by someone else also. Rules for where to send the
response should ultimately be the same for UAS or a proxy. The rules in
6.45 will result in the response being sent to the source address, and
so the same should apply to proxies. In fact, they do for a response
that a proxy forwards upstream (since the received-by address is used
first, which is the source address when not the same as sent-by). SO, if
a proxy receives a request, and just responds to it directly (rather
than proxying the request and then proxying a response), the response
goes to the source address of the request. If the request is proxied,
and then a response is received which is forwarded, it will end up being
sent to the source address the request originally came in on, since the
construction of the Via header guarantees this.

-Jonathan R.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 28 Apr 2000 19:58:52 -0400

There's another wrinkle: While the server effectively returns the
response to the source *IP address*, it does not necessarily use the
source *port*, at least for UDP. (TCP will try to re-use the same
connection, so it will be the source port in most cases.)

Unfortunately, NAPTs rewrite both address and port and even if we wanted
to fix this, this would break the desirable feature of letting the
client specify the return port (e.g., to have everything arrive on
5060).

I fixed 10.2.1 to refer to the Via rules (I think the confusion in
10.2.1 comes partially from this address/port distinction, where port is
meant).