[Asterisk-Dev] SIP bug and Polycom phones

[Christian Hecimovic]

Hi,

Polycom phones track the current SIP transaction with the branch number in the 
Via header. When Asterisk does a reinvite to set up a native bridge, it does 
not change the branch number - it's still the magic cookie plus some network 
info plus an unchanging random number stored in sip_pvt.branch. In short, the 
branch number stays the same from one invite to the next.

To get reinvites to work, I made a very simple fix in 
transmit_reinvite_with_sdp(). I incremented the branch number and recreated 
the via field of the sip_pvt struct before making the call to reqprep(). Now 
Polycom phones perform native bridging; sniffing the network shows that the 
RTP streams do not touch the server.

According to RFC 3261, Section 8.1.1.7, changing the branch number for each 
new transaction is the correct behaviour. I guess the question is, are 
reinvites new transactions? Polycom thinks so.

Before I submit this little patch, I would really like to hear from anyone who 
thinks this may destabilise Asterisk with other phones, who assume the branch 
number will stay the same between invites. I do not have any other phones to 
test with. The code is as follows:

static int transmit_reinvite_with_sdp(struct sip_pvt *p, struct ast_rtp *rtp, 
struct ast_rtp *vrtp)
{
	struct sip_request req;
	if (p->canreinvite == REINVITE_UPDATE)
		reqprep(&req, p, "UPDATE", 0);
	else {
		// BEGIN POLYCOM SPECIFIC CODE
        	p->branch++;
        	snprintf(p->via, sizeof(p->via), "SIP/2.0/UDP 
%s:%d;branch=z9hG4bK%08x", inet_ntoa(p->ourip), ourport, p->branch);
		// END POLYCOM SPECIFIC CODE
		reqprep(&req, p, "INVITE", 0);
    	}

... the rest of the function follows.

Thanks,

Christian