testing with another SIP client (pjsua) I found some problems and
strange behaviour in conjunctions with RTP/SRTP
Attached is a wireshark file that shows the network activities.
The following call flow:
- pjsua (at address *.130) calls SC (at address *.1) and sends an INVITE
offering several codecs
- SC answers with 200 OK, also offersing several codecs (2 in this case)
(pjsua always reduces the number of codecs to one, for example if it
receives an invite with several codes it send a 200 OK that contains
only the one codec it selected).
- pjsua sends ACK but sends another INVITE immediately afte rthe ACK
that contains only the one codec that pjsua selected.
- SC answers with 200 OK to this second invite
- pjsua sends ACK
In this case sometimes I don't hear pjsua audio, sometimes I hear it.
The attached files shows the second case also with a successful ZRTP
exchange. However, while the pjsua data is encrypted, the SC data is
not (I can deduct this from the RTP data pattern sent by SC). Thus
it seems that SC does seems to use 2 RTP sessions on the same port?
Could that happen because of the double invite (sort of re-invite) that
SC creates a second set of RTP session objects. This would explain that
sometimes I don't hear pjsip's audio.
To check this theory I reduced the number of codecs in SC to just
one so that SC offers only one codec in 200 OK. In this case pjsua
does not perform a second invite (because there was no reason to
reduce the number of codecs) and the RTP connection was ok, ZRTP
was ok and data was encrypted in both directions.
Can you have a look to this?
double-invite1.pcap.tar.gz (104 KB)