Re: Dual registration without Outbound

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