RE: Ack not arriving
Jeroen Van Bemmel <[email protected]>
| Newsgroups | gmane.comp.voip.nist-sip |
|---|---|
| Message-ID | <[email protected]> |
Ranga, ACK for 2xx should have different branch, rest should have same branch. Since the INVITE ST should be destroyed upon 2xx, it should not block the ACK even when the sender uses a wrong branch This is a good test case: the ST is kept alive to catch retransmitted INVITEs, but after 2xx it should not block ACKs Regard, Jeroen -----Oorspronkelijk bericht ----- Van: "M. Rangnathan" <[email protected]> Aan: "Gal Ben-Yair" <[email protected]> CC: [email protected] Verzonden: 11-7-06 16:36 Onderwerp: Re: [nist-sip] Ack not arriving Gal, Yes the ACK must have a different Branch ID. Otherwise, it winds up matching the INVITE client transaction and since that transaction is complete, it gets dropped. One can gete around this I suppose as there are a lot of buggy clients around that dont do this but I fear other things will start breaking. Perhaps I will make this a stack configurable property that allows such erroneous ACKs through. I will get around to this hack in a few days. Any comments on this Jeroen? Possible gotchas? Ranga Gal Ben-Yair wrote: >Hi Ranga, > >Thanks for the help. >Unfortunately, the ACK arrives from an external source not under my control. >I receive an INVITE, reply with OK and receive the ACK. >So you are saying that the ACK MUST have a different branch id than that of >the INVITE? Is there no way around this? > >Thanks, > Gal