> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 17, 2008 11:44 PM > To: Bob Penfield > Cc: [email protected] > Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-199-00.txt > > > Bob Penfield wrote: > >> On the topic of UAS's sending 199, I actually think things will work >> better if they did. I know there has been lots of discussion about >> B2BUAs doing it, but consider a UAS that is aware that it has multiple >> registered contacts (via presence or registration event package or >> other means), it might want to send the 199 to be sure that it does >> reach the UAC (in case the proxy does not support it). > > Bob, I don't understand the point you are making. Can you explain further? > > Are you talking about a case where there is a forking proxy in front of > the UAS, and the proxy doesn't know about 199, and the UAS wants to send > the 199 to give the UAC a warning in case the final response is delayed > by the proxy?
Yes, that is pretty much the case I was considering. > > While there may be some cases where that would be advantageous, in many > others it would just increase the message traffic for every failing > call. And I don't see how the UAS would be able to discern the cases > where it would be advantageous. I guess it could be configured in those > cases where all inbound calls are forked, but how many such cases are there? > If the UAS knows that the AOR has multiple registered contacts, it knows that inbound calls will be forked. In that case, it could send the 199. As long as proxies don't generate 199s in addition to ones they forward, the increased traffic could be limited. Having proxies generate responses on behalf of a UAS is a bit of a violation of the end-to-end principle from a purist point of view. By certainly having only proxies generate 199s would limit the increase in messages. I was just trying to point out that there might be cases where real User Agent would send 199 and not just B2BUAs. > Paul > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
