Re: Dual registration without Outbound

Paul Kyzivat <[email protected]>
Newsgroups gmane.ietf.sip
Message-ID <[email protected]>

Christer Holmberg wrote:
> Hi, 
> 
>> Trying to register the "same UA" concurrently with two different
> instance ids in an attempt to get parallel forked call attempts via
> different networks is creative but a bit ugly. For one thing 
>> its hard in general to guarantee that the two will be parallel forked.
> And the UA will have to attempt to correlate the two in order to realize
> they are the same and so process correctly. An 
>> SBC between the forking proxy and the UA is likely to disturb the
> CallID, the From, and the caller's Contact address. With those messed up
> the correlation will get difficult.
> 
> IF there is a need to do parallell forking to the "same UA", I think
> it's better to simply allow it in Outbound - instead of trying to find
> hacks on how to get around the current restrictions.
> 
> However, parallell forking in outbound should not be the default
> behavior, because I strongly think that in most cases people only want
> to receive the initial request on a SINGLE flow - no matter if they use
> one or more contacts.

Making this behavior "possible but not default" means that there must be 
two options: "do it", and "don't do it". The choice of which to do would 
need to be encoded somewhere. This matters a lot to the UA, so I think 
this option would have to be encoded as part of the registration 
request. Thus outbound would have to change to accommodate it.

In any case, changing the mechanism for requesting this behavior 
wouldn't really change the issues I raised about detecting when the same 
call is delivered via both paths.

	Thanks,
	Paul

> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.