[jitsi-dev] weird offer-answer behaviour with multiple streams (bug)


#1

Hello,

I noticed a weird behaviour of Jitsi (on Linux, 2.5.5065) with regards
to offer/answer if I enable SDES/SRTP and SAVP Optional (RTP/SAVP
first, then RTP/AVP). This may look like a corner case first, but
possibly it actually hints at a source of further interop errors with
multiple streams, so it might be worth looking at (try it out:
sip:gong@iptel.org, see below).

Jitsi sends two streams in the offer, one RTP/SAVP, one RTP/AVP, both
with the same port:

v=0
o=jitsi 0 0 IN IP4 192.168.5.110
s=-
c=IN IP4 192.168.5.110
t=0 0
m=audio 5020 RTP/SAVP 96 9 97 98 100 102 0 8 103 3 104 101
a=rtpmap:96 opus/48000/2
...
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:2FxMJRIcuX0DgarLy33wjCMuOVHjK372k/qwA8AD
...
m=audio 5020 RTP/AVP 96 9 97 98 100 102 0 8 103 3 104 101
a=rtpmap:96 opus/48000/2
...

now, if the answer looks like this, which seems to me the proper way
(first, RTP/SAVP, stream refused/inactive, second stream accepted):
v=0
o=sems 1141772649 2040895607 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 0 RTP/SAVP 96
a=inactive
m=audio 10006 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=direction:both

Jitsi doesn't open the port 5020, and does not send anything.

If, on the other hand, I accept the first stream incorrectly, with
RTP/AVP:
v=0
o=sems 1407684341 716534326 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=direction:both
m=audio 0 RTP/AVP 96
a=inactive

everything works, jitsi talks to me (well, echo gives fancy feedback
loops).

I didn't really get anything meaningful out of the logs. So I set this
up somewhere, and it's reachable as sip:gong@iptel.org for jitsi devs
to try (at least for a while); the first version, proper OA on the
'gong' side.

Stefan


#2

Hey

This is somewhat to be expected. The optional setting was/is a workaround for other ill-behaving clients that cannot deal with SAVP as a profile indicator. The two declared streams are essentially the same (like a copy/paste) and it would not be possible to accept both (or in a video case all four) of them. Not sure if I remember correctly now, but the AVP-Stream contains the a=crypto as well.

Other than to avoid the 'optional'-setting, I don't know what I could recommend you.

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

Le 24.02.2014 à 00:56, "Stefan Sayer" <stefan.sayer@googlemail.com> a écrit :

Hello,

I noticed a weird behaviour of Jitsi (on Linux, 2.5.5065) with regards
to offer/answer if I enable SDES/SRTP and SAVP Optional (RTP/SAVP
first, then RTP/AVP). This may look like a corner case first, but
possibly it actually hints at a source of further interop errors with
multiple streams, so it might be worth looking at (try it out:
sip:gong@iptel.org, see below).

Jitsi sends two streams in the offer, one RTP/SAVP, one RTP/AVP, both
with the same port:

v=0
o=jitsi 0 0 IN IP4 192.168.5.110
s=-
c=IN IP4 192.168.5.110
t=0 0
m=audio 5020 RTP/SAVP 96 9 97 98 100 102 0 8 103 3 104 101
a=rtpmap:96 opus/48000/2
...
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:2FxMJRIcuX0DgarLy33wjCMuOVHjK372k/qwA8AD
...
m=audio 5020 RTP/AVP 96 9 97 98 100 102 0 8 103 3 104 101
a=rtpmap:96 opus/48000/2
...

now, if the answer looks like this, which seems to me the proper way
(first, RTP/SAVP, stream refused/inactive, second stream accepted):
v=0
o=sems 1141772649 2040895607 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 0 RTP/SAVP 96
a=inactive
m=audio 10006 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=direction:both

Jitsi doesn't open the port 5020, and does not send anything.

If, on the other hand, I accept the first stream incorrectly, with
RTP/AVP:
v=0
o=sems 1407684341 716534326 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10000 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=direction:both
m=audio 0 RTP/AVP 96
a=inactive

everything works, jitsi talks to me (well, echo gives fancy feedback
loops).

I didn't really get anything meaningful out of the logs. So I set this
up somewhere, and it's reachable as sip:gong@iptel.org for jitsi devs
to try (at least for a while); the first version, proper OA on the
'gong' side.

Stefan

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

Hey Ingo,

o Ingo Bauersachs on 02/24/2014 06:15 AM:

Hey

This is somewhat to be expected. The optional setting was/is a workaround for other ill-behaving clients that cannot deal with SAVP as a profile indicator. The two declared streams are essentially the same (like a copy/paste) and it would not be possible to accept both (or in a video case all four) of them. Not sure if I remember correctly now, but the AVP-Stream contains the a=crypto as well.

Other than to avoid the 'optional'-setting, I don't know what I could recommend you.

thanks for the info, I can avoid 'optional' without problems. Still
it's not really good to interop with ill-behaving peers but to not
interop with properly behaving peers.

Best Regards
Stefan


#4

Hey Stefan,

Hey Ingo,

o Ingo Bauersachs on 02/24/2014 06:15 AM:

Hey

This is somewhat to be expected. The optional setting was/is a workaround for other ill-behaving clients that cannot deal with SAVP as a profile indicator. The two declared streams are essentially the same (like a copy/paste) and it would not be possible to accept both (or in a video case all four) of them. Not sure if I remember correctly now, but the AVP-Stream contains the a=crypto as well.

Other than to avoid the 'optional'-setting, I don't know what I could recommend you.

thanks for the info, I can avoid 'optional' without problems. Still
it's not really good to interop with ill-behaving peers but to not
interop with properly behaving peers.

I don't believe anyone is defending this. The point is that using multiple streams for this was a hack. A work around and not an intended feature.

Multiple streams in SDP are something quite ill-defined that's handled differently by different clients.

The situation is supposed to be clarified by plan unified at MMUSIC ... but I am not holding my breath.

Eventually, I expect everyone would simply start supporting RTP/SAVPF (for WebRTC compliance) and/or make the encryption choice based on presence of a=crypto attributes.

From that perspective, while what you describe is indeed an inconsistency, I don't exactly expect hoards of developers to rush on fixing it.

Emil

···

On 24.02.2014, at 11:54, Stefan Sayer <stefan.sayer@googlemail.com> wrote:

Best Regards
Stefan

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#5

thanks for the info, I can avoid 'optional' without problems. Still
it's not really good to interop with ill-behaving peers but to not
interop with properly behaving peers.

I don't believe anyone is defending this. The point is that using multiple
streams for this was a hack. A work around and not an intended feature.

Multiple streams in SDP are something quite ill-defined that's handled
differently by different clients.

The situation is supposed to be clarified by plan unified at MMUSIC ...

but I

am not holding my breath.

Eventually, I expect everyone would simply start supporting RTP/SAVPF (for
WebRTC compliance) and/or make the encryption choice based on presence of
a=crypto attributes.

From that perspective, while what you describe is indeed an inconsistency,

I

don't exactly expect hoards of developers to rush on fixing it.

I quickly looked over the code: it would probably be sufficient to only mark
a media type (audio/video) as seen, if it isn't inactive.
(CallPeerMediaHandlerSipImpl#createMediaDescriptionsForAnswer, line 536).
But I neither have the time nor the resources (other softclients, a Kamailio
server, Snom and Cisco hardphones) to test it.

Emil

Ingo


#6

o Ingo Bauersachs on 02/24/2014 08:44 PM:

thanks for the info, I can avoid 'optional' without problems. Still
it's not really good to interop with ill-behaving peers but to not
interop with properly behaving peers.

I don't believe anyone is defending this. The point is that using multiple
streams for this was a hack. A work around and not an intended feature.

Multiple streams in SDP are something quite ill-defined that's handled
differently by different clients.

The situation is supposed to be clarified by plan unified at MMUSIC ...

but I

am not holding my breath.

Eventually, I expect everyone would simply start supporting RTP/SAVPF (for
WebRTC compliance) and/or make the encryption choice based on presence of
a=crypto attributes.

From that perspective, while what you describe is indeed an inconsistency,

I

don't exactly expect hoards of developers to rush on fixing it.

gotta love these euphemisms :slight_smile:

I quickly looked over the code: it would probably be sufficient to only mark
a media type (audio/video) as seen, if it isn't inactive.
(CallPeerMediaHandlerSipImpl#createMediaDescriptionsForAnswer, line 536).
But I neither have the time nor the resources (other softclients, a Kamailio
server, Snom and Cisco hardphones) to test it.

sip:gong@iptel.org is still running.

Here's another weird one: apparently, if the any crypto suite in SDES
is unknown to jitsi, the call fails ('unknown crypto suite'),

INVITE:

v=0
o=sems 32603063 488686631 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10000 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=crypto:1 AES_CM_256_HMAC_SHA1_80
inline:4SjMFOJog437vwu1tqrslWLXRIu95bGOL2U7OcDr
a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:njzu61jyXlG7rWF3afljmTgbbh0zjwJwYNrKxheL
a=crypto:3 AES_CM_128_HMAC_SHA1_32
inline:3WPY8nxETDCj4gbJQkXmK6VT69xTi6xaLYKOwSka
a=direction:both
m=audio 10002 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=direction:both

fails with

SIP/2.0 488 Not Acceptable here
Via: SIP/2.0/UDP 192.168.5.110:5062;branch=z9hG4bKNO2T~aom;rport=5062
CSeq: 10 INVITE
Call-ID: 37A3A12B-530E41A10004BA59-99D77700
From:
<sip:callgen@callgen.example.net>;tag=595E005B-530E41A10004BA48-99D77700
Contact: "jitsi"
<sip:jitsi@192.168.5.110:14780;transport=udp;registering_acc=192_168_5_110>
User-Agent: Jitsi2.5.5065Linux
Content-Length: 0

the same with
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:ERI+A/NVEKE8iaR0RQ1qLu+ED5NMSE7kQkSQ3i9K
a=crypto:2 AES_CM_256_HMAC_SHA1_80
inline:sNuiquKHawzbvoSSJDiQyZemZ7Jxbjbz2WmbnAet
a=crypto:3 AES_CM_128_HMAC_SHA1_32
inline:DxbmxbYlxI5TJY6zMBTEPjuDlcn0s2ufDzAtqRUY

while an offer with known suites only:

v=0
o=sems 1645013317 1988569319 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10004 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:eM/ad9cTY53EGIdvm6DRmLNLgW4k+SFHcqyb2D9y
a=crypto:2 AES_CM_128_HMAC_SHA1_32
inline:dOdFO3Rf5in0lBNHrhWKtzaMyFvstmwH9UwroUjq
a=direction:both
m=audio 10006 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=direction:both

is happily accepted:

v=0
o=jitsi 0 0 IN IP4 192.168.5.110
s=-
c=IN IP4 192.168.5.110
t=0 0
m=audio 5014 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WJ8yuA55Y7LRxTvfbkaUypX/2G+/kBe63kFu7WNm

I mean, that's the idea of negotiation, no? Or do you spot anything
else wrong in the offer above?

(btw, the answer must contain as many m-lines as the offer; you should
reject the other streams).

If you'd need some testing instance to generate calls with that, let
me know via PM please.

Stefan

···

To: <sip:jitsi@192.168.5.110>;tag=5fbc99d7

Emil

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

o Stefan Sayer on 02/26/2014 08:40 PM:

o Ingo Bauersachs on 02/24/2014 08:44 PM:

thanks for the info, I can avoid 'optional' without problems. Still
it's not really good to interop with ill-behaving peers but to not
interop with properly behaving peers.

I don't believe anyone is defending this. The point is that using multiple
streams for this was a hack. A work around and not an intended feature.

Multiple streams in SDP are something quite ill-defined that's handled
differently by different clients.

The situation is supposed to be clarified by plan unified at MMUSIC ...

but I

am not holding my breath.

Eventually, I expect everyone would simply start supporting RTP/SAVPF (for
WebRTC compliance) and/or make the encryption choice based on presence of
a=crypto attributes.

From that perspective, while what you describe is indeed an inconsistency,

I

don't exactly expect hoards of developers to rush on fixing it.

gotta love these euphemisms :slight_smile:

I quickly looked over the code: it would probably be sufficient to only mark
a media type (audio/video) as seen, if it isn't inactive.
(CallPeerMediaHandlerSipImpl#createMediaDescriptionsForAnswer, line 536).
But I neither have the time nor the resources (other softclients, a Kamailio
server, Snom and Cisco hardphones) to test it.

sip:gong@iptel.org is still running.

Here's another weird one: apparently, if the any crypto suite in SDES
is unknown to jitsi, the call fails ('unknown crypto suite'),

INVITE:

v=0
o=sems 32603063 488686631 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10000 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=crypto:1 AES_CM_256_HMAC_SHA1_80
inline:4SjMFOJog437vwu1tqrslWLXRIu95bGOL2U7OcDr
a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:njzu61jyXlG7rWF3afljmTgbbh0zjwJwYNrKxheL
a=crypto:3 AES_CM_128_HMAC_SHA1_32
inline:3WPY8nxETDCj4gbJQkXmK6VT69xTi6xaLYKOwSka
a=direction:both
m=audio 10002 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=direction:both

fails with

SIP/2.0 488 Not Acceptable here
To: <sip:jitsi@192.168.5.110>;tag=5fbc99d7
Via: SIP/2.0/UDP 192.168.5.110:5062;branch=z9hG4bKNO2T~aom;rport=5062
CSeq: 10 INVITE
Call-ID: 37A3A12B-530E41A10004BA59-99D77700
From:
<sip:callgen@callgen.example.net>;tag=595E005B-530E41A10004BA48-99D77700
Contact: "jitsi"
<sip:jitsi@192.168.5.110:14780;transport=udp;registering_acc=192_168_5_110>
User-Agent: Jitsi2.5.5065Linux
Content-Length: 0

the same with
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:ERI+A/NVEKE8iaR0RQ1qLu+ED5NMSE7kQkSQ3i9K
a=crypto:2 AES_CM_256_HMAC_SHA1_80
inline:sNuiquKHawzbvoSSJDiQyZemZ7Jxbjbz2WmbnAet
a=crypto:3 AES_CM_128_HMAC_SHA1_32
inline:DxbmxbYlxI5TJY6zMBTEPjuDlcn0s2ufDzAtqRUY

while an offer with known suites only:

v=0
o=sems 1645013317 1988569319 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10004 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:eM/ad9cTY53EGIdvm6DRmLNLgW4k+SFHcqyb2D9y
a=crypto:2 AES_CM_128_HMAC_SHA1_32
inline:dOdFO3Rf5in0lBNHrhWKtzaMyFvstmwH9UwroUjq
a=direction:both
m=audio 10006 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=direction:both

is happily accepted:

v=0
o=jitsi 0 0 IN IP4 192.168.5.110
s=-
c=IN IP4 192.168.5.110
t=0 0
m=audio 5014 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WJ8yuA55Y7LRxTvfbkaUypX/2G+/kBe63kFu7WNm

I mean, that's the idea of negotiation, no? Or do you spot anything
else wrong in the offer above?

sorry for that wording here, I didn't realize that there's of course
negotiation implemented; a quick glance over the code shows this is
just caused by a bug, which is that the attribute object is tried to
create for each crypto attribute in the SDP - and if this fails, the
error is not handled properly.

Here's a third bug regarding multi-stream/SAVP support, and I think
this one is more severe, because it directly violates negotiation and
is also there if RTP/SAVP is mandatory: If jitsi receives an SDP with
two m-lines, RTP/AVP first and then RTP/SAVP, it responds with just
only RTP/SAVP as the first stream (m-line).

see well known 3264, 6.:
For each "m=" line in the offer, there MUST be a corresponding "m="
line in the answer. The answer MUST contain exactly the same number
of "m=" lines as the offer. This allows for streams to be matched up
based on their order. This implies that if the offer contained zero
"m=" lines, the answer MUST contain zero "m=" lines.

The "t=" line in the answer MUST equal that of the offer. The time
of the session cannot be negotiated.

An offered stream MAY be rejected in the answer, for any reason. If
a stream is rejected, the offerer and answerer MUST NOT generate
media (or RTCP packets) for that stream. To reject an offered
stream, the port number in the corresponding stream in the answer
MUST be set to zero. Any media formats listed are ignored. At least
one MUST be present, as specified by SDP.

example offer:
v=0
o=sems 396271500 158891925 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10000 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=direction:both
m=audio 10002 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:97fNBE6fp+ALI4NHXnO2sf0q1CnQ9xhGU1YOzdKY
a=direction:both

jitsi's answer:
v=0
o=jitsi 0 0 IN IP4 192.168.5.110
s=-
c=IN IP4 192.168.5.110
t=0 0
m=audio 5006 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:7g6ociewa7Dy2R2hQRseV/0GZa2RoKDNVcOLMevu

again, if you need a testing instance, I can set one up. or just use
sipp with the SDP above.

Would you prefer if I file bugs directly?

Stefan

···

(btw, the answer must contain as many m-lines as the offer; you should
reject the other streams).

If you'd need some testing instance to generate calls with that, let
me know via PM please.

Stefan

Emil

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#8

I quickly looked over the code: it would probably be sufficient to
only mark a media type (audio/video) as seen, if it isn't inactive.
(CallPeerMediaHandlerSipImpl#createMediaDescriptionsForAnswer, line
536). But I neither have the time nor the resources (other
softclients, a Kamailio server, Snom and Cisco hardphones) to test it.

sip:gong@iptel.org is still running.

That's a nice offer, but it doesn't help as it is just one example.

Here's another weird one: apparently, if the any crypto suite in SDES
is unknown to jitsi, the call fails ('unknown crypto suite'),

INVITE:
[...]
a=crypto:1 AES_CM_256_HMAC_SHA1_80
inline:4SjMFOJog437vwu1tqrslWLXRIu95bGOL2U7OcDr
a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:njzu61jyXlG7rWF3afljmTgbbh0zjwJwYNrKxheL
a=crypto:3 AES_CM_128_HMAC_SHA1_32
inline:3WPY8nxETDCj4gbJQkXmK6VT69xTi6xaLYKOwSka
[...]
I mean, that's the idea of negotiation, no? Or do you spot anything
else wrong in the offer above?

sorry for that wording here, I didn't realize that there's of course
negotiation implemented; a quick glance over the code shows this is
just caused by a bug, which is that the attribute object is tried to
create for each crypto attribute in the SDP - and if this fails, the
error is not handled properly.

Yes, this is a bug and fixed with commit
58f577eb86ebd7134f434602d556a733baa10bf5. But please note that
AES_CM_256_HMAC_SHA1_80 is indeed an invalid cipher suite. The correct
string to use would be AES_256_CM_HMAC_SHA1_80 (note the twisted
256_CM/CM_256) [1, 2].

Here's a third bug regarding multi-stream/SAVP support, and I think
this one is more severe, because it directly violates negotiation and
is also there if RTP/SAVP is mandatory: If jitsi receives an SDP with
two m-lines, RTP/AVP first and then RTP/SAVP, it responds with just
only RTP/SAVP as the first stream (m-line).

see well known 3264, 6.:
[...]

This should be fixed with commit 1cab0b3dc3e6171f16c1f772c791db27cb4a6246.

again, if you need a testing instance, I can set one up. or just use
sipp with the SDP above.

Would you prefer if I file bugs directly?

No, please use the list unless a developer says otherwise.

Stefan

(btw, the answer must contain as many m-lines as the offer; you should
reject the other streams).

If you'd need some testing instance to generate calls with that, let
me know via PM please.

Stefan

Ingo

[1]
http://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descr
iptions.xhtml
[2] https://tools.ietf.org/html/rfc6188#section-5


#9

o Ingo Bauersachs on 02/27/2014 09:49 PM:

I quickly looked over the code: it would probably be sufficient to
only mark a media type (audio/video) as seen, if it isn't inactive.
(CallPeerMediaHandlerSipImpl#createMediaDescriptionsForAnswer, line
536). But I neither have the time nor the resources (other
softclients, a Kamailio server, Snom and Cisco hardphones) to test it.

sip:gong@iptel.org is still running.

That's a nice offer, but it doesn't help as it is just one example.

Here's another weird one: apparently, if the any crypto suite in SDES
is unknown to jitsi, the call fails ('unknown crypto suite'),

INVITE:
[...]
a=crypto:1 AES_CM_256_HMAC_SHA1_80
inline:4SjMFOJog437vwu1tqrslWLXRIu95bGOL2U7OcDr
a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:njzu61jyXlG7rWF3afljmTgbbh0zjwJwYNrKxheL
a=crypto:3 AES_CM_128_HMAC_SHA1_32
inline:3WPY8nxETDCj4gbJQkXmK6VT69xTi6xaLYKOwSka
[...]
I mean, that's the idea of negotiation, no? Or do you spot anything
else wrong in the offer above?

sorry for that wording here, I didn't realize that there's of course
negotiation implemented; a quick glance over the code shows this is
just caused by a bug, which is that the attribute object is tried to
create for each crypto attribute in the SDP - and if this fails, the
error is not handled properly.

Yes, this is a bug and fixed with commit
58f577eb86ebd7134f434602d556a733baa10bf5. But please note that
AES_CM_256_HMAC_SHA1_80 is indeed an invalid cipher suite. The correct
string to use would be AES_256_CM_HMAC_SHA1_80 (note the twisted
256_CM/CM_256) [1, 2].

thank you very much for the heads up! Fixed on my side now.

It's almost working now, but there's still an issue here - jitsi
(nightly 2.5.5123-1) uses the wrong tag in the crypto attribute of the
reply:

Offer:
v=0
o=sems 564451074 374432857 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10000 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=crypto:1 AES_256_CM_HMAC_SHA1_80
inline:QmF55C7blH8KF2HanvdUPReOsi66ZnOY+QnIOp+s
a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:EosCe/TXeVy3dsTOyCNoQVAe2Iv6lYVMOuTRdc+t
a=direction:both
m=audio 10002 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=direction:both

Answer:
v=0
o=jitsi-jitsi.org 0 0 IN IP4 192.168.5.110
s=-
c=IN IP4 192.168.5.110
t=0 0
m=audio 5006 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:V0lpqe6dUBzFBz/KdsZBsKluqitYsNuJSNbK4jMG

4568 5.1.2. says
* The tag and crypto-suite from the accepted crypto attribute in the
    offer (the same crypto-suite MUST be used in the send and receive
    direction).

Also note above that there's still only one stream in the answer in
the 'Optional' case (bug).

In 'Mandatory' multi-stream O/A works, both cases.

In 'Off' it doesn't; only the first is accepted, whether it's RTP/AVP
or RTP/SAVP (bug).

See below for signaling traces.

thanks and best Regards
Stefan

'Off'

···

------------------------------
Offer:
v=0
o=sems 370577957 715744048 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10000 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=direction:both
m=audio 10002 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=crypto:1 AES_256_CM_HMAC_SHA1_80
inline:xOyHph67i7cpPz86sAU/yary5AOjTvpP58kW+Y6d
a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:yAezPqzbrua/bDSyh80AHQSxAhYUJzg/LA0kfhlQ
a=direction:both
Answer:
v=0
o=jitsi-jitsi.org 0 0 IN IP4 192.168.5.110
s=-
c=IN IP4 192.168.5.110
t=0 0
m=audio 5022 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000

------------------------------
Offer:
v=0
o=sems 1966939655 631152050 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10000 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=crypto:1 AES_256_CM_HMAC_SHA1_80
inline:KpHEDdxEaYTQQQXi5W0Xer7ZM7QvBQZLMPei4zvs
a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:w8xEykh+LLlHMs5lqfZULhHTPugfbfCyB0J0H6TI
a=direction:both
m=audio 10002 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=direction:both
Answer:
v=0
o=jitsi-jitsi.org 0 0 IN IP4 192.168.5.110
s=-
c=IN IP4 192.168.5.110
t=0 0
m=audio 5024 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:cbe2Kl3MYKTcMvZpScuDfkdLJyAubdL2NECueTTY

'Optional'
------------------------------
Offer:
v=0
o=sems 1745504523 1306405880 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10000 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=direction:both
m=audio 10002 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=crypto:1 AES_256_CM_HMAC_SHA1_80
inline:DssZNgFRNZwQHYXS3FJfDXO62Hn+z1WUWP20RLfd
a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:6Inor5uj/SoNDhaJEJbZJuG2DGgDXCLitQwJ1IoG
a=direction:both

Answer:
v=0
o=jitsi-jitsi.org 0 0 IN IP4 192.168.5.110
s=-
c=IN IP4 192.168.5.110
t=0 0
m=audio 5026 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
-----
Offer:
v=0
o=sems 1521335971 1539109500 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10000 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=crypto:1 AES_256_CM_HMAC_SHA1_80
inline:UYWXy+TvnuIW4koL+N228l+01sNKh58nUI+7kr+o
a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:Roe71NXkSSEuE1msai5vgz16rwtCvYi8OCwsP/3M
a=direction:both
m=audio 10002 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=direction:both

Answer:
v=0
o=jitsi-jitsi.org 0 0 IN IP4 192.168.5.110
s=-
c=IN IP4 192.168.5.110
t=0 0
m=audio 5028 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:gBvUYUC4erBfDML6X9ToI4bXdiCIw5MChmMokvrN

'Mandatory'
------------------------------
Offer:
v=0
o=sems 1891996452 1108293986 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10000 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=direction:both
m=audio 10002 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=crypto:1 AES_256_CM_HMAC_SHA1_80
inline:A0pAN5ud+AMszheNpNRq3FAVfI35OOTGcvMDuwWK
a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:N8BS8K+QyUrP3VUYLehr4A1zAHssb0RfjZIbs6P7
a=direction:both

Answer:
v=0
o=jitsi-jitsi.org 0 0 IN IP4 192.168.5.110
s=-
c=IN IP4 192.168.5.110
t=0 0
m=audio 0 RTP/AVP 0 8 96
m=audio 5030 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:NYZDyJ1h6KBp/aYkOfWkko+Rcs97c6wklgDssHp1

-----
Offer:
v=0
o=sems 2081983816 1376207275 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10000 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=crypto:1 AES_256_CM_HMAC_SHA1_80
inline:xZFEgYRX/b2eEYpusv3R6GGRrUNPBdlhFBdw386L
a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:UPuXxU/invFRZkMuQnig0VvqgIk9vNi4ABKZUyA7
a=direction:both
m=audio 10002 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=sendrecv
a=direction:both
Answer:
v=0
o=jitsi-jitsi.org 0 0 IN IP4 192.168.5.110
s=-
c=IN IP4 192.168.5.110
t=0 0
m=audio 5032 RTP/SAVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 telephone-event/8000
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:LoQ8uwGtQYp+shfgESKRIg9/QH3do+3FQ+ZA4ytO
m=audio 0 RTP/AVP 0 8 96

-----

Here's a third bug regarding multi-stream/SAVP support, and I think
this one is more severe, because it directly violates negotiation and
is also there if RTP/SAVP is mandatory: If jitsi receives an SDP with
two m-lines, RTP/AVP first and then RTP/SAVP, it responds with just
only RTP/SAVP as the first stream (m-line).

see well known 3264, 6.:
[...]

This should be fixed with commit 1cab0b3dc3e6171f16c1f772c791db27cb4a6246.

again, if you need a testing instance, I can set one up. or just use
sipp with the SDP above.

Would you prefer if I file bugs directly?

No, please use the list unless a developer says otherwise.

Stefan

(btw, the answer must contain as many m-lines as the offer; you should
reject the other streams).

If you'd need some testing instance to generate calls with that, let
me know via PM please.

Stefan

Ingo

[1]
http://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descr
iptions.xhtml
[2] https://tools.ietf.org/html/rfc6188#section-5

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#10

o Stefan Sayer on 03/04/2014 04:48 PM:

In 'Mandatory' multi-stream O/A works, both cases.

found a more serious bug (makes e.g. bid-down attack possible) in
'Mandatory': if jitsi receives an RTP/AVP answer to the RTP/SAVP
offer, jitsi still continues the call normally, unencrypted.

offer from jitsi:
v=0
o=jitsi-jitsi.org 0 0 IN IP4 192.168.5.110
s=-
c=IN IP4 192.168.5.110
t=0 0
m=audio 5069 RTP/SAVP 96 9 97 98 100 102 0 8 103 3 104 101
a=rtpmap:96 opus/48000/2
a=fmtp:96 usedtx=1
a=rtpmap:9 G722/8000
a=rtpmap:97 SILK/24000
a=rtpmap:98 SILK/16000
a=rtpmap:100 speex/32000
a=rtpmap:102 speex/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:104 speex/8000
a=rtpmap:101 telephone-event/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:csrc-audio-level
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:51ozfUhJtmew15FEh5Sj6uCEzVV5EIhDLxMoivbn
a=crypto:2 AES_CM_128_HMAC_SHA1_32
inline:JSWsKIKLCkbURbGfcmVVlGj7c4EearCTPqk4Z1pw
a=crypto:3 F8_128_HMAC_SHA1_80
inline:7G7IwlACvRZKpcrWEpCa+zlr1hcVjVaJEx9cb+iB

(incorrect) answer:

v=0
o=sems 901688451 386176378 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10002 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=direction:both

jitsi just continues the call. again, if you want a test server
instance for this...

Stefan


#11

It's almost working now, but there's still an issue here - jitsi
(nightly 2.5.5123-1) uses the wrong tag in the crypto attribute of the
reply:

[...]

4568 5.1.2. says
* The tag and crypto-suite from the accepted crypto attribute in the
    offer (the same crypto-suite MUST be used in the send and receive
    direction).

This is fixed in libjitsi/14b8f56430f71f4837fe736f1544c1fb3b6b0dde and
jitsi/5cf2a26673c58eea5dcbe7d374bf4aa7986eace0

Also note above that there's still only one stream in the answer in
the 'Optional' case (bug).

That will follow eventually when I found more time to work on it (I've begun
with writing unit tests).

Ingo


#12

Hi Ingo, Emil,

I just met Stefan at Kamailio World and he reminded me of this email. Do any of you guys would be able to comment on this one? :slight_smile:

Thanks!
Yana

···

On 04 Mar 2014, at 19:47, Stefan Sayer <stefan.sayer@googlemail.com> wrote:

o Stefan Sayer on 03/04/2014 04:48 PM:

In 'Mandatory' multi-stream O/A works, both cases.

found a more serious bug (makes e.g. bid-down attack possible) in
'Mandatory': if jitsi receives an RTP/AVP answer to the RTP/SAVP
offer, jitsi still continues the call normally, unencrypted.

offer from jitsi:
v=0
o=jitsi-jitsi.org 0 0 IN IP4 192.168.5.110
s=-
c=IN IP4 192.168.5.110
t=0 0
m=audio 5069 RTP/SAVP 96 9 97 98 100 102 0 8 103 3 104 101
a=rtpmap:96 opus/48000/2
a=fmtp:96 usedtx=1
a=rtpmap:9 G722/8000
a=rtpmap:97 SILK/24000
a=rtpmap:98 SILK/16000
a=rtpmap:100 speex/32000
a=rtpmap:102 speex/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:104 speex/8000
a=rtpmap:101 telephone-event/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:csrc-audio-level
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:51ozfUhJtmew15FEh5Sj6uCEzVV5EIhDLxMoivbn
a=crypto:2 AES_CM_128_HMAC_SHA1_32
inline:JSWsKIKLCkbURbGfcmVVlGj7c4EearCTPqk4Z1pw
a=crypto:3 F8_128_HMAC_SHA1_80
inline:7G7IwlACvRZKpcrWEpCa+zlr1hcVjVaJEx9cb+iB

(incorrect) answer:

v=0
o=sems 901688451 386176378 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10002 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=direction:both

jitsi just continues the call. again, if you want a test server
instance for this...

Stefan

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#13

Stefans mails are still marked as unread and are on my todo list. The tag is already fixed but not tested and not committed. For the other one I'm trying to write unit tests, but I just didn't have enough time to work on stuff that is currently unimportant for me.

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

Le 04.04.2014 à 17:20, "Yana Stamcheva" <yana@jitsi.org> a écrit :

Hi Ingo, Emil,

I just met Stefan at Kamailio World and he reminded me of this email. Do any of you guys would be able to comment on this one? :slight_smile:

Thanks!
Yana

On 04 Mar 2014, at 19:47, Stefan Sayer <stefan.sayer@googlemail.com> wrote:

o Stefan Sayer on 03/04/2014 04:48 PM:

In 'Mandatory' multi-stream O/A works, both cases.

found a more serious bug (makes e.g. bid-down attack possible) in
'Mandatory': if jitsi receives an RTP/AVP answer to the RTP/SAVP
offer, jitsi still continues the call normally, unencrypted.

offer from jitsi:
v=0
o=jitsi-jitsi.org 0 0 IN IP4 192.168.5.110
s=-
c=IN IP4 192.168.5.110
t=0 0
m=audio 5069 RTP/SAVP 96 9 97 98 100 102 0 8 103 3 104 101
a=rtpmap:96 opus/48000/2
a=fmtp:96 usedtx=1
a=rtpmap:9 G722/8000
a=rtpmap:97 SILK/24000
a=rtpmap:98 SILK/16000
a=rtpmap:100 speex/32000
a=rtpmap:102 speex/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 iLBC/8000
a=rtpmap:3 GSM/8000
a=rtpmap:104 speex/8000
a=rtpmap:101 telephone-event/8000
a=extmap:1 urn:ietf:params:rtp-hdrext:csrc-audio-level
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:51ozfUhJtmew15FEh5Sj6uCEzVV5EIhDLxMoivbn
a=crypto:2 AES_CM_128_HMAC_SHA1_32
inline:JSWsKIKLCkbURbGfcmVVlGj7c4EearCTPqk4Z1pw
a=crypto:3 F8_128_HMAC_SHA1_80
inline:7G7IwlACvRZKpcrWEpCa+zlr1hcVjVaJEx9cb+iB

(incorrect) answer:

v=0
o=sems 901688451 386176378 IN IP4 192.168.5.110
s=sems
c=IN IP4 192.168.5.110
t=0 0
m=audio 10002 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=direction:both

jitsi just continues the call. again, if you want a test server
instance for this...

Stefan

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev