<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
On 04/21/2010 03:08 PM, Warren Selby wrote:
<blockquote
 cite="mid:w2je7f1293f1004211408z4cf549e3n9cc357aa19feabb0@mail.gmail.com"
 type="cite">
  <div class="gmail_quote">On Wed, Apr 21, 2010 at 3:46 PM, Jay Vocaire
  <span dir="ltr">&lt;<a moz-do-not-send="true"
 href="mailto:jvocaire@innproc.com">jvocaire@innproc.com</a>&gt;</span>
wrote:<br>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Thanks
for the tip, I did just that, and now I am more confused.<br>
    <br>
It does appear as though there is just one call ID (if my assumption
that the "tag=" determines the call.<br>
    <br>
The first time it sends like this:<br>
    <br>
  </blockquote>
  <div>&lt;snip&gt; <br>
  </div>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Asterisk
responds with a SIP/2.0 401 Unauthorized, the phone then comes back
with this:<br>
    <br>
  </blockquote>
  <div>&lt;snip&gt; <br>
  </div>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The
difference is that the CSeq is now 2 and the following line is added:<br>
    <br>
Authorization: Digest username="3271", realm="asterisk",
nonce="393a1b1f", uri=<a class="moz-txt-link-rfc2396E" href="sip:3261@y.y.y.y;user=phone">"sip:3261@y.y.y.y;user=phone"</a>,
response="c8223e261c252c12172982ee661ad307", algorithm=MD5<br>
    <br>
    <br>
So maybe I do have an issue in Asterisk, okay probably. &nbsp;Any clues as
to how to debug? &nbsp;Let me know if need to post more information.<br>
    <br>
  </blockquote>
  <div><br>
This is expected behavior for SIP communications.&nbsp; I see this all the
time when an end point is registering with Asterisk.&nbsp; I think in those
cases, however, it's a REGISTER request, not an INVITE.&nbsp; How is your
sip.conf configured for these end points?<br>
  <br>
Do you have any phones other than the ones experiencing this problem
that you can test with? <br>
  </div>
  </div>
  <br>
</blockquote>
<br>
Yes this is expected behavior on a REGISTER.&nbsp; I didn't think that it
was correct on an INVITE, however on reading RFC 3261, I believe that
Asterisk is correctly responding to the request, needing credentials
from the UA (Polycom).&nbsp; <br>
<br>
<br>
My Ekiga softphone is doing the exact same thing, however it's not
creating the same "2 call" issue that your Polycoms are having.&nbsp; The
Ekiga call setup is not including credentials on the first INVITE,
receives a 401 not authorized, and sends another INVITE with
credentials, and receives a "100 TRYING" from Asterisk.<br>
<br>
This is most likely an issue with the firmware on the Polycom.&nbsp; Bottom
line is that another UA is doing the same thing, the call is setup
properly, and it appears to work.&nbsp; <br>
<br>
I respectfully request that someone smarter than me take a look at this
and verify my conclusions, or correct me accordingly.<br>
<br>
Thanks. <br>
<br>
According to RFC 3261 (note that the RFC uses the word "request"
instead of "register" or "registration request"):<br>
<br>
<pre>"... If a 401 (Unauthorized) or 407 (Proxy Authentication Required)
response is received, the UAC SHOULD follow the authorization
procedures of Section 22.2 and Section 22.3 to retry the request with 
credentials. ..."</pre>
<div id="TixyyLink"
 style="border: medium none ; overflow: hidden; color: rgb(0, 0, 0); background-color: transparent; text-align: left; text-decoration: none;"><br>
Read more: <a
 href="http://www.faqs.org/rfcs/rfc3261.html#ixzz0llyASXyI">http://www.faqs.org/rfcs/rfc3261.html#ixzz0llyASXyI</a><br>
</div>
<br>
" ...<br>
<pre>22.2 User-to-User Authentication

   When a UAS receives a request from a UAC, the UAS MAY authenticate
   the originator before the request is processed.  If no credentials
   (in the Authorization header field) are provided in the request, the
   UAS can challenge the originator to provide credentials by rejecting
   the request with a 401 (Unauthorized) status code.

   The WWW-Authenticate response-header field MUST be included in 401
   (Unauthorized) response messages.  The field value consists of at
   least one challenge that indicates the authentication scheme(s) and
   parameters applicable to the realm.

   An example of the WWW-Authenticate header field in a 401 challenge
   is:

      WWW-Authenticate: Digest
              realm="biloxi.com",
              qop="auth,auth-int",
              nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
              opaque="5ccc069c403ebaf9f0171e9517f40e41"

   When the originating UAC receives the 401 (Unauthorized), it SHOULD,
   if it is able, re-originate the request with the proper credentials.
   The UAC may require input from the originating user before
   proceeding.  Once authentication credentials have been supplied
   (either directly by the user, or discovered in an internal keyring),
   UAs SHOULD cache the credentials for a given value of the To header
   field and "realm" and attempt to re-use these values on the next
   request for that destination.  UAs MAY cache credentials in any way
   they would like.

   If no credentials for a realm can be located, UACs MAY attempt to
   retry the request with a username of "anonymous" and no password (a
   password of "").

   Once credentials have been located, any UA that wishes to
   authenticate itself with a UAS or registrar -- usually, but not
   necessarily, after receiving a 401 (Unauthorized) response -- MAY do
   so by including an Authorization header field with the request.  The
   Authorization field value consists of credentials containing the
   authentication information of the UA for the realm of the resource
   being requested as well as parameters required in support of
   authentication and replay protection.

..."
</pre>
<div id="TixyyLink"
 style="border: medium none ; overflow: hidden; color: rgb(0, 0, 0); background-color: transparent; text-align: left; text-decoration: none;">Read
more: <a href="http://www.faqs.org/rfcs/rfc3261.html#ixzz0llyY2M2W">http://www.faqs.org/rfcs/rfc3261.html#ixzz0llyY2M2W</a><br>
</div>
<br>
</body>
</html>