On Fri, Jun 29, 2012 at 4:20 AM, R?gis Montoya <r3gis.3r at gmail.com> wrote: > Hi, > > As per ticket 1185 some parts of the code is disabled. As part of that, > the OPTIONS reply doesn't include SDP body anymore. > > Right, I think we missed that! Let me fix it soon. > I understand that the root cause is that no media transport are present at > the point an incoming OPTIONS request arrives. > The problem is that it seems to break the incoming calls for some other > sides. I've one report from user with an asterisk configured with SRTP > incoming. > I don't know yet what the remote side is, but it maybe comes from their > asterisk server. I guess there is some check to know first if client is > able to use SRTP? Would it make sense? If so, I think that the app should > 'try' to reply with a SDP body. > > So I've one question : > Would it be acceptable to reply with a SDP with fake ip/port in OPTIONS > reply (for example 0.0.0.0)? Is there any case where OPTIONS reply would be > used for media ip/port? > > IMO it should be okay to use fake IP, but I'm not sure about 0.0.0.0 as it conveys call hold state in old SIP spec. I don't think anyone should/would use the IP/port in OPTIONS reply. > I guess that if not a problem, it would be possible to generate a SDP with > just codecs / crypto / known information. I don't know if it's possible in > pjsip but I guess that at this point codec manager is already up and most > things will go fine. > > Yes. > Also side note, while investigating the issue, I noticed that ticket 1185 > also remove something about SRTP optional mode (in pjsua_media.c:1980). I > didn't get why this part of the code is disabled. After a very first look > it seems nothing is missing at this point to have this part of code > enabled. Did I miss something? > > This is for another way to convey optional SRTP encryption for the media, by duplicating each media in the offer: one with RTP/AVP and another exact copy with RTP/SAVP. It was making things very very complicated even with the 1.x already, and now in the 2.x with the async media transport, video, and multiple media lines, it will be an order of magnitude more complex. Frankly we gave up. But it was not so popular anyway, so I don't think we're loosing much. Best regards Benny > Best regards, > R?gis > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20120629/ad489d9c/attachment.html>
