[Home]

Summary:ASTERISK-01305: Bad branch id in VIA
Reporter:jht (jht)Labels:
Date Opened:2004-03-27 20:01:30.000-0600Date Closed:2008-01-15 14:50:02.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Our other SIP equipment vendors are complaining that Asterisk is sending an incorrect branch id when it replies to a 407 Auth Request received in response to an attempted SIP Register.

Asterisk is not generating a new branh ID for this reply (it is reusing the one from the previous packet), and therefore the reply appears to be a retransmission rather than a new packet.  This causes the Register with the authentication data from the Asterisk to be ignored/fail.

SIP RFC3261 says:
 The branch parameter value MUST be unique across space and time for
  all requests sent by the UA.  The exceptions to this rule are CANCEL
  and ACK for non-2xx responses.  As discussed below, a CANCEL request
  will have the same value of the branch parameter as the request it
  cancels.  As discussed in Section 17.1.1.3, an ACK for a non-2xx
  response will also have the same branch ID as the INVITE whose
  response it acknowledges.

I haven't checked, but there may be other places where Asterisk is not generating a new branch ID when it should.






Comments:By: Mark Spencer (markster) 2004-03-27 23:10:01.000-0600

Please check my fix in CVS to see if it works properly for you.

More kudos to the SIP authors for more unnecessary and rediculous ways of making the protocol more complicated.
By: jht (jht) 2004-03-28 00:05:18.000-0600

Thanks for the quick update.  I'm compiling now.
By: jht (jht) 2004-03-28 01:11:38.000-0600

Still looks like its reusing the same branch ID -- see log below

Reliably Transmitting:
REGISTER sip:hi-proxy.commpartners.us SIP/2.0
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1a215b79
From: <sip:7029395300@hi-proxy.commpartners.us>;tag=as2a839e1d
To: <sip:7029395300@hi-proxy.commpartners.us>
Call-ID: 6b8b4567327b23c6643c986966334873@64.65.89.226
CSeq: 105 REGISTER
User-Agent: Asterisk PBX
Expires: 120
Contact: <sip:7029395300@64.65.89.226>
Event: registration
Content-Length: 0

(no NAT) to 66.209.88.19:5060


Sip read:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1a215b79
From: <sip:7029395300@hi-proxy.commpartners.us>;tag=as2a839e1d
To: <sip:7029395300@hi-proxy.commpartners.us>;tag=SD38uk799-
Call-ID: 6b8b4567327b23c6643c986966334873@64.65.89.226
CSeq: 105 REGISTER
Contact: <sip:7029395300-g4hdgk58bigq6@66.209.88.18:5060;transport=udp>;expires=300
User-Agent: Asterisk PBX
Event: registration
Proxy-Authenticate: digest realm="Syndeo Corporation", nonce="1080453255dfee5f67838d563cac2c0f0aa7db2579", opaque="80
395b5d2bcfa819c94474665bd4ec87", algorithm="MD5", qop="auth"
Content-Length: 0


11 headers, 0 lines
12 headers, 0 lines
Reliably Transmitting:
REGISTER sip:hi-proxy.commpartners.us SIP/2.0
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1a215b79
From: <sip:7029395300@hi-proxy.commpartners.us>;tag=as2a839e1d
To: <sip:7029395300@hi-proxy.commpartners.us>
Call-ID: 6b8b4567327b23c6643c986966334873@64.65.89.226
CSeq: 106 REGISTER
User-Agent: Asterisk PBX
Proxy-Authorization: Digest username="7029395300", realm="Syndeo Corporation", algorithm="MD5", uri="sip:7029395300-g
4hdgk58bigq6@66.209.88.18:5060", nonce="1080453255dfee5f67838d563cac2c0f0aa7db2579", response="e97f9276ed677d96eead3a
8c1202d7e9"
Expires: 120
Contact: <sip:7029395300@64.65.89.226>
Event: registration
Content-Length: 0

(no NAT) to 66.209.88.19:5060


Sip read:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1a215b79
From: <sip:7029395300@hi-proxy.commpartners.us>;tag=as2a839e1d
To: <sip:7029395300@hi-proxy.commpartners.us>;tag=SD38uk799-
Call-ID: 6b8b4567327b23c6643c986966334873@64.65.89.226
CSeq: 106 REGISTER
Contact: <sip:7029395300-g4hdgk58bigq6@66.209.88.18:5060;transport=udp>;expires=300
User-Agent: Asterisk PBX
Event: registration
Proxy-Authenticate: digest realm="Syndeo Corporation", nonce="1080453255dfee5f67838d563cac2c0f0aa7db2579", opaque="80
395b5d2bcfa819c94474665bd4ec87", algorithm="MD5", qop="auth"
Content-Length: 0


11 headers, 0 lines
12 headers, 0 lines
Reliably Transmitting:
REGISTER sip:hi-proxy.commpartners.us SIP/2.0
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1a215b79
From: <sip:7029395300@hi-proxy.commpartners.us>;tag=as2a839e1d
To: <sip:7029395300@hi-proxy.commpartners.us>
Call-ID: 6b8b4567327b23c6643c986966334873@64.65.89.226
CSeq: 107 REGISTER
User-Agent: Asterisk PBX
Proxy-Authorization: Digest username="7029395300", realm="Syndeo Corporation", algorithm="MD5", uri="sip:7029395300-g
4hdgk58bigq6@66.209.88.18:5060", nonce="1080453255dfee5f67838d563cac2c0f0aa7db2579", response="e97f9276ed677d96eead3a
8c1202d7e9"
Expires: 120
Contact: <sip:7029395300@64.65.89.226>
Event: registration
Content-Length: 0

(no NAT) to 66.209.88.19:5060


Sip read:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1a215b79
From: <sip:7029395300@hi-proxy.commpartners.us>;tag=as2a839e1d
To: <sip:7029395300@hi-proxy.commpartners.us>;tag=SD38uk799-
Call-ID: 6b8b4567327b23c6643c986966334873@64.65.89.226
CSeq: 107 REGISTER
Contact: <sip:7029395300-g4hdgk58bigq6@66.209.88.18:5060;transport=udp>;expires=300
User-Agent: Asterisk PBX
Event: registration
Proxy-Authenticate: digest realm="Syndeo Corporation", nonce="1080453255dfee5f67838d563cac2c0f0aa7db2579", opaque="80
395b5d2bcfa819c94474665bd4ec87", algorithm="MD5", qop="auth"
Content-Length: 0
By: jht (jht) 2004-03-28 01:14:04.000-0600

Forgot to include the header for the log so you can verify which version was running.


$ /usr/sbin/asterisk -vvvvgc
 == Parsing '/etc/asterisk/asterisk.conf': Found
Asterisk CVS-03/27/04-18:41:36, Copyright (C) 1999-2001 Linux Support Services, Inc.
Written by Mark Spencer <markster@linux-support.net>
=========================================================================
 == Parsing '/etc/asterisk/logger.conf': Found
Asterisk Event Logger Started /var/log/asterisk/event_log
By: Mark Spencer (markster) 2004-03-29 03:22:33.000-0600

Okay try again.
By: jht (jht) 2004-03-30 01:27:02.000-0600

I'm compiling to test, but just got this note from our one of our vendors on yet another reason our Asterisk Register is failing:

-- quote --
Thanks for the logs. Syion is expecting to receive the "opaque" parameter in the new REGISTER message, with the same value that it sent out in the initial 407 response.

opaque: "This is an opaque data string passed to the user in a challenge. The user will pass the data string back to the server in a digest response. That allows servers to be stateless. If there is any state they need to maintain between challenge and response, they can pass it to the client using this parameter and read it again later when a digest response comes."

Can Asterisk be configured to include the opaque parameter as well in the REGISTER message when it retries the registration with the required credentials?
--end quote--
By: Mark Spencer (markster) 2004-03-30 02:33:52.000-0600

Is there a section of the RFC describing the "opaque" stuff?
By: jht (jht) 2004-03-30 10:59:06.000-0600

SIP RFC 3261

20.27 Proxy-Authenticate

  A Proxy-Authenticate header field value contains an authentication
  challenge.

  The use of this header field is defined in [H14.33].  See Section
  22.3 for further details on its usage.



Rosenberg, et. al.          Standards Track                   [Page 174]
�
RFC 3261            SIP: Session Initiation Protocol           June 2002


  Example:

     Proxy-Authenticate: Digest realm="atlanta.com",
      domain="sip:ss1.carrier.com", qop="auth",
      nonce="f84f1cec41e6cbe5aea9c8e88d359",
      opaque="", stale=FALSE, algorithm=MD5

--
Its defined in the BNF in the SIP RFC and usage is explained in RFC 2617
in Section 3.2.1
http://www.ietf.org/rfc/rfc2617.txt
By: Mark Spencer (markster) 2004-03-31 03:02:10.000-0600

Okies it's in there now.
By: jht (jht) 2004-03-31 18:08:11.000-0600

Looks like there is a buffer too short somewhere, opaque value is getting truncated in the reply to the 407.




Sip read:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK346e5e98
From: <sip:7029395300@hi-proxy.commpartners.us>;tag=as133b0398
To: <sip:7029395300@hi-proxy.commpartners.us>;tag=SD38uk799-
Call-ID: 6b8b4567327b23c6643c986966334873@64.65.89.226
CSeq: 109 REGISTER
Contact: <sip:7029395300-g4hdgk58bigq6@66.209.88.18:5060;transport=udp>;expires=300
User-Agent: Asterisk PBX
Event: registration
Proxy-Authenticate: digest realm="Syndeo Corporation", nonce="1080773035fc9f5f13a6e424d329e38296096c7404", opaque="bf
df32bc7482df59d8179d0298920b0f", algorithm="MD5", qop="auth"
Content-Length: 0


11 headers, 0 lines
12 headers, 0 lines
Reliably Transmitting:
REGISTER sip:hi-proxy.commpartners.us SIP/2.0
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK6c7734f6
From: <sip:7029395300@hi-proxy.commpartners.us>;tag=as133b0398
To: <sip:7029395300@hi-proxy.commpartners.us>
Call-ID: 6b8b4567327b23c6643c986966334873@64.65.89.226
CSeq: 110 REGISTER
User-Agent: Asterisk PBX
Proxy-Authorization: Digest username="7029395300", realm="Syndeo Corporation", algorithm="MD5", uri="sip:7029395300-g
4hdgk58bigq6@66.209.88.18:5060", nonce="1080773035fc9f5f13a6e424d329e38296096c7404", response="d2126b7f18868ed9ad655a
8528d0db97", opaque="bfdf32bc7482df59d8179
Expires: 120
Contact: <sip:7029395300@64.65.89.226>
Event: registration
Content-Length: 0
By: Mark Spencer (markster) 2004-04-01 01:28:28.000-0600

Okay try now.
By: Mark Spencer (markster) 2004-04-02 00:35:07.000-0600

Did it work?
By: jht (jht) 2004-04-02 02:02:28.000-0600

Tested and awaiting feedback from softswitch vendor -- hopefully will get in the next day or two.
By: Mark Spencer (markster) 2004-04-03 20:58:36.000-0600

What's the story?  Is it fixed?
By: jht (jht) 2004-04-04 01:40:06.000-0600

Looks OK to me, but softswitch is still rejecting.
Awaiting their analysis of the logs.
Hopefully will get something back Mon or Tuesday.
By: jht (jht) 2004-04-04 22:54:18

I've been studying the logs from clients that register sucessfully and reading through http://www.ietf.org/rfc/rfc2617

As I read the RFC, the qop, cnouce, and nc parameters all need to be included in the response to a 407 that includes an qop parameter.

I noticed that the clients able to register sucessfully include these in their replies to a 407 msg.
By: Mark Spencer (markster) 2004-04-05 01:11:43

qop
    Indicates what "quality of protection" the client has applied to
    the message. If present, its value MUST be one of the alternatives
    the server indicated it supports in the WWW-Authenticate header.
    These values affect the computation of the request-digest. Note
    that this is a single token, not a quoted list of alternatives as
    in WWW- Authenticate.  This directive is optional in order to
    preserve backward compatibility with a minimal implementation of
    RFC 2069 [6], but SHOULD be used if the server indicated that qop
    is supported by providing a qop directive in the WWW-Authenticate
    header field.

Clearly it *IS* optional, but they want us to use it if the server says it.  I've done a hack-up job of implementation with some hard coded values (we only support "auth" and we assume we've seen the nonce exactly once) but at least try this and get me a debug.  If it doesn't work, include both the debug of us and one that does work.

Is it any wonder that VoIP is no more widely deploeyd than it is when standards are written like SIP?
By: jht (jht) 2004-04-05 02:10:18

First test worked!
Will test some more (haven't tried calls yet).
By: Mark Spencer (markster) 2004-04-05 15:50:58

Okay please let me know ASAP if this is fixed.  Ready to close this one out.
By: jht (jht) 2004-04-05 19:56:40

Invite auth is failing.
I haven't had time to delveinto it, but at first glance I think the branch ID may not be changing.  May be other issues too.
By: Mark Spencer (markster) 2004-04-06 01:46:49

Okay double check and get back with me ASAP
By: jht (jht) 2004-04-06 02:20:20

I think there are two problems with the Invite Auth sequence.

1) via Branch ID in the original Invite, and the second Invite in response to the 407 msg are the same.

2) The username= field in the Proxy-Authorization: header in the Invite responding to the 407 msg is incorrect.  It has the phone number being called when it should have the same username used in the Register.

Here is the log:

   -- Executing SetCallerID("SIP/3000-3885", "7029395300") in new stack
   -- Executing SetCIDName("SIP/3000-3885", "James Thomspon") in new stack
   -- Executing Dial("SIP/3000-3885", "SIP/18083877665@syndeo") in new stack
We're at 64.65.89.226 port 12024
Answering/Requesting with root capability 4
Answering/Requesting with preferred capability 4
Answering/Requesting with preferred capability 8
Answering/Requesting with preferred capability 2
12 headers, 11 lines
Reliably Transmitting:
INVITE sip:18083877665@hi-proxy.commpartners.us SIP/2.0
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1b182478
From: "James Thomspon" <sip:7029395300@64.65.89.226>;tag=as301945f8
To: <sip:18083877665@hi-proxy.commpartners.us>
Contact: <sip:7029395300@64.65.89.226>
Call-ID: 4996a8652041fa5b5046778d7ee280bc@64.65.89.226
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Date: Mon, 05 Apr 2004 18:06:38 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 231

v=0
o=root 18688 18688 IN IP4 64.65.89.226
s=session
c=IN IP4 64.65.89.226
t=0 0
m=audio 12024 RTP/AVP 0 0 8 3
a=rtpmap:0 PCMU/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=silenceSupp:off - - - -
(no NAT) to 66.209.88.19:5060
   -- Called 18083877665@syndeo


Sip read:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1b182478
From: "James Thomspon" <sip:7029395300@64.65.89.226>;tag=as301945f8
To: <sip:18083877665@hi-proxy.commpartners.us>
Call-ID: 4996a8652041fa5b5046778d7ee280bc@64.65.89.226
CSeq: 102 INVITE


6 headers, 0 lines


Sip read:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1b182478
From: "James Thomspon" <sip:7029395300@64.65.89.226>;tag=as301945f8
To: <sip:18083877665@hi-proxy.commpartners.us>;tag=SD30rsd99-
Call-ID: 4996a8652041fa5b5046778d7ee280bc@64.65.89.226
CSeq: 102 INVITE
Contact: <sip:7029395300@66.209.88.18:5060;transport=udp>
User-Agent: Asterisk PBX
Date: Mon, 05 Apr 2004 18:06:38 GMT
Proxy-Authenticate: digest realm="Syndeo Corporation", nonce="10811895050322fc2f17864a9b33341c3dbab0a5
ef", opaque="585f56bf5ac622ee857ddfdbf6ec0217", algorithm="MD5", qop="auth"
Content-Length: 0


11 headers, 0 lines
Transmitting:
ACK sip:7029395300@66.209.88.18:5060 SIP/2.0
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1b182478
From: "James Thomspon" <sip:7029395300@64.65.89.226>;tag=as301945f8
To: <sip:18083877665@hi-proxy.commpartners.us>;tag=SD30rsd99-
Contact: <sip:7029395300@64.65.89.226>
Call-ID: 4996a8652041fa5b5046778d7ee280bc@64.65.89.226
CSeq: 102 ACK
User-Agent: Asterisk PBX
Content-Length: 0

(no NAT) to 66.209.88.19:5060
We're at 64.65.89.226 port 12024
Answering/Requesting with root capability 4
Answering/Requesting with preferred capability 4
Answering/Requesting with preferred capability 8
Answering/Requesting with preferred capability 2
Reliably Transmitting:
INVITE sip:18083877665@hi-proxy.commpartners.us SIP/2.0
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1b182478
From: "James Thomspon" <sip:7029395300@64.65.89.226>;tag=as301945f8
To: <sip:18083877665@hi-proxy.commpartners.us>
Contact: <sip:7029395300@64.65.89.226>
Call-ID: 4996a8652041fa5b5046778d7ee280bc@64.65.89.226
CSeq: 103 INVITE
User-Agent: Asterisk PBX
Proxy-Authorization: Digest username="18083877665", realm="Syndeo Corporation", algorithm="MD5", uri="
sip:7029395300@66.209.88.18:5060", nonce="10811895050322fc2f17864a9b33341c3dbab0a5ef", response="fcfca
a08df8c97ca9a6d10ee8aca2508", opaque="585f56bf5ac622ee857ddfdbf6ec0217", qop="auth", cnonce="4bb44f3f"
, nc=00000001
Date: Mon, 05 Apr 2004 18:06:38 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 231

v=0
o=root 18688 18689 IN IP4 64.65.89.226
s=session
c=IN IP4 64.65.89.226
t=0 0
m=audio 12024 RTP/AVP 0 0 8 3
a=rtpmap:0 PCMU/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=silenceSupp:off - - - -
(no NAT) to 66.209.88.19:5060


Sip read:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1b182478
From: "James Thomspon" <sip:7029395300@64.65.89.226>;tag=as301945f8
To: <sip:18083877665@hi-proxy.commpartners.us>
Call-ID: 4996a8652041fa5b5046778d7ee280bc@64.65.89.226
CSeq: 103 INVITE


6 headers, 0 lines


Sip read:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1b182478
From: "James Thomspon" <sip:7029395300@64.65.89.226>;tag=as301945f8
To: <sip:18083877665@hi-proxy.commpartners.us>;tag=SD30rsd99-
Call-ID: 4996a8652041fa5b5046778d7ee280bc@64.65.89.226
CSeq: 103 INVITE
Contact: <sip:7029395300@66.209.88.18:5060;transport=udp>
User-Agent: Asterisk PBX
Date: Mon, 05 Apr 2004 18:06:38 GMT
Proxy-Authenticate: digest realm="Syndeo Corporation", nonce="10811895050322fc2f17864a9b33341c3dbab0a5
ef", opaque="585f56bf5ac622ee857ddfdbf6ec0217", algorithm="MD5", qop="auth"
Content-Length: 0


11 headers, 0 lines
Transmitting:
ACK sip:7029395300@66.209.88.18:5060 SIP/2.0
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1b182478
From: "James Thomspon" <sip:7029395300@64.65.89.226>;tag=as301945f8
To: <sip:18083877665@hi-proxy.commpartners.us>;tag=SD30rsd99-
Contact: <sip:7029395300@64.65.89.226>
Call-ID: 4996a8652041fa5b5046778d7ee280bc@64.65.89.226
CSeq: 103 ACK
User-Agent: Asterisk PBX
Content-Length: 0

(no NAT) to 66.209.88.19:5060
We're at 64.65.89.226 port 12024
Answering/Requesting with root capability 4
Answering/Requesting with preferred capability 4
Answering/Requesting with preferred capability 8
Answering/Requesting with preferred capability 2
Reliably Transmitting:
INVITE sip:18083877665@hi-proxy.commpartners.us SIP/2.0
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1b182478
From: "James Thomspon" <sip:7029395300@64.65.89.226>;tag=as301945f8
To: <sip:18083877665@hi-proxy.commpartners.us>
Contact: <sip:7029395300@64.65.89.226>
Call-ID: 4996a8652041fa5b5046778d7ee280bc@64.65.89.226
CSeq: 104 INVITE
User-Agent: Asterisk PBX
Proxy-Authorization: Digest username="18083877665", realm="Syndeo Corporation", algorithm="MD5", uri="
sip:7029395300@66.209.88.18:5060", nonce="10811895050322fc2f17864a9b33341c3dbab0a5ef", response="28ed6
2bfe090a4692b25cd52bd98d130", opaque="585f56bf5ac622ee857ddfdbf6ec0217", qop="auth", cnonce="5f0fd21d"
, nc=00000001
Date: Mon, 05 Apr 2004 18:06:38 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Content-Type: application/sdp
Content-Length: 231

v=0
o=root 18688 18690 IN IP4 64.65.89.226
s=session
c=IN IP4 64.65.89.226
t=0 0
m=audio 12024 RTP/AVP 0 0 8 3
a=rtpmap:0 PCMU/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=silenceSupp:off - - - -
(no NAT) to 66.209.88.19:5060


Sip read:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1b182478
From: "James Thomspon" <sip:7029395300@64.65.89.226>;tag=as301945f8
To: <sip:18083877665@hi-proxy.commpartners.us>
Call-ID: 4996a8652041fa5b5046778d7ee280bc@64.65.89.226
CSeq: 104 INVITE


6 headers, 0 lines


Sip read:
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1b182478
From: "James Thomspon" <sip:7029395300@64.65.89.226>;tag=as301945f8
To: <sip:18083877665@hi-proxy.commpartners.us>;tag=SD30rsd99-
Call-ID: 4996a8652041fa5b5046778d7ee280bc@64.65.89.226
CSeq: 104 INVITE
Contact: <sip:7029395300@66.209.88.18:5060;transport=udp>
User-Agent: Asterisk PBX
Date: Mon, 05 Apr 2004 18:06:38 GMT
Proxy-Authenticate: digest realm="Syndeo Corporation", nonce="10811895050322fc2f17864a9b33341c3dbab0a5
ef", opaque="585f56bf5ac622ee857ddfdbf6ec0217", algorithm="MD5", qop="auth"
Content-Length: 0


11 headers, 0 lines
Transmitting:
ACK sip:7029395300@66.209.88.18:5060 SIP/2.0
Via: SIP/2.0/UDP 64.65.89.226:5060;branch=z9hG4bK1b182478
From: "James Thomspon" <sip:7029395300@64.65.89.226>;tag=as301945f8
To: <sip:18083877665@hi-proxy.commpartners.us>;tag=SD30rsd99-
Contact: <sip:7029395300@64.65.89.226>
Call-ID: 4996a8652041fa5b5046778d7ee280bc@64.65.89.226
CSeq: 104 ACK
User-Agent: Asterisk PBX
Content-Length: 0

(no NAT) to 66.209.88.19:5060
Apr  5 08:06:38 NOTICE[81926]: chan_sip.c:5129 handle_response: Failed to authenticate on INVITE to '"
James Thomspon" <sip:7029395300@64.65.89.226>;tag=as301945f8'
Destroying call '4996a8652041fa5b5046778d7ee280bc@64.65.89.226'
By: Mark Spencer (markster) 2004-04-06 10:03:00

Okay we should bump the branch ID now, but if you want to select a different username, you'll have to specify it in the friend or peer section of sip.conf for the peer you are calling.  There is absolutely no relationship between a register request and a call request.
By: Mark Spencer (markster) 2004-04-06 15:17:15

Again, please get back with me on this ASAP.
By: jht (jht) 2004-04-06 22:22:18

Works!

Thanks much!
By: Digium Subversion (svnbot) 2008-01-15 14:49:13.000-0600

Repository: asterisk
Revision: 2577

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r2577 | markster | 2008-01-15 14:49:12 -0600 (Tue, 15 Jan 2008) | 2 lines

Attempt at incrementing branch (or changing it) at the right places (bug ASTERISK-1305)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=2577
By: Digium Subversion (svnbot) 2008-01-15 14:50:02.000-0600

Repository: asterisk
Revision: 2636

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r2636 | markster | 2008-01-15 14:50:02 -0600 (Tue, 15 Jan 2008) | 2 lines

Bump branch id on INVITE with auth (bug ASTERISK-1305)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=2636