Shinji, thank you I didn't get your first answer, now I do
24.01.2019, 04:43, "OKUMURA Shinji" <ietf.shi...@gmail.com>: > Hi, > > No B doesn't. B has not changed PAI of A. B has just indicated its own ID. > > Regards, > Shinji > > On 2019/01/24 0:04, r...@yandex.ru wrote: >> Thank you >> >> Does B violates some standard changing original PAI value? >> >> 21.01.2019, 11:09, "OKUMURA Shinji" <ietf.shi...@gmail.com>: >>> Hi, >>> >>> RFC3325/9.1 >>> Header field where proxy ACK BYE CAN INV OPT REG >>> ------------ ----- ----- --- --- --- --- --- --- >>> P-Asserted-Identity adr - o - o o - >>> >>> RFC3261/20 says, >>> An empty entry in the "where" column indicates that the header >>> field may be present in all requests and responses. >>> >>> According to the above, PAI may be present in responses of INVITE. >>> >>> And PAI in responses indicates callee's ID. >>> >>> Regards, >>> Shinji >>> >>> On 2019/01/18 22:22, r...@yandex.ru wrote: >>>> Hi everyone >>>> >>>> Could some point to the doc or maybe clarify if B is correct in the >>>> following. >>>> >>>> A sends INVITE to B. There is PAI header, lets say P-Asserted-Identity: >>>> "Alice" <sip:+1...@hostname.com> >>>> >>>> B in reply (SIP/183 and SIP/200) sends for example P-Asserted-Identity: >>>> "Bob" <sip:+4...@abcd.com>, that means PAI header completely differs from >>>> that in INVITE. >>>> >>>> A acts like it doesn't see SIP/183, SIP/200. >>>> >>>> Please advise if changing of PAI in this case is correct. > > _______________________________________________ > 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
