Subject: [SIP] ACK for 401 responses

From: Harleen Gill <[email-masked]>
Date: Thu, 12 Oct 2000 16:49:37 -0700

In Section "15.1.2 The Authorization Request Header" the following 
statement creates some confusion of whether an ACK message should be sent 
by the UAC when a 401 response is received:

"Not generating nonces avoids the additional set of request, 401 response 
and possibly ACK messages and reduces delay by one round-trip time. "

The use of the word "possibly" suggests that ACKs may or may not be sent 
when a 401 response is received.  What is the recommended SIP procedure?

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Oct 2000 19:55:29 -0400

> when a 401 response is received.  What is the recommended SIP procedure?

INVITE transactions generate ACKs, but OPTIONS and other requests don't,
thus the "possibly".

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

---

From: Neil Deason <[email-masked]>
Date: Fri, 13 Oct 2000 09:37:08 +0100

In testing labs I am seeing a worrying number of UA 
implementations making the same mistake of sending requests
to a Proxy where the Request-URI is in the form 
sip:user@<proxy-address>. I think some of the confusion may
be traced back to early SIP message flows which showed this
behaviour. I urge implementers to rectify this situation as 
we are seeing this cause a great deal of confusion to 
the first commercial adopters of SIP technology. These people 
are not SIP protocol experts and just expect this technology 
to work.

It is often seen when using a local out bound proxy. The 
situation is that the UA takes a configuration parameter 
for the local proxy. You can then dial by keying in just the 
user part of a SIP URL. The UA then builds a complete URL by 
adding the Proxy's address and sends the message to the proxy. 
The Proxy then receives an INVITE of the form 
sip:user@proxy-ip - according to the protocol spec the Proxy 
will route this request to the server at the given IP address.
This is obviously itself so an illegal loop is created. A
simple solution would appear to be to configure these UAs with
a 'default dial domain' and for it to build URLs using this
not the Proxy's address.

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 13 Oct 2000 09:13:35 -0400

> This is obviously itself so an illegal loop is created. A

An outbound proxy for userA can be configured 
to translate upon a received outgoing message 
from known userA however it wishes.  UserA 
dialing *69 on a phone can be sent to outbound 
proxy with Request-URI of *69@outboundProxy-Ip.  
Assuming the outbound proxy knows userA, it can 
change the Request-URI into the last "known" 
user@host that called userA.

> a 'default dial domain' and for it to build URLs using this

I agree that default dial domain can be used 
and does more explicitly inform the proxy that
the request was intended to be processed 
like an outbound-proxy instead of a regular 
proxy.  However I don't see that it should be 
required unless the outbound proxy has problems
with spiraling.

---

From: David Daiker <[email-masked]>
Date: Fri, 13 Oct 2000 09:32:05 -0400 (EDT)

> This is obviously itself so an illegal loop is created. A

I disagree, if the uri points to proxyA, that only implies that
proxyA has access to a location service that can forward this
request (at least 1 hop closer) to 'user'

> a 'default dial domain' and for it to build URLs using this

Sure, but since the proxy is probably linked to the local domain
anyway, I think it's more realistic to configure the proxy with
a 'default dial domain' than force it on every UA that happens to
wander in.

After all, isn't that what proxies are for ? Otherwise, the UA
might as well send the invite directly to the destination.

david

---

From: Neil Deason <[email-masked]>
Date: Fri, 13 Oct 2000 15:46:20 +0100

> user@host that called userA.

According to the SIP spec sip:*69@outboundProxy-Ip 
does not map onto the last incoming caller's sip URL 
this is specialised logic. It may exist but a truly 
interoperable UA must still be able to work if it 
doesn't. 

The point I was really trying to make is that a UA 
should not write Request-URIs out to be the destination 
of where they are being sent in the hostport when using
a local outbound proxy.

Say I want to dial sip:[email-masked] but 
the UA configured with a local outbound proxy setting 
of proxy.this-domain.com actually sends the INVITE 
out as:-

        INVITE sip:[email-masked] SIP/2.0
        To: sip:[email-masked]
        From: sip:[email-masked]        
        ....

This will either result in a 404 response, possibly 
482 if the Proxy sends on to itself, or go to the 
wrong jsmith. If a UA can only send out INVITEs 
with Request-URIs like this it is broken.

Cheers,
Neil.

---

From: "Umesh Sirsiwal" <[email-masked]>
Date: Fri, 13 Oct 2000 10:53:29 -0400

I have a simple question regarding SIP and NAPT. The following is
taken from SIP draft. In this specification, proxies inspect source
IP address, and if that is different then the address in via filed they
add a received attribute, however they do not do a similar thing with
the source port number. I do not understand why? If they can do that
SIP will trverse transparently across NAPTs as well...

-Umesh

        A host behind a network address translator (NAT) or
        firewall may not be able to insert a network address into
        the Via header that can be reached by the next hop beyond
        the NAT. Use of the received attribute allows SIP requests
        to traverse NAT's which only modify the source IP address.
        NAT's which modify port numbers, called Network Address
        Port Translators (NAPTs) will not properly pass SIP when
        transported on UDP, so that an application-layer gateway is

Handley/Schulzrinne/Schooler/Rosenberg                       [Page 75]

Internet Draft                    SIP                     August 6, 2000

        required. When run over TCP, SIP stands a better chance of
        traversing NAPTs, since its behavior is similar to HTTP in
        this case, albeit using different ports.

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 13 Oct 2000 16:37:10 +0100

> SIP will trverse transparently across NAPTs as well...

This has been discussed on the List a number of times.

Basically, it is not reasonable to assume that a client sends
on the same port that it listens on; indeed, for common IP
stacks, this would rule out being able to detect ICMP errors
when utilising UDP as a transport, for example.  Thus, the
source port is quite unlikely to be helpful.

There are other issues, but this is probably the most pressing.

HTH,

 - Jo.

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 13 Oct 2000 12:32:18 -0400

>         From: sip:[email-masked]        

A proxy receiving the above request assumes 
that the user is trying to reach the Request-URI.  
By becoming aware the need to act as an 
outbound proxy, the Request-URI can be changed 
by the outbound proxy.  When any proxy or user 
agent receives the initial INVITE, the user@hostport 
of "To" should only really mean what was supposedly 
dialed/entered to reach you (and call-leg identification).

If the user agent was trying to reach
sip:[email-masked],
it should be in the Request-URI.  And the
 message should be sent to 
proxy.this-domain.com if it wants to use it
as an outbound proxy.

Note: Recent threads on outbound proxies also
define the use "Route" to allow for an outbound
proxy chain.  However I don't think that discussion
has been finalized.