[Asterisk-Dev] SIP bug and Polycom phones
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 188.8.131.52, 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);
// BEGIN POLYCOM SPECIFIC CODE
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.
More information about the asterisk-dev