Hi Paul, Thank you very much, I got your point.
BR///Rakesh On Thu, Aug 4, 2022 at 10:28 PM Paul Kyzivat <pkyzi...@alum.mit.edu> wrote: > On 8/4/22 11:09 AM, Rakesh wrote: > > Hi Paul, > > > > Thanks for your response. > > Quoting your statement "But it makes no sense to send this unless there > > was a matching prior sip request with the same sip URI." > > > > If I understood correctly the earlier request prior to CANCEL is > > normally a sip INVITE. And in case of INVITE has been sent with the such > > format in FROM header then further requests like CANCEL can send it else > > not. > > > > Do we have any reference on RFC that any SIP entity should not send sip > > From header as like on CANCEL if INVITE has not sent with that way? > > Spend some time understanding section 9 of RFC 3261. > > It doesn't say it is incorrect to send a CANCEL without a prior matching > request. But it specifies what the receiver of the CANCEL should do - > that it should send a 481 response. > > From what little you have said about the situation it sounds like this > may have been sent as part of a test. If so the sender may intentionally > be generating error cases to see if your implementation responds to them > as it should. > > Thanks, > Paul > > > BR///Rakesh > > > > On Thu, Aug 4, 2022 at 8:24 PM Paul Kyzivat <pkyzi...@alum.mit.edu > > <mailto:pkyzi...@alum.mit.edu>> wrote: > > > > On 8/4/22 8:11 AM, Rakesh wrote: > > > Hi Team, > > > > > > I could see in a sip CANCEL message From Header as below > > > > > > From: "test" <sip:ims.test.in > > <http://ims.test.in>>;tag=3bbb9483d215d830c635372f8f181929 > > > > > > is this correct? > > > > Just looking at this, without regard for context, it is valid syntax. > > (The userinfo portion of the sip URI is optional.) > > > > But it makes no sense to send this unless there was a matching prior > > sip > > request with the same sip URI. > > > > Each domain is free to define the userinfo portion of its sip URIs > > as it > > sees fit. This includes whether to support URIs with no userinfo. You > > might want to consult an administrator for ims.test.in > > <http://ims.test.in>. > > > > Thanks, > > Paul > > > > > Normally the From header is sip:user@domain > > > > > > As per ABNF grammar, the above one is also should not be an issue > > as From > > > header but could let me know if I misinterpreted the ABNF grammar? > > > > > > BR///Rakesh > > > _______________________________________________ > > > Sip-implementors mailing list > > > Sip-implementors@lists.cs.columbia.edu > > <mailto:Sip-implementors@lists.cs.columbia.edu> > > > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > <https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors> > > > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@lists.cs.columbia.edu > > <mailto:Sip-implementors@lists.cs.columbia.edu> > > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > <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
