Re: [Sip-implementors] Usage of "User-Agent" in SIP responses
Thanks, Paul for the detailed response, it more or less matches my own understanding. Do you think for the sake of implementation it can be compressed down to something like that: - if you are making SIP RESPONSE to an incoming request use "Server", otherwise if generating new REQUEST use "User-Agent"? Are there any situations where a locally generated response to a transaction that comes from the outside world might need to use "User-Agent"? My understanding is no, since I don't know any scenarios where UAS issues a request, or UAC generates a response. -Max On Tue, Apr 28, 2020 at 10:35 AM Paul Kyzivat wrote: > On 4/28/20 1:08 PM, Maxim Sobolev wrote: > > Hi, > > > > I've noticed that in the last few years few implementations have gained > > popularity who use User-Agent in both requests and responses. Instead of > > User-Agent in requests and Server in responses which I always believed > > (perhaps incorrectly) to be the right way of doing it. The argument there > > is that "oh, our implementation is an endpont/B2BUA, not an UAS". The > > question hence is it my reading of RFC wrong or theirs? Thanks! > > From 3261: > > The Server header field contains information about the software used > by the UAS to handle the request. > ... > The User-Agent header field contains information about the UAC > originating the request. > > And note that UAC and UAS are *roles*. If you initiating (not > forwarding) a SIP request then you are, at that moment, acting as a UAC. > And if you are initiating (not forwarding) a SIP response then you are > acting as a UAS. In practice it is really hard (probably impossible) to > find anything that is purely a UAC or UAS. > > So the usage you are seeing is *wrong*. > > This gets hazy with B2BUAs. Note that they have no official standing in > 3261. As far as 3261 is concerned something that thinks of itself as a > B2BUA is just two sip devices lashed together. When the B2BUA receives a > request on one side it is acting as a UAS and when it sends it out the > other side it is acting as a UAC. In principle that should be governing > its use of User-Agent and Server on each side. But often they try to act > as a Proxy. (Except when doing something that a Proxy isn't permitted to > do.) I think they hand wave around this by claiming that they are > sometimes acting as Proxies and other times are acting as UAs and so > pick whichever suits them when arguing that they are compliant. > > Thanks, > Paul > ___ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] Usage of "User-Agent" in SIP responses
Hi Paul, Maxim I agree with both and from the implementations i have seen so far, I see User-Agent header being inserted by UE devices like smartphones : e.g. User-Agent: LG IMS client: 6.0 and Server header is inserted by the intermediate servers like CSCF, AS, MRF, etc: E.g. Server: CSCF and softclients use either User-Agent or Server interchangeably Regards Ranjit On Tue, Apr 28, 2020 at 12:35 PM Paul Kyzivat wrote: > On 4/28/20 1:08 PM, Maxim Sobolev wrote: > > Hi, > > > > I've noticed that in the last few years few implementations have gained > > popularity who use User-Agent in both requests and responses. Instead of > > User-Agent in requests and Server in responses which I always believed > > (perhaps incorrectly) to be the right way of doing it. The argument there > > is that "oh, our implementation is an endpont/B2BUA, not an UAS". The > > question hence is it my reading of RFC wrong or theirs? Thanks! > > From 3261: > > The Server header field contains information about the software used > by the UAS to handle the request. > ... > The User-Agent header field contains information about the UAC > originating the request. > > And note that UAC and UAS are *roles*. If you initiating (not > forwarding) a SIP request then you are, at that moment, acting as a UAC. > And if you are initiating (not forwarding) a SIP response then you are > acting as a UAS. In practice it is really hard (probably impossible) to > find anything that is purely a UAC or UAS. > > So the usage you are seeing is *wrong*. > > This gets hazy with B2BUAs. Note that they have no official standing in > 3261. As far as 3261 is concerned something that thinks of itself as a > B2BUA is just two sip devices lashed together. When the B2BUA receives a > request on one side it is acting as a UAS and when it sends it out the > other side it is acting as a UAC. In principle that should be governing > its use of User-Agent and Server on each side. But often they try to act > as a Proxy. (Except when doing something that a Proxy isn't permitted to > do.) I think they hand wave around this by claiming that they are > sometimes acting as Proxies and other times are acting as UAs and so > pick whichever suits them when arguing that they are compliant. > > Thanks, > Paul > ___ > 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
Re: [Sip-implementors] Usage of "User-Agent" in SIP responses
On 4/28/20 1:08 PM, Maxim Sobolev wrote: Hi, I've noticed that in the last few years few implementations have gained popularity who use User-Agent in both requests and responses. Instead of User-Agent in requests and Server in responses which I always believed (perhaps incorrectly) to be the right way of doing it. The argument there is that "oh, our implementation is an endpont/B2BUA, not an UAS". The question hence is it my reading of RFC wrong or theirs? Thanks! From 3261: The Server header field contains information about the software used by the UAS to handle the request. ... The User-Agent header field contains information about the UAC originating the request. And note that UAC and UAS are *roles*. If you initiating (not forwarding) a SIP request then you are, at that moment, acting as a UAC. And if you are initiating (not forwarding) a SIP response then you are acting as a UAS. In practice it is really hard (probably impossible) to find anything that is purely a UAC or UAS. So the usage you are seeing is *wrong*. This gets hazy with B2BUAs. Note that they have no official standing in 3261. As far as 3261 is concerned something that thinks of itself as a B2BUA is just two sip devices lashed together. When the B2BUA receives a request on one side it is acting as a UAS and when it sends it out the other side it is acting as a UAC. In principle that should be governing its use of User-Agent and Server on each side. But often they try to act as a Proxy. (Except when doing something that a Proxy isn't permitted to do.) I think they hand wave around this by claiming that they are sometimes acting as Proxies and other times are acting as UAs and so pick whichever suits them when arguing that they are compliant. Thanks, Paul ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
[Sip-implementors] Usage of "User-Agent" in SIP responses
Hi, I've noticed that in the last few years few implementations have gained popularity who use User-Agent in both requests and responses. Instead of User-Agent in requests and Server in responses which I always believed (perhaps incorrectly) to be the right way of doing it. The argument there is that "oh, our implementation is an endpont/B2BUA, not an UAS". The question hence is it my reading of RFC wrong or theirs? Thanks! -Max 24 Apr 22:09:09.581/235a214a5855df2494b0d55d3ee6d7d5/b2bua[70873]: RECEIVED message from 1.2.3.4:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP [...] From: [...] To: [...] Call-ID: 235a214a5855df2494b0d55d3ee6d7d5 CSeq: 201 BYE User-Agent: XYZ Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Content-Length: 0 ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
