>>The registrar is non-conforming. It should have failed the request since
Yes, absolutely. My reaction was just because the behaviour was so ridiculous. "SIP in action!!" is just my sarcastic/satirical exclaimation - stuff in the real world doesn't do even the most basics of checks!! * sigh * Maybe I would forgive it if it was new but it isn't. It's a fairly well-known SIP product. Regards, Attila ________________________________ From: Paul Kyzivat [mailto:pkyzi...@cisco.com] Sent: Thu 02/04/2009 19:56 To: Attila Sipos Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] What's the harm in always adding Path at the proxy? (RFC3327 question) Attila Sipos wrote: > Would you believe it? I tried it out and I got: > > 5) the proxy adds Path and adds Requires:path. > The registrar doesn't support it, doesn't copy the Path and doesn't > use it. > > > Welcome to SIP in action!!! I can't tell if you are happy, or what. The registrar is non-conforming. It should have failed the request since it didn't support the required path option. Paul > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzi...@cisco.com] > Sent: 01 April 2009 17:06 > To: Attila Sipos > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] What's the harm in always adding Path at > the proxy? (RFC3327 question) > > If you do as you propose there are good cases and bad cases. > > Good cases: > > 1) the proxy adds Path, but *doesn't* add Requires:path. The registrar > *honors* the Path request, echoing it in the response. And uses it for > future requests. > > 2) the proxy adds Path, but *does* add Requires:path. The registrar > supports it, *honors* the Path request, echoing it in the response. And > uses it for future requests. > > Bad cases: > > 3) the proxy adds Path, but *doesn't* add Requires:path. The registrar > rejects the request, as recommended by RFC 3327. > > 4) the proxy adds Path, but *does* add Requires:path. The registrar > doesn't support the path option, and so rejects the request with 421. > > Whether the bad cases are really bad depends on how essential the proxy > is. If it believes it is so essential that its ok to fail the > registration if it can't get on the Path, then it might as well do so. > > Thanks, > Paul > > > In this case, > > Attila Sipos wrote: >> >> A Path header can be added by a proxy if a UA indicates support for >> "path". >> >> But what harm is there in adding it if "path" isn't supported by the > UA? >> >> I can't see any, except it would screw up a stupid UA implementation >> which cries when it receives unknown SIP headers. >> >> Is that all? >> >> Regards, >> >> Attila >> >> >> _______________________________________________ >> Sip-implementors mailing list >> Sip-implementors@lists.cs.columbia.edu >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
