[asterisk-bugs] [JIRA] (ASTERISK-21411) Re-invite without SDP causes one-way audio
Rusty Newton (JIRA)
noreply at issues.asterisk.org
Fri Apr 19 18:05:01 CDT 2013
[ https://issues.asterisk.org/jira/browse/ASTERISK-21411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205495#comment-205495 ]
Rusty Newton edited comment on ASTERISK-21411 at 4/19/13 6:03 PM:
------------------------------------------------------------------
I might need someone else to double-check what I'm thinking here, but I think Asterisk is behaving correctly in 1.8.X I'm not sure about the old 1.4.X. (many things have changed since back then).
In regards to the 1.8 pcap and debug you attached:
If I'm reading RFC3264 correctly..
1.
{quote}
The corresponding media stream in the answer MAY be the same as the
stream in the previous SDP from the answerer, or it MAY be different.
If the updated stream is accepted by the answerer, the answerer
SHOULD begin sending traffic for that stream to the new port
immediately. If the answerer changes the port from the previous SDP,
it MUST be prepared to receive media on both the old and new ports as
soon as the answer is sent. The answerer MUST NOT cease listening
for media on the old port until media arrives on the new port. At
that time, it MAY cease listening for media on the old port. The
same is true for an offerer that sends an updated offer with a new
port; it MUST NOT cease listening for media on the old port until
media arrives on the new port.
{quote}
It sounds like ContactRoute shouldn't be trying to listen on the new port until Asterisk actually starts sending media to it. Therefore in this case even though we are ignoring the new SDP coming with the ACK; the ContactRoute server should continue listening on the same port.
2.
{quote}
Nearly all aspects of the session can be modified. New streams can
be added, existing streams can be deleted, and parameters of existing
streams can change. When issuing an offer that modifies the session,
the "o=" line of the new SDP MUST be identical to that in the
previous SDP, except that the version in the origin field MUST
increment by one from the previous SDP. If the version in the origin
line does not increment, the SDP MUST be identical to the SDP with
that version number. The answerer MUST be prepared to receive an
offer that contains SDP with a version that has not changed; this is
effectively a no-op. However, the answerer MUST generate a valid
answer (which MAY be the same as the previous SDP from the answerer,
or MAY be different), according to the procedures defined in Section
6.
{quote}
The ContactRoute server doesn't change the SDP version in it's ACK from the previous SDP it sent. Asterisk notes in the debug after the first ACK with SDP back from the ContactRoute server:
{quote}
[Apr 12 11:20:35] DEBUG[5817] chan_sip.c: Processing session-level SDP v=0... UNSUPPORTED OR FAILED.
[Apr 12 11:20:35] DEBUG[5817] chan_sip.c: Call 35b845b441d04134b3f9359d05478aa9 responded to our reinvite without changing SDP version; ignoring SDP.
{quote}
I believe if ContactRoute would change the SDP version in the ACK with SDP at frame 5244 that Asterisk would acknowledge it and modify the port for the RTP stream.
I think ASTERISK-17227 is a similar scenario, but with a INVITE with SDP instead of without.
The following option may present a work-around to your issue if you can't affect whether ContactRoute increments the SDP version. This is from the sip.conf sample:
{quote}
;ignoresdpversion=yes ; By default, Asterisk will honor the session version
; number in SDP packets and will only modify the SDP
; session if the version number changes. This option will
; force asterisk to ignore the SDP session version number
; and treat all SDP data as new data. This is required
; for devices that send us non standard SDP packets
; (observed with Microsoft OCS). By default this option is
; off.
{quote}
was (Author: rnewton):
I might need someone else to double-check what I'm thinking here, but I think Asterisk is behaving correctly in 1.8.X I'm not sure about the old 1.4.X. (many things have changed since back then).
In regards to the 1.8 pcap and debug you attached:
If I'm reading RFC3264 correctly..
1.
{quote}
The corresponding media stream in the answer MAY be the same as the
stream in the previous SDP from the answerer, or it MAY be different.
If the updated stream is accepted by the answerer, the answerer
SHOULD begin sending traffic for that stream to the new port
immediately. If the answerer changes the port from the previous SDP,
it MUST be prepared to receive media on both the old and new ports as
soon as the answer is sent. The answerer MUST NOT cease listening
for media on the old port until media arrives on the new port. At
that time, it MAY cease listening for media on the old port. The
same is true for an offerer that sends an updated offer with a new
port; it MUST NOT cease listening for media on the old port until
media arrives on the new port.
{quote}
It sounds like ContactRoute (or whats beyond it) shouldn't be trying to listen on the new port until Asterisk actually starts sending media to it. Therefore in this case even though we are ignoring the new SDP coming with the ACK; the ContactRoute server should continue listening on the same port.
2.
{quote}
Nearly all aspects of the session can be modified. New streams can
be added, existing streams can be deleted, and parameters of existing
streams can change. When issuing an offer that modifies the session,
the "o=" line of the new SDP MUST be identical to that in the
previous SDP, except that the version in the origin field MUST
increment by one from the previous SDP. If the version in the origin
line does not increment, the SDP MUST be identical to the SDP with
that version number. The answerer MUST be prepared to receive an
offer that contains SDP with a version that has not changed; this is
effectively a no-op. However, the answerer MUST generate a valid
answer (which MAY be the same as the previous SDP from the answerer,
or MAY be different), according to the procedures defined in Section
6.
{quote}
The ContactRoute server doesn't change the SDP version in it's ACK from the previous SDP it sent. Asterisk notes in the debug after the first ACK with SDP back from the ContactRoute server:
{quote}
[Apr 12 11:20:35] DEBUG[5817] chan_sip.c: Processing session-level SDP v=0... UNSUPPORTED OR FAILED.
[Apr 12 11:20:35] DEBUG[5817] chan_sip.c: Call 35b845b441d04134b3f9359d05478aa9 responded to our reinvite without changing SDP version; ignoring SDP.
{quote}
I believe if ContactRoute would change the SDP version in the ACK with SDP at frame 5244 that Asterisk would acknowledge it and modify the port for the RTP stream.
I think ASTERISK-17227 is a similar scenario, but with a INVITE with SDP instead of without.
The following option may present a work-around to your issue if you can't affect whether ContactRoute increments the SDP version. This is from the sip.conf sample:
{quote}
;ignoresdpversion=yes ; By default, Asterisk will honor the session version
; number in SDP packets and will only modify the SDP
; session if the version number changes. This option will
; force asterisk to ignore the SDP session version number
; and treat all SDP data as new data. This is required
; for devices that send us non standard SDP packets
; (observed with Microsoft OCS). By default this option is
; off.
{quote}
> Re-invite without SDP causes one-way audio
> ------------------------------------------
>
> Key: ASTERISK-21411
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-21411
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_sip/General
> Affects Versions: 1.8.21.0, 11.2.0
> Environment: CentOS release 5.9 (Final)
> Reporter: Olivier Lambert
> Assignee: Michael L. Young
> Attachments: issue21411.zip
>
>
> A re-invite without SDP is causing the voice to be established in one way. The exact same test done on asterisk 1.4.38 is not giving the issue, creating a two ways audio as it should. Pcaps of the two tests are available at http://www.misterlambert.net/pcaps.zip. Reinvite is located at frame 5127 for the 1.4 test while it is located at frame 7897 for the 1.8. The one way audio is caused by the missing RTP flow visible at frame 5166.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list