Juha,
i think 3261 is pretty clear on that (see below). So, if we have two different To-tags, then it must be coming from two different UAs. As we do not support this feature yet, we have to ignore any other reply not having the same to-tag. With Alex's patch, we are dropping the first UA, in favor of the second one, which is anyhow not RFC conform. Basically, there is no good way of handling multiple early dialogs anyway (which audio are we supposed to play?). The only correct behavior here would be to create a second dialog based on the 200 reply, and CANCEL any other dialogs (which is what is meant with "terminate any unconfirmed early dialog"). Any other opinion around? Cheers Raphael. 8.2.6.2 Headers and Tags [...] However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present). This serves to identify the UAS that is responding, possibly resulting in a component of a dialog ID. The same tag MUST be used for all responses to that request, both final and provisional (again excepting the 100 (Trying)). Procedures for the generation of tags are defined in Section 19.3. Juha Heinanen wrote: > Raphael Coeffic writes: > > > The sipctrl plug-in limits this by rejecting other final replies, once > > the first has been received. Indeed, it is not mandatory to have a > > To-tag in a provisional reply, as far as I know. > > raphael, > > to tag may not not be mandatory in 18x response, but if it is there and > IF sems takes it from there, it must make sure that once the dialog has > been finally established by a 2xx response, sems will use to tag from > 2xx rather than from a 18x response. > > -- juha > _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
