Hi, >>I don't think the spec is broken. I think the spec was >>written based on the assumption that a UA instance is not >>interested in receiving an INVITE multiple times in >>parallel (the UA will return 484 for all but one INVITE) - >>which I don't think is desired even in normal forking scenarios - > >the assumption and your conclusion is plain wrong. in the >example i gave, it is very useful and desired that if wlan >connectivity works, phone gets the invite about 10 seconds >faster than over gprs and the call id free. when second >invite comes, my phone rejects it (i don't remember the code, >but that doesn't really matter to me).
484. >>but that it should be possible to, if one flow is down, >>choose another flow to reach the UA (read: serial forking). > >cannot do that it the other flow is not reachable through the >proxy and the other proxy to which the contact was registered >is down. this is because the contact was not registered with >both due to the brain damage of ob draft and its instance-id business. If specs had brains they would write themselves for us... :) >>And, IF you would use two instance-ids (as proposed by >>Dean), why does the forking proxy need to know whether >>they belong to the same UA or not? Why doesn't it simply >>do paralell forking? > >the proxy does not, but i don't want to complicate >configuration of the UA simply in order to cope with the >brain damage of ob draft. also, don't want that the UA has >to send two invites for one contact each. Why would the UA have to send two INVITEs just because it uses different instance-ids? Regards, Christer _______________________________________________ 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
