[asterisk-bugs] [Asterisk 0019337]: [patch] Call shows on hold after attended transfer with a Polycom phone
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue May 31 09:38:35 CDT 2011
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=19337
======================================================================
Reported By: remiq
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 19337
Category: Channels/chan_sip/Transfers
Reproducibility: always
Severity: minor
Priority: normal
Status: acknowledged
Asterisk Version: SVN
JIRA: SWP-3492
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): 1.8
SVN Revision (number only!): 319938
Request Review:
======================================================================
Date Submitted: 2011-05-20 10:33 CDT
Last Modified: 2011-05-31 09:38 CDT
======================================================================
Summary: [patch] Call shows on hold after attended transfer
with a Polycom phone
Description:
When I do an attended transfer from a Polycom IP650 the call is
transferring successfully, but the call is not releasing properly on the
phone that is initiating the transfer. Instead the call shows that it is
on hold.
======================================================================
----------------------------------------------------------------------
(0135578) remiq (reporter) - 2011-05-31 09:38
https://issues.asterisk.org/view.php?id=19337#c135578
----------------------------------------------------------------------
According to Adtran, the uri in the Proxy-Authorization header is not
within specs according to the RFC 3261. Here is the response I got from
Adtran #RQST00001208043:
The TA 900 is rejecting the BYE because there is a syntax error in the
Proxy-Authorization header. For reference, here is that header:
Proxy-Authorization: Digest username="322-eng", realm="asterisk",
algorithm=MD5, uri="64.19.145.13", nonce="",
response="eac3218b89666699bb97133fa8966982"
Per RFC 3261 Section 25.1, the digest-uri portion of the header is defined
as follows:
digest-uri = "uri" EQUAL LDQUOT digest-uri-value RDQUOT
Section 22.4 of RFC 3261 defines digest-uri-value as follows:
3. The BNF for digest-uri-value is:
digest-uri-value = Request-URI ; as defined in Section 25
Section 25.1 of RFC 3261 defines Request-URI as follows:
Request-URI = SIP-URI / SIPS-URI / absoluteURI
SIP-URI = "sip:" [ userinfo ] hostport
uri-parameters [ headers ]
SIPS-URI = "sips:" [ userinfo ] hostport
uri-parameters [ headers ]
hostport = host [ ":" port ]
absoluteURI = scheme ":" ( hier-part / opaque-part )
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
Based on these definitions, the uri parameter in the Proxy-Authorization
header is not valid. It would be valid as the following:
uri="sip:64.19.145.13"
which would give a full header that looked like this:
Proxy-Authorization: Digest username="322-eng", realm="asterisk",
algorithm=MD5, uri="sip:64.19.145.13", nonce="",
response="eac3218b89666699bb97133fa8966982"
Issue History
Date Modified Username Field Change
======================================================================
2011-05-31 09:38 remiq Note Added: 0135578
======================================================================
More information about the asterisk-bugs
mailing list