[OpenSIPS-Users] Distinction between two forked INVITE received from upstream

Yannick LE COENT yannick.lecoent at nexcom.fr
Thu Jan 21 18:10:14 CET 2010


To simplify the call flow, I omitted the 100 Trying sent upstream by
OpenSIPS for both INVITE (1) and (2).

You will find below the complete call-flow

 

Only one INVITE will be accepted, but I could not guess which one.

 

The upstream proxy provides the REGISTRAR function, thus it forks initial
requests. This proxy is on a private network.

My OpenSIPS is the link between the public and private networks.

 

 

                 openSIPS

                 +------+

--  INVITE(1) -->|      |--- INVITE(1) -->

<-- 100(1) ------|      |

                 |      |

--  INVITE(2) -->|      |--- INVITE(2) -->

<-- 100(2) ------|      |

<-- 180(2) ------|      |<-- 180(2) ------

<-- 200(2) ------|      |<-- 200(2) ------

                 |      |

--  CANCEL(1) -->|      |

<-- 200(CANCEL) -|      |

<-- 487(1) ------|      |

--  ACK(1) ----->|      |

                 |      |

--  ACK(2) ----->|      |--- ACK(2) ----->

                 |      |

                 +------+

                    |

                    |

                 +------+

                 |      |

                 |      |

                 +------+

                 RTP proxy

 

-----------------------------------------------------------

This is an interesting question. The requests should have different tags
.I'm not sure how OpenSIPs handles the individual requests..
 
I'd tend to expect a 491 Request Pending or a 500 Requests Merged. But maybe
that's B2BUA behavior.
 
Since opensips isn't replying to the "second" INVITE, it's almost like it's
absorbing it as a retransmission. I'm not sure what your expected behavior
is, but it seems that you're going to constantly have race conditions on
this and that the outcome will be "random" (ie: does INVITE(1) hit first, or
INVITE(2))
 
What's the larger picture here? Why do you have two INVITEs from the same
call hitting your proxy?
-Brett
 
 
On Thu, Jan 21, 2010 at 8:50 AM, Yannick LE COENT <
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users> yannick.lecoent
at nexcom.fr
> wrote:
 
>  Hello,
> 
> 
> 
> The next figure describes my problem.
> 
> 
> 
>                  openSIPS
> 
>                  +------+
> 
> --  INVITE(1) -->|      |--- INVITE(1) -->
> 
>                  |      |
> 
> --  INVITE(2) -->|      |--- INVITE(2) -->
> 
> <-- 180(2) ------|      |<-- 180(2) ------
> 
> <-- 200(2) ------|      |<-- 200(2) ------
> 
>                  |      |
> 
> --  CANCEL(1) -->|      |
> 
> <-- 200(CANCEL) -|      |
> 
> <-- 487(1) ------|      |
> 
> --  ACK(1) ----->|      |
> 
>                  |      |
> 
> --  ACK(2) ----->|      |--- ACK(2) ----->
> 
>                  |      |
> 
>                  +------+
> 
>                     |
> 
>                     |
> 
>                  +------+
> 
>                  |      |
> 
>                  |      |
> 
>                  +------+
> 
>                  RTP proxy
> 
> 
> 
> I use RTP proxy to relay media streams.
> 
> 
> 
> INVITE (1) and (2) have been forked from an upstream proxy, thus they have
> the same Call-ID and From tag, and a different branch ID.
> 
> INVITE (2) is accepted, but INVITE (1) has no response.
> 
> The upstream proxy cancels INVITE (1).
> 
> 
> 
> In my script, on CANCEL(1) request I close the RTP session, but I should
> not dot that since INVITE(2) has been accepted.
> 
> 
> 
> My questions are:
> 
> How can I know when I received CANCEL(1) that INVITE(2) has been accepted?
> 
> Do I need to use flags? Which ones ?
> 
> 
> 
> Thanks for any help,
> 
> Yannick
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users> 
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20100121/c447a49c/attachment-0001.htm 


More information about the Users mailing list