[SR-Users] rtpengine with rejected re-invites to new RTP ports

[Jeff Pyle]

Richard,

After quite a bit of testing I can confirm there is no accidental success
here.  With default settings the old RTP flow ceases 30 seconds after the
rejected re-invite.


- Jeff


On Mon, Sep 29, 2014 at 1:17 PM, Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 09/25/14 12:05, Jeff Pyle wrote:
> > Hello,
> >
> > Given the following scenario with Kamailio and rtpengine in the middle:
> >
> > -  call establishes with G.711 RTP
> > -  b-leg re-invites to T.38, indicating a different port number then he
> > is using for G.711
> > -  a-leg refuses the re-invite with a 488
> > -  call continues using G.711 on original port numbers as if re-invite
> > never happened
> >
> > Will Kamailio and rtpengine handle it?
> >
> > Today I have a functional configuration with rtpproxy on another SIP
> > proxy.  It handles every scenario I have tried except this one.
> >  rtpproxy sees the new ports in the re-invite and adjusts its session
> > accordingly.  If the re-invite is rejected, the old media ports are no
> > longer valid through rtpproxy, and the call fails.
> >
> > Is there an approach I can take with Kamailio and rtpengine to allow
> > this scenario to succeed?
>
> This may or may not work with rtpengine. If it does work, it's simply a
> lucky side effect, as this is entirely unsupported and I've never tested
> it myself. Now if you had a final re-invite back to G.711, then that
> would and should most definitely work.
>
> cheers
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20141008/35b1e35a/attachment.html>