[reSIProcate] Forking of INVITE request - regarding

[Robert Sparks]

On Nov 28, 2006, at 11:25 AM, Raj wrote:

> Consider the following situation.
>
> 	Adam wants to call Bob, let’s say that Bob is
> registered at three locations, that is, at home, at
> head office and at his branch office. Hence, when Adam
> makes a call, INVITE request is forked by the proxy
> and it reaches all the three destinations. Hence,
> three 200 OK SIP response will be sent back to Adam.

This will only happen when (as you say below) the three phones answer  
at the same time, where
"same time" is the window (measured in milliseconds) between the  
first 200 arriving at  the proxy
and the CANCELs it sends to the other legs making it to the other two  
phones. So, realize when
choosing how to deal with this that it is an edge condition.  
Unfortunately, studies in the traditional
PSTN suggest that it's not that unusual to stimulate this particular  
edge.

Note also that early media (ringback or IVR media) can come from all  
three branches. In this case,
there is no nice short window to save you from this edge condition,  
you'll have to figure out what to do
for the duration of the "ringing" time.

>
> 	Consider the situation, when Bob’s friends answer the
> call at all the three locations at the same time, what
> will happen? Either three media channel will be
> established between them or which two will be
> discarded.
>
> 	Can anyone please clear this?

So, the bad news is that the specs don't tell you what to do with  
this, and there is no current
frontrunner for an "industry best practice". A lot of implementations  
will play media from whatever
source got a packet to them first, discarding the other streams.  
Others have considered making
each leg appear on individual lines, or mixing them into a local ad- 
hoc conference.

Finding a good solution is made more difficult by the lack of  
information that allows you to associate a leg
with a branch. RTCP can eventually give you that, but there are a lot  
of phones out there now that aren't
implementing RTCP yet. A lot of the work going into securing the  
media streams will make this problem
easier to solve.

It's a non-trivial problem and the more folks we have looking for  
good solutions, the better.
Check out the SIP/SIPPING mailing lists for the ongoing conversations.

RjS

>
> With regards
> Raj.
>
>
>
>
> ______________________________________________________________________ 
> ______________
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel