Sorry - I meant the question was asked of me in terms of how our proxy would behave - would it issue a challenge to the sendonly INVITE from Phone B vs. would it simply allow the routing to Phone A on the grounds that "we are in a dialog already". The grounds for their asking appear to be the network round trips not doing this might save when putting on hold for MOH etc.
My view (which I think I'm still holding to based on what you all said) is that the proportion of INVITEs that are sendonly are so low that this: a) would not "save" anything significant in resource / processing terms along that portion of the signalling path b) could open up a large replay hole so today our proxy challenges all sendonly INVITEs which I hope is the "more correct answer". As Paul says this question could equally apply to several / many in dialog requests. Thanks for all your help. -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: 28 January 2008 14:11 To: Steve Langstaff Cc: SCG2; [email protected] Subject: Re: [Sip-implementors] Challenging a sendonly INVITE The question is a little too narrow. The same issues apply to any in-dialog request. Steve makes a good point. But practically speaking authentication is rarely done on in-dialog requests. Bypassing it assumes that the dialog id is only known to the parties on the signaling path, even though this might not be true. In most cases, in the original scenario here Phone A would not share a secret with Phone B that could be used for authentication. So if Phone A issues a challenge there is a strong likelihood that it will fail. This wouldn't necessarily cause the call to fail, but wouldn't help. BUT, if Phone A *does* issue a challenge like this, then of course Phone B should properly respond to it if it has the proper credentials to do so. Paul Steve Langstaff wrote: > How do you know it *really* is phone B that is asking for the HOLD? > >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On >> Behalf Of SCG2 >> >> Is there any circumstance at all where it makes sense to >> challenge an INVITE which is putting a call on hold? >> >> I can find nothing in 3264 that suggests it, but wondered if: >> >> Phone A -> Phone B (in doing so phone A may have been authenticated) >> >> Phone B later goes to put phone A on hold > > _______________________________________________ > 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
