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 
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
