[Asterisk-Dev] SIP bug and Polycom phones

Christian Hecimovic checimovic at qworks.ca
Thu Dec 11 12:02:40 MST 2003


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, 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 {
        	snprintf(p->via, sizeof(p->via), "SIP/2.0/UDP 
%s:%d;branch=z9hG4bK%08x", inet_ntoa(p->ourip), ourport, p->branch);
		reqprep(&req, p, "INVITE", 0);

... the rest of the function follows.



More information about the asterisk-dev mailing list