[Asterisk-Dev] Yet more non-RFC compliance with SIP

Christian Hecimovic checimovic at qworks.ca
Thu Feb 26 11:46:57 MST 2004

I believe this was fixed and is in the current CVS.


The branch tag is now incremented with each request.


On Thursday 26 February 2004 10:31, William Waites wrote:
> This time with INFO -- and likely other request methods.
> The scenario is Asterisk talking to eXosip and configured
> to use INFO for DTMF. The first INFO message goes through
> fine, subsequent ones are treated as retransmissions by
> eXosip. Why does this happen? Because the branch tag in
> the VIA header constructed by Asterisk is always the same.
> From RFC3621
> Via
> 	[...]
>    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.
> 	[...]
> In order to make your implementation compliant to this part
> of the specification, you must either:
> 	- not send branch parameters that start with the magic
> 	  cookie "z9hG4bK" that cause other SIP implementations
> 	  to mistakenly believe that Asterisk actually complies
> 	  with RFC3621
> 	- arrange it so that the branch parameter is unique for
> 	  each request as required by RFC3621 setion
> /w

More information about the asterisk-dev mailing list