In case if INVITE contains Route header then it should be copied in CANCEL request too else it is not needed. CANCEL request is hop by hop and proxies/B2B in-between should take care of forwarding it to the same path where INVITE traveled. Copying Record-Route header as Route in CANCEL is not required.
Anubhav On Thu, Sep 7, 2017 at 2:47 PM, neil corcoran <n...@corcoran.name> wrote: > Hi, > > I can't see a definitive answer in RFC 3261 > > We send an INVITE > we receive 100 Trying > we receive 183 reliable with Route headers and a Contact > we sent PRACK and honour the Route headers and Contact (3262 PRACK == in > dialog message) > we receive 200 for the PRACK > > We then send CANCEL in accordance with > https://tools.ietf.org/html/rfc3261#section-9.1 > > we send this to the same destination as the original INVITE and don't > include the Route headers or from the 183 > > I think this is the right thing to do but I also see CANCEL referred to as > in-dialog so perhaps I'm wrong. Is there anything that I've overlooked that > defines the correct behaviour to take in this instance. > We have a query from a customer that they think that the CANCEL should be > sent with the same Route headers as the PRACK. I'm thinking this could > cause problems. > > Thanks in advance for any assistance > > Neil > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
