branch id is not unique for subsequent REGISTRATION transactions

[GoogleCodeExporter]

We have tried to use Sipdroid with our SoftSwitch but it can not
authenticate the REGISTRATION because the branch id is not changed by
Sipdroid when resending REGISTRATION request with authentication
information and so our SoftSwitch identifies it as the same transaction as
the original REGISTRATION request and simply sends back the stored reply.

For the first REGISTRATION request from Sipdroid we answer a 401
Unauthorized and that reply terminates the transaction, so the next
REGISTRATION request with authentication information must have a different
branch id!

Original request:
REGISTER sip:deverto.com SIP/2.0
Via: SIP/2.0/UDP
127.0.0.1:5060;rport=5060;branch=z9hG4bK47254;received=212.40.113.58
Max-Forwards: 70
Contact: <sip:huhha@127.0.0.1>
To: <sip:huhha@deverto.com>
From: <sip:huhha@deverto.com>;tag=z9hG4bK12344022
Call-ID: 854194088806@127.0.0.1
CSeq: 1 REGISTER
Expires: 3600
User-Agent: mjsip stack 1.6
Content-Length: 0

Our reply:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
127.0.0.1:5060;rport=5060;branch=z9hG4bK47254;received=212.40.113.58
To: <sip:huhha@deverto.com>;tag=6f65be3c
From: <sip:huhha@deverto.com>;tag=z9hG4bK12344022
Call-ID: 854194088806@127.0.0.1
CSeq: 1 REGISTER
WWW-Authenticate: Digest
realm="deverto.com",algorithm=MD5,nonce="4a0420aab3423b1951c080608ef08768ea44ca2
5",qop="auth",o
paque="",stale=false
Content-Length: 0

----------------
New REGISTER request from Sipdroid:

REGISTER sip:deverto.com SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5060;rport;branch=z9hG4bK47254
Max-Forwards: 70
To: <sip:huhha@deverto.com>
From: <sip:huhha@deverto.com>;tag=z9hG4bK12344022
Call-ID: 854194088806@127.0.0.1
CSeq: 2 REGISTER
Contact: <sip:huhha@127.0.0.1>
Expires: 3600
User-Agent: mjsip stack 1.6
Authorization: Digest username="huhha", realm="deverto.com",
nonce="4a0420aab3423b1951c080608ef08768ea44ca25", uri="sip:d
everto.com", algorithm=MD5, opaque="", qop=auth,
response="6fd1a78a6ed447d6c3a9baf077013d97"
Content-Length: 0

Notice that the branch id is the same.

If the branch id starts with the magic cookie "z9hG4bK" (as in this case),
then it must be unique for every transaction.

See rfc 3261 for further details.

Original issue reported on code.google.com by HubaGas...@gmail.com on 8 May 2009 at 12:51

[GoogleCodeExporter]

Issue 149 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 2 Oct 2009 at 8:42

[GoogleCodeExporter]

anyone has a fix for this ??? I have added a patch to registerAgent.java
I am not sure the other message invite/subscribe should be treated same if 
authentication is reqired.

    private boolean processAuthenticationResponse(TransactionClient transaction,
            Message resp, int respCode){
        if (attempts < MAX_ATTEMPTS){
            attempts++;
            //xiaoyu add to make unique branch id
            Message req = transaction.getRequestMessage();
            req.setCSeqHeader(req.getCSeqHeader().incSequenceNumber());
            ViaHeader vh=req.getViaHeader();
            String  oldbranch=vh.getBranch();
            String  newbranch = SipProvider.pickBranch();
            vh.setBranch(newbranch);    
            android.util.Log.e("RegisterAgent","oldbranch="+oldbranch+" 
newbranch="+newbranch);
            req.addViaHeader(vh);
            if (handleAuthentication(respCode, resp, req)) {
                TransactionClient t = new TransactionClient
(sip_provider, req, this);

                t.request();
                return true;
            }
        }
        return false;
    }

Original comment by yuxiao...@gmail.com on 4 Dec 2009 at 6:59

[GoogleCodeExporter]

I've added your patch to include it into next release.

Original comment by pmerl...@googlemail.com on 11 Dec 2009 at 11:29

• Changed state: FutureRelease

[GoogleCodeExporter]

Original comment by pmerl...@googlemail.com on 14 Dec 2009 at 8:54

• Changed state: Fixed

[GoogleCodeExporter]

Issue 290 has been merged into this issue.

Original comment by pmerl...@googlemail.com on 21 Jan 2010 at 2:43