Christer Holmberg writes: > 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). > 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. > 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. -- juha _______________________________________________ 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
