Hi, RFC 3261 does discuss aggregating some things such as authenticate headers (401/407) and Contacts (3xx); however I don't recall if it discusses doing any aggregation for 2xx responses.
However since the subsequent request typically has no guarantee of reaching the same target(s) as the prior OPTIONS (unless maybe by using gruu), I'm not sure how many vendors actually still try to use OPTIONS outside of a dialog for the original purpose. However as discussed within draft-jones-sip-options-ping, vendors do continue to use OPTIONS as a ping mechanism. > -----Original Message----- > From: Paul Kyzivat [mailto:[email protected]] > Sent: Wednesday, July 10, 2013 9:37 AM > To: [email protected] > Subject: Re: [Sip-implementors] Request aggregation and Response > aggregation of OPTIONS of other SIP requests > > It isn't *forbidden* to do this, but it is certainly not normal > behavior. It would be somewhat deceptive, and there is no single one > "right" way to aggregate the capabilities of the two devices. The > likelihood that the result will be beneficial to A or B is slim. > > If you want to achieve this effect, I suggest that the proxy may return > a 3xx with the contacts for device1 and device2. > > Thanks, > Paul > > On 7/10/13 1:47 AM, manju nath wrote: > > Hi All, > > > > Does any one has any idea about request & response aggregation > in SIP > > OPTIONS exchange?? > > I have tried to google it and i found some thing about response > aggregation > > like > > > > " Say there are two users A & B. A has two devices, device1 & device2 > > [multidevice scenario]). A registered both of his devices. When B > performs > > the OPTION exchange with A, proxy in between them will fork the > OPTION > > request to both the device 1 & device 2 of A and gets the responses > from > > them respectively & will aggregate the capabilities of A's both > devices and > > will send a response to B's device." > > > > Is this is correct?? is there any specification which talks about > request & > > response aggregation in SIP. Please help in finding the answer. > > > > Thanks in advance > > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
