[sr-dev] RTPEngine in reINVITE/on-hold use case

[Waite, Hugh]

Hi,

I updated to the latest from git but it didn't improve the situation with null IP addresses from the non-webRTC client. In fact, rtpengine sent some ICE candidate lines with null IP's.
We decided we don't need to worry about clients that use the null IP mechanism for on-hold, so I sent some simulated traffic with sipp that has real IP addresses and uses a=sendonly/inactive. These results were better.

With the latest rtpengine version (as of 21/7/14), the initial invite towards Chrome uses a=setup:actpass for the DTLS handshake, as required. In the reINVITE, it uses a=setup:passive. Chrome rejects this because it isn't actpass.
I can see the code that works out the setup direction string in sdp.c:1600 based on the active/passive flags. Should the value always be "actpass" if we are making an offer? (RFC5763 §5)

Regards,
Hugh

-----Original Message-----
From: sr-dev-bounces at lists.sip-router.org [mailto:sr-dev-bounces at lists.sip-router.org] On Behalf Of Richard Fuchs
Sent: 17 July 2014 18:06
To: sr-dev at lists.sip-router.org
Subject: Re: [sr-dev] RTPEngine in reINVITE/on-hold use case

On 07/17/14 12:48, Waite, Hugh wrote:
> Hi,
>
> I am using rtpengine to convert SRTP to RTP for audio and video and I
> am also doing this for reINVITEs.
>
>
> RTPEngine appears to have disabled the two media streams, rather than
> putting them on hold. Is this a deliberate choice or the best choice
> given the multiple possibilities of client implementations? And can
> this behaviour be improved?
>
> If the call is taken off-hold later, I would prefer not to have to do
> the full ICE restart, including TURN, DTLS handshakes etc. etc. if it
> can be avoided.


This is one of those cases where no matter what you do, it's always gonna be wrong for somebody. :)

There was a recent commit [1] which slightly changed the behaviour when putting a call on hold in this manner, I suspect your build is older than this. I'm not sure if it would fix your particular issue though.

Rtpengine could translate a null c= address into the respective attributes (and leave a valid c= address), but then you run into the problem of breaking compatibility with clients which don't support or misunderstand this type of signalling.

So yes, there's definitely room for improvement (there always is), it's just a matter of figuring out what the Right Thing[tm] to do is. :)

cheers

[1]
https://github.com/sipwise/rtpengine/commit/a7784f5ca3437d1c7b58308022ef0e06cfa4d745

_______________________________________________
sr-dev mailing list
sr-dev at lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
________________________________
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.