5 Dec
2019
5 Dec
'19
1:33 p.m.
On Thu, Dec 05, 2019 at 09:37:51AM +0000, Laurent Schweizer wrote:
Hello,
I already see old post about this :
https://opensips.org/pipermail/users/2014-November/030451.html
but I???m interested to know if now they is a solution ????
so the issue is a RE-INVITE rejected (415 Unsupported Media or 488 ) and the RTP port is
changing.
Is that case the old RTP relay (I???m using RTPengine) is destroyed after 30sec.
Any way to restore them ?
I'm confused:
- opensips != kamailio
- rtpproxy != rtpengine
But RFC 3261 states (page 16):
During the session, either Alice or Bob may decide to change the
characteristics of the media session. This is accomplished by
sending a re-INVITE containing a new media description. This re-
INVITE references the existing dialog so that the other party knows
that it is to modify an existing session instead of establishing a
new session. The other party sends a 200 (OK) to accept the change.
The requestor responds to the 200 (OK) with an ACK. If the other
party does not accept the change, he sends an error response such as
488 (Not Acceptable Here), which also receives an ACK. However, the
failure of the re-INVITE does not cause the existing call to fail -
the session continues using the previously negotiated
characteristics. Full details on session modification are in Section
14.
So if this happens with kamailio/rtpengine that is a bug in (I presume) rtpengine.
5 Dec
5 Dec
1:45 p.m.
New subject: RTPengine with rejected RE-INVITE when port is changing
On 05.12.19 11:33, Daniel Tryba wrote:
On Thu, Dec 05, 2019 at 09:37:51AM +0000, Laurent
Schweizer wrote:
RTPEngine itself doesn't send SIP replies. Typically the 415 or 488 are
sent by the endpoints. Kamailio doesn't do it by default, but of course
can do it if explicitely wanted in the kamailio .cfg routing actions. My
guess is that the endpoint sends the 415/488, so all this doesn't have
to do anything with rtpengine/kamailio -- that can be checked by looking
at the sip network traffic on kamailio server to see where 415/488 is
coming from.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com
Hello,
I already see old post about this :
https://opensips.org/pipermail/users/2014-November/030451.html
but I???m interested to know if now they is a solution ????
so the issue is a RE-INVITE rejected (415 Unsupported Media or 488 ) and the RTP port is
changing.
Is that case the old RTP relay (I???m using RTPengine) is destroyed after 30sec.
Any way to restore them ?
I'm confused:
- opensips != kamailio
- rtpproxy != rtpengine
But RFC 3261 states (page 16):
During the session, either Alice or Bob may decide to change the
characteristics of the media session. This is accomplished by
sending a re-INVITE containing a new media description. This re-
INVITE references the existing dialog so that the other party knows
that it is to modify an existing session instead of establishing a
new session. The other party sends a 200 (OK) to accept the change.
The requestor responds to the 200 (OK) with an ACK. If the other
party does not accept the change, he sends an error response such as
488 (Not Acceptable Here), which also receives an ACK. However, the
failure of the re-INVITE does not cause the existing call to fail -
the session continues using the previously negotiated
characteristics. Full details on session modification are in Section
14.
So if this happens with kamailio/rtpengine that is a bug in (I presume) rtpengine.
2 p.m.
New subject: RTPengine with rejected RE-INVITE when port is changing
Hello,
Sorry for the confusion.
The point is the following:
1) call is setup correctly
2) just after one side send a RE-INVITE with a new port and new codec.
3) The other leg reject the RE-INVITE with a 415
During the RE-INVITE, the first RTP relay on RTPengine is removed (with a delay of 30
sec).
As the RE-INVITE with the new port is rejected the current RTP relay is still used, so we
must not delete them.
BR
Laurent
-----Original Message-----
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Daniel-Constantin
Mierla
Sent: jeudi, 5 décembre 2019 11:46
To: sr-users(a)lists.kamailio.org; Daniel Tryba <d.tryba(a)pocos.nl>
Subject: Re: [SR-Users] RTPengine with rejected RE-INVITE when port is changing
On 05.12.19 11:33, Daniel Tryba wrote:
On Thu, Dec 05, 2019 at 09:37:51AM +0000, Laurent
Schweizer wrote:
RTPEngine itself doesn't send SIP replies. Typically the 415 or 488 are sent by the
endpoints. Kamailio doesn't do it by default, but of course can do it if explicitely
wanted in the kamailio .cfg routing actions. My guess is that the endpoint sends the
415/488, so all this doesn't have to do anything with rtpengine/kamailio -- that can
be checked by looking at the sip network traffic on kamailio server to see where 415/488
is coming from.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda --
www.linkedin.com/in/miconda Kamailio World Conference - April 27-29, 2020, in Berlin --
www.kamailioworld.com
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello,
I already see old post about this :
https://opensips.org/pipermail/users/2014-November/030451.html
but I???m interested to know if now they is a solution ????
so the issue is a RE-INVITE rejected (415 Unsupported Media or 488 ) and the RTP port is
changing.
Is that case the old RTP relay (I???m using RTPengine) is destroyed after 30sec.
Any way to restore them ?
I'm confused:
- opensips != kamailio
- rtpproxy != rtpengine
But RFC 3261 states (page 16):
During the session, either Alice or Bob may decide to change the
characteristics of the media session. This is accomplished by
sending a re-INVITE containing a new media description. This re-
INVITE references the existing dialog so that the other party knows
that it is to modify an existing session instead of establishing a
new session. The other party sends a 200 (OK) to accept the change.
The requestor responds to the 200 (OK) with an ACK. If the other
party does not accept the change, he sends an error response such as
488 (Not Acceptable Here), which also receives an ACK. However, the
failure of the re-INVITE does not cause the existing call to fail -
the session continues using the previously negotiated
characteristics. Full details on session modification are in Section
14.
So if this happens with kamailio/rtpengine that is a bug in (I presume) rtpengine.
1814
days inactive
1814
days old
2 comments
3 participants
participants (3)
-
Daniel Tryba -
Daniel-Constantin Mierla -
Laurent Schweizer