Discussion:
[SR-Users] rtpengine with rejected re-invites to new RTP ports
Jeff Pyle
2014-09-25 16:05:32 UTC
Permalink
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?



Regards,
Jeff
Richard Fuchs
2014-09-29 17:17:59 UTC
Permalink
Post by Jeff Pyle
Hello,
- 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
Jeff Pyle
2014-10-08 04:07:58 UTC
Permalink
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
Post by Richard Fuchs
Post by Jeff Pyle
Hello,
- 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
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Loading...