<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";
        color:black;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        color:black;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=white lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I appears as though I was a little hasty in saying that it wasn’t
generating two calls. It actually was, but I was doing a poor job of searching
the logs.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I setup a new-to-me IP 6000 with older firmware on it (3.0.2.0927),
and I am not getting the issue. I am going to start upgrading the
firmware on that phone to see when it breaks, then it looks like I will call
Polycom to try to get them to fix the issue.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thanks for the help from everyone on this.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>-Jay<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:windowtext'>From:</span></b><span style='font-size:10.0pt;font-family:
"Tahoma","sans-serif";color:windowtext'>
asterisk-users-bounces@lists.digium.com
[mailto:asterisk-users-bounces@lists.digium.com] <b>On Behalf Of </b>Sean Brady<br>
<b>Sent:</b> Wednesday, April 21, 2010 5:49 PM<br>
<b>To:</b> asterisk-users@lists.digium.com<br>
<b>Subject:</b> Re: [asterisk-users] Odd Issue With Polycom Phones<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><br>
<br>
On 04/21/2010 03:08 PM, Warren Selby wrote: <o:p></o:p></p>
<div>
<p class=MsoNormal>On Wed, Apr 21, 2010 at 3:46 PM, Jay Vocaire <<a
href="mailto:jvocaire@innproc.com">jvocaire@innproc.com</a>> wrote:<o:p></o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>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:<o:p></o:p></p>
<div>
<p class=MsoNormal><snip> <o:p></o:p></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<p class=MsoNormal style='margin-bottom:12.0pt'>Asterisk responds with a
SIP/2.0 401 Unauthorized, the phone then comes back with this:<o:p></o:p></p>
</blockquote>
<div>
<p class=MsoNormal><snip> <o:p></o:p></p>
</div>
<blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;
margin-left:4.8pt;margin-right:0in'>
<p class=MsoNormal style='margin-bottom:12.0pt'>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 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. Any clues as to
how to debug? Let me know if need to post more information.<o:p></o:p></p>
</blockquote>
<div>
<p class=MsoNormal><br>
This is expected behavior for SIP communications. I see this all the time
when an end point is registering with Asterisk. I think in those cases,
however, it's a REGISTER request, not an INVITE. 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? <o:p></o:p></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
Yes this is expected behavior on a REGISTER. 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). <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. 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. Bottom
line is that another UA is doing the same thing, the call is setup properly,
and it appears to work. <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"):<o:p></o:p></p>
<pre>"... If a 401 (Unauthorized) or 407 (Proxy Authentication Required)<o:p></o:p></pre><pre>response is received, the UAC SHOULD follow the authorization<o:p></o:p></pre><pre>procedures of Section 22.2 and Section 22.3 to retry the request with <o:p></o:p></pre><pre>credentials. ..."<o:p></o:p></pre>
<p class=MsoNormal><br>
Read more: <a href="http://www.faqs.org/rfcs/rfc3261.html#ixzz0llyASXyI">http://www.faqs.org/rfcs/rfc3261.html#ixzz0llyASXyI</a><o:p></o:p></p>
<p class=MsoNormal><br>
" ...<o:p></o:p></p>
<pre>22.2 User-to-User Authentication<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> When a UAS receives a request from a UAC, the UAS MAY authenticate<o:p></o:p></pre><pre> the originator before the request is processed. If no credentials<o:p></o:p></pre><pre> (in the Authorization header field) are provided in the request, the<o:p></o:p></pre><pre> UAS can challenge the originator to provide credentials by rejecting<o:p></o:p></pre><pre> the request with a 401 (Unauthorized) status code.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> The WWW-Authenticate response-header field MUST be included in 401<o:p></o:p></pre><pre> (Unauthorized) response messages. The field value consists of at<o:p></o:p></pre><pre> least one challenge that indicates the authentication scheme(s) and<o:p></o:p></pre><pre> parameters applicable to the realm.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> An example of the WWW-Authenticate header field in a 401 challenge<o:p></o:p></pre><pre> is:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> WWW-Authenticate: Digest<o:p></o:p></pre><pre> realm="biloxi.com",<o:p></o:p></pre><pre> qop="auth,auth-int",<o:p></o:p></pre><pre> nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",<o:p></o:p></pre><pre> opaque="5ccc069c403ebaf9f0171e9517f40e41"<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> When the originating UAC receives the 401 (Unauthorized), it SHOULD,<o:p></o:p></pre><pre> if it is able, re-originate the request with the proper credentials.<o:p></o:p></pre><pre> The UAC may require input from the originating user before<o:p></o:p></pre><pre> proceeding. Once authentication credentials have been supplied<o:p></o:p></pre><pre> (either directly by the user, or discovered in an internal keyring),<o:p></o:p></pre><pre> UAs SHOULD cache the credentials for a given value of the To header<o:p></o:p></pre><pre> field and "realm" and attempt to re-use these values on the next<o:p></o:p></pre><pre> request for that destination. UAs MAY cache credentials in any way<o:p></o:p></pre><pre> they would like.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> If no credentials for a realm can be located, UACs MAY attempt to<o:p></o:p></pre><pre> retry the request with a username of "anonymous" and no password (a<o:p></o:p></pre><pre> password of "").<o:p></o:p></pre><pre><o:p> </o:p></pre><pre> Once credentials have been located, any UA that wishes to<o:p></o:p></pre><pre> authenticate itself with a UAS or registrar -- usually, but not<o:p></o:p></pre><pre> necessarily, after receiving a 401 (Unauthorized) response -- MAY do<o:p></o:p></pre><pre> so by including an Authorization header field with the request. The<o:p></o:p></pre><pre> Authorization field value consists of credentials containing the<o:p></o:p></pre><pre> authentication information of the UA for the realm of the resource<o:p></o:p></pre><pre> being requested as well as parameters required in support of<o:p></o:p></pre><pre> authentication and replay protection.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>..."<o:p></o:p></pre>
<p class=MsoNormal>Read more: <a
href="http://www.faqs.org/rfcs/rfc3261.html#ixzz0llyY2M2W">http://www.faqs.org/rfcs/rfc3261.html#ixzz0llyY2M2W</a><o:p></o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</body>
</html>