1 / 7

Some early SIPREC interop testing results

Some early SIPREC interop testing results . Hadriel Kaplan. We’ve done some testing. 3 Vendors, 4 implementations 2 SRCs, 2 SRS’ Hopefully going to next Sipit as well 3 Problems found, arguably bugs Details next. Problem 1.

purity
Télécharger la présentation

Some early SIPREC interop testing results

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Some early SIPREC interop testing results Hadriel Kaplan

  2. We’ve done some testing • 3 Vendors, 4 implementations • 2 SRCs, 2 SRS’ • Hopefully going to next Sipit as well • 3 Problems found, arguably bugs • Details next...

  3. Problem 1 • SRS implemented older draft XML, but there’s no way to know that by by MIME type • The problem now is how do we know when the SRS gets updated to the correct/latest XML in the future? • Requires configuration change on SRC and/or SRS • This is a general problem with implementing drafts of course, but the IETF wants early implementation experience/knowledge

  4. Problem 2 • SRC and SRS setup Recording Session successfully, but then both SRC and SRS sent re-INVITEs at the same time (i.e., glare) • This is supposed to cause a 491/500 response and fail the transaction but not the dialog, and start random timers on both sides • Naturally that didn’t happen... well it kinda did, but things weren’t good • Might want to put some text in the docs to watch out for this being possible

  5. Problem 3 • SRC and SRS setup Recording Session successfully, but... • Far-end PBX then changes the participant with a SIP UPDATE method, which SRC forwarded correctly to SIP UA, but SRC did not update SRS • Interestingly, the UPDATE changed the From/PAI URIs of the dialog (yes, that’s legal)

  6. Other notes • 1 SRC created the Recording Session on receipt of INVITE, the other on receipt of SDP answer in 18x/200 • This was a surprise to one of the SRS’ • 1 SRC actually honored the recordpref attribute • This was a surprise to me  • Of course it could be overridden with configuration (not a surprise)

  7. Has anyone else done interop testing yet?

More Related